I hate to be the negative guy, and they were hashing passwords better than 90% of the sites, but it would be SO easy to completely neutralize password leakage when the attacker only has access to the database.

https://blog.filippo.io/salt-and-pepper/

tl;dr: Hardcode a second salt in your application code or in an environment variable. Then a database dump is not enough anymore to do any kind of bruteforce.

It's simple, free and you can retroactively apply it.

EDIT: I addressed some of the points raised in this thread here https://blog.filippo.io/salt-and-pepper/#editedtoaddanoteonr...

> No financial or payment information was accessed or compromised in this attack.

This wouldn't be my first concern. It would be all of the confidential communication that happens within slack.

Assuming (no evidence, it's just very common) that this was a SQL Injection, here are some ways to protect yourself:

* Use http://en.wikipedia.org/wiki/Database_activity_monitoring. If you don't list users on your site and you get a query that would return more than one user record, it's a hacker

* Add some http://en.wikipedia.org/wiki/Honeytoken s to your user table, and sound the alarm if they leave your db

* Use Row-Level Security

* Database server runs on own box in own network zone

* Send logs via write-only account to machine in different network zone. Monitor logs automatically, and have alerts.

* Pepper your passwords (HMAC them with a key in an HSM on the web server (then bcrypt). Don't store key in db). https://blog.mozilla.org/webdev/2012/06/08/lets-talk-about-p...

* Use a WAF that looks for SQL injections

* [Use real database authentication, per user. Not one username for everyone connecting to db. Yes, this is bad for connection pooling]

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.

It's refreshing to 1) see a breach notification including the actual password hashing algorithm, 2) see they're using a strong one like bcrypt (presumably with a reasonable cost factor).

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.

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?

Host your own IRC if you care about the privacy and security of your communication.

There is no reason why you can't take 10min to setup a IRC with SSL on your own.

Yes, Slack is awesome, lots of features, but it's not yours!

Surprisingly, they didn't force a password reset on all accounts. Even though the passwords are hashed and salted, targeting a couple users and checking for weak passwords can now be done offline, with no rate-limiting or network calls necessary. In breaches like these, it should still be mandatory to issue service wide password resets. Anything less is unacceptable.

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.

So a database gets hacked, they add MFA and people are arguing about peppering passwords. What about the part on how the hackers got access to the database in the first place?

Passwords are not the only sensitive info that can be stored in a database and most of the time, that info isn't hashed.

I would be more interested in how the hacker got access to their DB and nothing else. Maybe the DB is remotely accessible (unlikely) or there is SQLi vuln. in Slack.

One thing that bugged me about this today was that after I changed my password on desktop, my mobile session wasn't invalidated. Apparently it's an option for mass password resets, but it really should be mandatory.

My team logs with our Google accounts. It's not addressed in the disclosure, but should we be deauthorising Slack. Have our tokens been breached?

> 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.

I'm happy to hear they didn't just use MD5 with no salt as this would be the same as storing it in plane text...

bcrypt + random salt sounds to me like the best practice nowadays, is it still holding? or are there some advanced in GPU cluster costs on EC2 that make even bcrypt hackable. I think I heard something that it has a way to "adapt" to advances in computing, is that by simply adding more iterations based on the current CPU speed or something? how does that work?

Was an admin account compromised in a situation where 2FA could have prevented the unauthorized access? If that's not what happened, then 2FA seems a bit hand wavy if it's not directly related to this security incident.

I wonder how many people send sensitive credentials or other operational details through Slack. It'd definitely be a target (along with mail systems) if you want to attack better-protected customer systems.

We've been waiting for over a year for Slack to create a self-hosted version that we can deploy to our intranet specifically because we can't expose ourself to things like this. They've kept insisting that it's around the corner but it doesn't seem to be happening. Hopefully this will spur them to prioritize self-hosted Slack.

Literally was arguing with someone like two days ago that using Slack for sensitive data was a bad idea, guaranteed to blow up in your face sooner or later.

Nothing sweeter than "I told you so".

Slack encourages 2-factor authentication:

> Download and install either the Google Authenticator or Duo Mobile apps on your phone or tablet.

Hey Slack, I don't have a smartphone. What am I supposed to do?

Can we go back to IRC now, please! Slack is not only distracting, proprietary, but it is also pretty expensive. Let the mere mortals use it, but we should stay away!

Out of interest, where where the per-user salts stored I wonder? Where would people normally store this if not next to the hashed password in the same table?

Lot's of hype (IMO) around Slack, but lot's of money thrown at them so I kept thinking that I'm missing something! Just being skeptical as usual. The other day an invitation arrives to use Slack. Great! Let's see it, this killer feature or killer combination of features. What have these smart people come up with that hasn't been done countless times in the same space to make them so successful?

It's literally nothing. I can't believe that's the product.

Anyway, on top of a completely underwhelming experience comes this news. I can't see why a company would use them, to be honest. But then I haven't built a billion dollar company, so not many people will be asking me for an opinion.

"As part of our investigation we detected suspicious activity affecting a very small number of Slack accounts. We have notified the individual users and team owners who we believe were impacted and are sharing details with their security teams."

Assuming the password hashes can't be reasonably reversed, what would have caused suspicious activity on some user accounts? Is this a situation where certain users may have been targeted specifically, meaning that only a couple hashes needed to be reversed, making the task feasible?

Dear All - Your passwords should be considered compromised. Hashing is merely a deterrent, it does not prevent cracking.

So they didn't get the password, ok. But they still have my name, my email, my skype.

This completely sucks.

Hope the Slack team will properly implement SSO two-factor authentication policy - right now none of the Slack apps request re-authentication after thirty days once an account is signed into via SSO. Sign in once on OS X, Windows, iOS, Android and no further authentication needed. Looking at Google Apps SSO specifically but am assuming it affects other authentication providers.

Might as well plug my tiny Slack auto-install/update script for the OS X app while I'm here - hope someone else finds it helpful:

https://github.com/opragel/install_latest_slack_osx_app

Can anyone from Slack elaborate as to where this hack originated if known?

Slack has now sent me 6 e-mails about this, to the same address :(

They have different names associated in each one (i.e. some have my last name, some have an alias, etc), but all to the same target e-mail address.

Can we please reference to this event as the "Shlacking"?

Interesting that the title says "March 2015 Security Incident" but it turns out it was in February. Also interesting they don't say which days in February.

Why is everyone worried about what hashing algorithm was used and not if their company's private chat logs are about to become public knowledge?

If you have a reset_token you still can log in, even when passwords are hashed. Likely reset tokens were stored in the same table

> 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?

It would be good to know exactly how this sort of thing happens so others can try to prevent it in their own systems.

Well, I can't even reset my password. I suspect that's because my registered e-mail address uses the "foo+bar@gmail.com" format (which I use for easier filtering), and something on Slack doesn't like sending those (no e-mail on my inbox, spam folder or filter matches)

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.

Remember kids, it's 2FA before the fact, not after. 2FA is not a magic bullet though, and neither is salting. Salting makes it _expensive_, but not impossible for pass recovery. Always aim for impossible. You want to be able to throw away the key during an incident.

For those that store the user tables in the same db as everything else, what is the big deal about protecting passwords in particular? The attacker already has much more. If it is because of password re-use then that is what should be prevented.

Got the email from them about the issue, as a Slack user. Also got 2 other duplicate emails from them (which went into the same Gmail conversation, since same subject), that were empty.

Seen this a few times for other services, not sure why it happens.

This is why you need to hash reset tokens too

http://sakurity.com/blog/2015/03/27/slack_or_reset_token_has...

ppl gotta stop thinking encryption in a db saves you from compromise. Its being very naive or ignorant. It only reduces your exposure to data leak very lightly - in some circumstances, which are generally not even likely (like make a dump and post it publicly)

Its like 'but it says AES on the box so its secure right?' and shouldn't be a thing among developers anymore.

Obviously the database data has to be decrypted for the app to use it, and generally, you hack the app, not the db.

What tangible things were hacked? apart from password was the communication history, files share etc were hacked too? We sometimes share code blocks and zip files etc..

If someone was able to get access to the user table I would believe it is trivial for them to download the chatlogs/ mine other information from database.

May be slack wants us to believe only a small part of the data is hacked , I dont know .

We have been using Slack for many projects over last year and it helps improve productivity

Slack is growing their security team, if you want to help them improve the security of the product: https://slack.com/jobs/dfd75111/security-engineer

"So yeah, we got hacked..." - Landing Page

How many rounds of hashing did they use?

Wait a second, you got hacked 27 DAYS ago (at least), you know they got data, and you are NOW telling people?

Dong, Dong, Dong, that is the death bell of a startup

They added team-wide password/security stuff.... but it's paid users only. Lame.

Why the fuck am I reading this on hacker news and not from a notification in slack?

uc3dp

is there anything that slack does you can't do with skype?

I find lot of these new startups are just creative ways of reinventing the wheel and convincing you need it to appear cool & hip....kind of like fashion for high schoolers

I dont really care. Never shared any critical information on slack any ways.

Why do I have to install Google Authenticator some sort of other app for 2factor here? Why can't you send me a text like everyone else does?

EDIT: Slack responded that they do not support SMS yet.

This sounds like a half-assed hack if they were able to limit the damage. 2/10 try harder next time, skiddos.

What the flippin' heck is Slack? I received an email today telling me of this event. Then I had to recover my team and my password, then deactivate my account, and I have never seen this website until I saw that email. Looking at my team, it seems to be created by the guys at <pyistanbul.org>, or someone using that website as a base for accounts. That one has a people page and there are links to various places. Now, someone has created an account in my name using my main e-mail address and I have not been e-mail-notified for a confirmation of account, or at least not have been notified that an account is created. Apparently either these lot cannot write proper emails that can pass through spam filters or they expressly allow this sort of malicious account creation. Not surprising that they got hacked.