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…
Slack was hacked
391–400 of 526 posts
Re: Slack was hacked
#392Was 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.
Re: Slack was hacked
#393Re: Slack was hacked
#394Lot'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…
Re: Slack was hacked
#395Earlier 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…
Re: Slack was hacked
#396Was 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…
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
#397Assuming (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…
Re: Slack was hacked
#398I 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…
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
#399Earlier 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…
Re: Slack was hacked
#400Earlier 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.