Slack was hacked

Original email sent to Slack users: https://gist.github.com/anonymous/a26e3279dd57be3363b3

What the email might sound like if Slack was being completely forthright:

---

Dear User,

We are writing to inform you that our servers have been broken into and that the personal information of our 500,000 users (including you) has been stolen. This information was likely swiped by either the bad guys (thieves) and will be sold on the darknet, or by the bad guys (NSA) and will be used in their efforts to build a global surveillance state.[1] We have since tried to block this unauthorized access and made additional (but nebulous) changes to our technical infrastructure in an attempt to prevent future PR headaches. No specific action is required of you - nor is there anything you can do to reverse your lost privacy.

However, our PR department is extremely worried that this news might damage our 2.76 billion dollar valuation.[2] Since we have been working on a sexy (but completely unrelated) security feature for a while, we decided to release it early. We intentionally conflated the fact that our servers got hacked with a new user-space security feature in an effort to obfuscate how badly we screwed up.

The breach happened in February but it has taken us till the end of March to get this new feature usable.[3] (If you are asking yourself why we would release a half-baked security feature, just remember, we are the company that just accidentally released personal information belonging to you and half a million other people.)

We are hoping that by making just the the paragraph about this new feature BOLD many users might miss what really happened. We also hope that by "strongly recommending" that you enable this feature, the blame for this security blunder is shifted to our customers, as if this could somehow be prevented by enabling this feature. Additional misdirection is available in our help center.

[1] https://www.eff.org/nsa-spying

[2] http://blogs.wsj.com/digits/2015/03/26/slacks-valuation-more...

[3] http://slackhq.com/post/114696167740/march-2015-security-inc...

Careful. If an attacker is ever able to observe the output for a very short password - one byte, say - then only one byte of your secret salt is used, and the attacker could begin brute-forcing the secret salt starting with the first byte.

XOR could also result in NULL bytes anywhere in the hash input, which could drastically weaken passwords,. For example, bcrypt ignores any password characters after the first NULL byte. This is especially bad if the attacker can supply their own passwords, doubly so if they can observe the output, since they can then easily brute-force individual bytes of the secret and use that knowledge to intentionally create NULL bytes in the hash input.

> XOR doesn't decrease the keyspace (or change it in any interesting way), so any attack on XOR is an attack on bcrypt

I wouldn't make any statement like this unless you've actually gone through the steps to prove it.

See my other comment on the same point in this thread.

Yeah, what I'm getting at is that those posts don't actually come right out and say your code should be calibrating itself regularly. They talk about selecting a work factor by benchmarking your current hardware, but they leave it there, and one might come to the conclusion that once they've measured their hardware, they put "13" in a config file and call it done. I'm advocating for advice like "Don't think about work factors, think about time. Your configuration should be a time value, and when your app starts up, it should compute its own work factor based on this time value." If your code does this, there's no need for rules of thumb like "11 is a good starting point for a bcrypt work factor."

> 3. For some historical reasons, many people feel the need to change keys regularly. This is rather misguided: key rotation makes sense in an army or spy network where there are many keys, and partial compromissions are the normal and expected situation, so a spy network must, by necessity, be in permanent self-cleansing recovery mode; when there is a single key and the normal situation is that the key is NOT compromised, changing it brings no tangible advantage.

This is a really strange advice from Thomas Pornin. People rotate keys because not doing so weakens most symmetric encryption schemes. For example while using AES-GCM with 96-bit nonces one needs to rotate keys after encrypting roughly 2^32 ~ 4 billion messages; otherwise the IV collision probability will be higher than 2^(-32), which is already high enough in most large scale systems (and really bad things happen when the IV is repeated).