Live data from Hacker News

Slack was hacked

slackhq.com

391–400 of 526 posts

Re: Slack was hacked

#391

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

That's a really interesting idea. I was thinking it might have performance implications but I think that will only apply to the password validation. How do you make sure the mapping key doesn't cause collisions when you roll it to reset everyone's passwords?

Re: Slack was hacked

#392
post #120

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.

[deleted]

Re: Slack was hacked

#394

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…

It's the same criticism people had for Dropbox or the first iPhone: there's nothing new. The key is that it's very well packaged with a focus on UX (especially on mobile) and it requires extremely little setup effort.

Re: Slack was hacked

#395

Earlier quoted context omitted.

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…

OTOH, if you're small, you are not as interesting a target as a huge cloud provider that hosts everyone . Which means, while small practice's security should be good, it doesn't actually have to be as good as the big cloud behemoth. It's why your gmail account is more likely to get hacked than my piddly self hosted imap server. Google's network security is unarguably better than mine, but you are never going to socia…

Also, it is far easier to harden one or two hosts than entire farm of different devices.

Re: Slack was hacked

#396
post #120

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 actually am coming to the conclusion that 2FA is dangerous. It's recommended any time there's any kind of breach as if it were some kind of panacea for security, when in most cases the cause of a security breach is a database intrusion. 2FA keys are stored unencrypted so if the db is breached they're already cleartext (no boil the oceans bcrypt collision needed) and the extra layer of security theatre from 2FA only…

2FA can prevent future password phishing attempts when your users table is compromised.

It's a bit of a redirect in terms of what happened with Slack though and not worth mentioning after the fact.

Re: Slack was hacked

#397
post #50

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…

The most important thing to stop sql injection is to validate your parameters on the server side.

Re: Slack was hacked

#398

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

> you won't know what usernames they go with

But if you've got a list of all usernames (probably a relatively small number) and access to a running system, isn't it easy to just try each password against each user until you find a match?

The common practice of limiting logins from a single username wouldn't help with that either.

Re: Slack was hacked

#399
post #285

Earlier quoted context omitted.

Encryption isn't the same as hashing. Encryption is two-way. The previous comment did make the encryption / hash distinction - though I can totally understand how his post might have been misread that he was recommending the same mechanisms for both sets of data.

OK, so slack stores a username, name and email address for each user. This is visible to everyone else in the same Slack team at minimum. You also need it for e.g. password resets, perhaps billing. We can assume they aren't total idiots and there's a Internet facing application server that connects to a internal-only database server that has this data. Also, assume SQL injection is not the attack vector. How would yo…

I wouldn't. I don't agree with his point either (see my response to him: https://news.ycombinator.com/item?id=9277659).

Re: Slack was hacked

#400

Earlier quoted context omitted.

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

> you won't know what usernames they go with But if you've got a list of all usernames (probably a relatively small number) and access to a running system, isn't it easy to just try each password against each user until you find a match? The common practice of limiting logins from a single username wouldn't help with that either.

Yes, but we currently have 2.1 million users, so that's still no small burden. And don't forget that's only after you brute forced the passwords.
Post reply on HN