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

331–340 of 526 posts

Re: Slack was hacked

#331

Post by rnovak »

Someone1234 wrote: post #327
rnovak wrote: post #299

Earlier quoted context omitted.

Once you use Encryption, it's no longer pepper, it's encryption with weak key storage (hard-coded). At that point, genuinely, why not just follow best practices and store the key securely (e.g. using an HSM)?

Because nobody knows how to do that and it is likely extremely expensive by every metric. And, no, I am not being facetious by saying nobody knows how to do that. I am being quite literal. Have you ever done that? Do you know how? Do you even know what you would google to figure out how? I'm yet to see my favorite library of course's documentation on a HSM. How do you do that in e.g. PHP with MySQL? MVC with MS SQL?…

It's worth it. And yes, I have done that, it's not a mystery, they all provide a API/ABI for interacting with them[1], such as OpenSSL's Engine API or PCKS#11.

Edit: There's even a project to literally do this directly from PHP[3]

[1] http://stackoverflow.com/questions/10796485/interfacing-with...

[2] http://en.wikipedia.org/wiki/PKCS_11

[3] http://stackoverflow.com/questions/3231293/how-to-interface-...

Re: Slack was hacked

#332

Post by tomjen3 »

curiously wrote: post #92

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

Yeah, about 90%.

Slack is many-to-many entities real-time-optional communication, where one particular subset is that all entities are humans and it is entirely real-time. That subset is handled, badly as always, by Skype.

Re: Slack was hacked

#333

Post by jjarmoc »

ntucker wrote: post #324
sdevlin wrote: post #57

Earlier quoted context omitted.

There are some thoughts on the matter here: http://chargen.matasano.com/chargen/2015/3/26/enough-with-th... . But I would say yes, bcrypt is still best practice. Other commenters are right that bad passwords will still be recoverable, but using one of bcrypt/scrypt/PBKDF2 is due diligence. I would use whichever one is most easily available on your platform.

Why do articles talking about this always talk about specific work factors and choosing a correct work factor, as if it's fixed? I thought good practice was to choose the work factor dynamically so it's calibrated to whatever hardware you're running today.

Uhh.. it doesn't? While it does give some specific values as 'a reasonable starting point' the article suggests tuning these to the specific environment.

"Each of these algorithms requires setting of an appropriate work factor. This should be tuned to make digest computation as difficult as possible while still performing responsively enough for the application. For concurrent user logins, you may need The stackexchange post (which is linked in the article) can be found at http://security.stackexchange.com/questions/3959/recommended...

Re: Slack was hacked

#334

Post by tomjen3 »

thspimpolds wrote: post #135

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

Sadly the universe isn't fair.

Nobody gives a shit about security, but yeah it should be illegal to sit on the information more than 48 hours. If you can't determine the complete and full extend of the damage before that you need to be out of business.

Re: Slack was hacked

#335

Post by zaroth »

yellowapple wrote: post #311
mike_hearn wrote: post #176

Earlier quoted context omitted.

You mean like how Authy specialised in two-factor authentication, but still managed to have basic string concatenation bugs that rendered their entire 2FA system bypassable?

Huh? This is the first I've heard about this, and searching for "Authy concatenation bug" isn't turning up anything useful.

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.

Re: Slack was hacked

#336

Post by brackin »

jacquesm wrote: post #204
buttsex wrote: post #201

Earlier quoted context omitted.

They archive chat messages so that you can search through them later.

That alone would be a great reason not to use them.

It's why I love Slack. If I remember a conversation about something two months ago I go to the room, search and find exactly what I needed.

Re: Slack was hacked

#337

Post by ntucker »

FiloSottile wrote: post #130

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 simpl…

We have an approach to this which doesn't modify the password hashing at all, so it can't possibly reduce the strength: we store users and password hashes (currently bcrypt * ) in two separate tables, and the key used to look up a given user's password hash is an encrypted version of their user id. The encryption key for doing this transformation is loaded dynamically at app startup and has some extra security precautions around storing it, so it's not baked into either the source code or a config file.

The upshot is that if you get a db dump and are able to brute force some bcrypt hashes, you won't know what usernames they go with. If you get a db dump and our source code, you're still out of luck. If you get ahold of an old server hard drive, you're out of luck. If you root a running server and inspect the process memory, you can obtain this key.

This scheme also allows the mapping key to be rolled, which would immediately invalidate all passwords in the system.

*we also version our password hash records so we can migrate from bcrypt to a new scheme fairly painlessly if it's warranted in the future.

Re: Slack was hacked

#338

Post by barce »

curiously wrote: post #92

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

Yes, the /giphy command. :)

Re: Slack was hacked

#340

Post by zeeboo »

randunel wrote: post #153
FiloSottile wrote: post #130

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 simpl…

I generally disagree with hardcoded salts, you should assume everything is compromised in a successful attack. But I'm actually commenting here because I don't see how you can retroactively apply the second salt to a hashed string. Could you please elaborate or share a link? Later edit: I'm referring to your example in your link: salt = urandom(16) pepper = "oFMLjbFr2Bb3XR)aKKst@kBF}tHD9q" # or, getenv('PEPPER') hash…

Update the hash when the user logs in because you have the password. You can tell if it's been applied by having another column, or prepending/suffixing the output with something that scrypt can't output.
Post reply on HN