Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Slack was hacked

slackhq.com

Post reply on HN
Print view View original

361–370 of 526 posts

Re: Slack was hacked

#361

Post by kendallpark »

superuser2 wrote: post #81
kendallpark wrote: post #20

Earlier quoted context omitted.

> Regardless, this is an example of why cloud communication (and ticketing and database off-loading [see MongoHQ] and...) systems probably won't ever become commonplace in most of the government space and the finance and health sectors. I agree. We might not like rolling out our own instances, but it prevents hackers from being able to grab ALL THE DATA in one fell swoop. It really amazes me that some EHR systems hav…

It's heartening to me. I've seen small practices with atrocious IT security. No WAY is self-hosted (for the thousands of small practices with maybe a couple of clueless help-desk types) even a billionth as secure as a professionally secured cloud service. Also, "cloud" for services like this means "your own private instance of the software running in a private VM in our datacenter" not "your own customer_id in a shar…

If you had a vulnerability in an EHR that was run locally at many different hospitals a hacker would still have to target every single hospital that uses it and wade their way through a bunch of different custom configurations. It's not as juicy a target as a cloud-based system where a single vulnerability can get ALL the data of ALL the hospitals EVER in one location. (Like the Anthem hack.) I agree that most locally run systems are more vulnerable than the professional cloud based services. But cloud services are more exposed to attack and are a more profitable target for hackers due to their size.

I think you have to assume that you're going to be hacked if you're a big enough target. You don't know what you don't know about your vulnerabilities. The better question is how you're going to design your data and platform to minimize the damage a major hack can do.

Re: Slack was hacked

#362

Post by koide »

yebyen wrote: post #122
petercooper wrote: post #47

Earlier quoted context omitted.

Setting up an ircd is not a bad idea. Then we just need to find the ircd and client that does what Slack does. (Which is totally possible, but I'm not sure it exists?)

I am interested first in persistent backlogs -- do you know an IRCd that does that? I am sure it couldn't be implemented client-side. I remember "SILC" which is not IRC, but if I remember correctly it had this. Mainly when you join a room, you should not get tabula rasa. You enter into some context, and if the last message was posted 4 days ago, your context starts 4 days ago, and the datestamps all reflect this. The…

See above, I use jabber for chat (supports backlog) with ejabberd and for other automation tasks I use hubot which integrates nicely with XMPP.

Re: Slack was hacked

#363

Post by homakov »

cheshire137 wrote: post #151

Looks like they require Google Authenticator or Duo Mobile app to do two-factor auth. I'm not interested. Why can't they be like Github and just send me a text message? I don't want a dependency on some other company's product to make Slack more secure.

SMS is the worst kind of 2fa, better not use it at all.

Re: Slack was hacked

#364

Post by dragonwriter »

cheshire137 wrote: post #151

Looks like they require Google Authenticator or Duo Mobile app to do two-factor auth. I'm not interested. Why can't they be like Github and just send me a text message? I don't want a dependency on some other company's product to make Slack more secure.

> I don't want a dependency on some other company's product to make Slack more secure.

How is dependency on SMS not dependency on some other company's product?

Re: Slack was hacked

#365

Post by zaroth »

yellowapple wrote: post #358
zaroth wrote: post #335

Earlier quoted context omitted.

Here's the write-up from Homokov. The guy is a pen-testing genius: http://sakurity.com/blog/2015/03/15/authy_bypass.html But if you just want the money shot: http://sakurity.com/img/smsauthy.png Yes. Typing '../sms' in the field bypassed the 2nd factor. Just, wow.

Huh. Well now I know. Thanks! Amazing what you can do with improperly-implemented input sanitation :) This probably could've been prevented by disallowing non-number inputs, no?

"In fact the root of the problem was default Sinatra dependency 'rack-protection'".

They were doing the input sanitation, but it wasn't the very first thing in the processing pipeline, since "best practice" was to pipe everything through 'rack-protection' first.

Homokov was first to state, this was really a black-swan type bug which 99.9% of the time makes it into production. Apparently, they were doing the "right thing" and still got burned.

Re: Slack was hacked

#366

Post by _trb_ »

I am an application security professional, and I created this account in order to make this post after reading many of the comments on this thread.

Many of the comments have great suggestions. However, very few talk about the most important part of creating mitigations and designing key management/crypto. What is the security target?

Before throwing new designs at a problem, the attackers and attack vectors must be defined. If you don't know who you are guarding against and what they will do (and what data they will steal), then how can you possibly say what is a good mitigation??

One might argue that the threat is obvious, but I'll guarantee you that there are dozens of threats here. List them. Prioritize them. Then mitigate them. It is helpful to fully understand the problem/solution space before jumping in with pepper's, salt's, extra databases, and solutions.

Re: Slack was hacked

#367

Post by [deleted] »

Yen wrote: post #62
eridius wrote: post #31

> Slack’s hashing function is bcrypt with a randomly generated salt per-password which makes it computationally infeasible that your password could be recreated from the hashed form. Is this true even when the attacker is specifically focusing on a single account, or is it only computationally infeasible to recover passwords for accounts in general?

quick answer - It's probably computationally infeasable to gain access to any specific account, or all accounts in the database. It's probably feasible to gain access to at least one account in the database, if it has a weak password. Hashing functions like bcrypt are intentionally set up to be computationally expensive, so that when brute-forcing a password, attackers can only try, say, 1 thousand passwords per seco…

[deleted]

Re: Slack was hacked

#368

Post by sjbase »

rattray wrote: post #45

How does one discover that they were hacked? The post states that the breach occurred during February, and this is the end of March... did it just take them a long time to react and write a post about it, or did they likely discover after the fact? If so, how?

The wording of the article suggests that they released 2-factor auth -after- the breach happened. This is purely speculation, but one possibility is that they wanted to get their ducks in a row (i.e. have some enhanced security options in place) before announcing the breach. Mitigate the PR damage.

Re: Slack was hacked

#369

Post by chatmasta »

If I were Slack, I would pretend to get hacked. Slack critics often point to its centralized architecture as a weak point, because rational corporations should not entrust security of their internal communications to a third party. Particuarly when that third party aggregates communications of its many clients, it becomes a target of hacking. Why hack a single corporation when you can hack Slack and get all their clients at once?

This is a valid criticism. Slack can do all it can to mitigate security risk. But at the end of the day, there is always at least one vulnerability, somewhere.

As Slack matures as a company, it needs an answer to this criticism. Because security is so naturally unpredictable, it would be disingenuous for Slack to respond with anything resembling "our security is perfect." Because, of course, as we see time and time again, no security is perfect.

Now that Slack has captured the low-hanging-fruit of the market, it needs to pick the high-hanging-fruit. The most profitable clients for slack will be the largest, conservative, enterprise clients who will join the Slack platform and then never leave. The long term survivability prospects of Slack depend on capturing these large enterprise customers.

Strategically, Slack needs to find a response to the criticism that its security is prohibitively weak, so that it can convince these large enterprises to join its platform.

Perhaps, the best response to security criticism is that "we got hacked, but our internal policies mitigated any cascading effects and customer data remains safe." [0] [1] So would it be in Slack's best interest to stage a hack on itself? Or to report a hack occurred when it really didn't?

It seems feasible that by setting precedent for its reaction to a hack, Slack has a chance to demonstrate the competence of its security team. Now investors can point to this incident as one handled well by the security team. In a world where, unfortunately, corporations will always get hacked, Slack was able to survive with some dignity.

[0] or, as safe as it can possibly be according to computer science.

[1] debatable.

Re: Slack was hacked

#370

Post by xorcist »

elchief wrote: post #301
specialk wrote: post #182

Earlier quoted context omitted.

Is there any significant evidence that peppering passwords helps? I've seen arguments for and against peppering out on the big bad internet. Everyone has opinions but there are few people's opinions about crypto that I actually trust. The best article I've seen against this technique is by ircmaxell [0]. Nicely summed up in this sentence "It is far better to use standard, proven algorithms then to create your own to…

It can help in the following scenarios: 1. Hacker steals db but does not compromise web servers (because the hmac pepper key lives on the web servers and not in the db) 2. Hacker can run SQL Injection via web server, but cannot otherwise access web server memory/process 3. HMAC key is stored in a hardware security module and hacker cannot gain physical access

All of the above cases are also helped by just by regular symmetric encryption. Why make things more complicated than necessary?
Post reply on HN