131–140 of 526 posts
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?
Earlier quoted context omitted.
Note: if your hashing algorithm is too compute intensive, you have to take other measures to prevent your login system from being a DDOS vector... for example, with SCrypt's recommended defaults for passwords, the .Net library takes almost half a second of time on a modern CPU... if you get more than a few dozen requests per second, per system you can be brought to a crawl without other mitigation in place.
What makes it slow? Is it implemented in C#? I would avoid slow implementations of password hashing algorithms. You want the overall operation to be slow due to the computations you're performing, but you want the implementations of those operations to be fast. Because the attacker's implementations of those operations will be fast .
Earlier quoted context omitted.
Which leads to the question if slack encrypts the chat data in the database.
That would make implementing search quite hard so I'd say - it's pretty likely they don't encrypt it.
EDIT: Slack responded that they do not support SMS yet.
Dong, Dong, Dong, that is the death bell of a startup
> 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 cl…
bcrypt + random salt
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…
Earlier quoted context omitted.
My concern are the usernames, emails and phone numbers that were probably not encrypted
Exactly!!! Encrypting user data should be a common practice like hashing passwords.
What could you do with a one-way encrypted phone number? I'm not able to enter a phone hash to make a call.
Earlier quoted context omitted.
Why would you assume that? There are plenty of ways to hack into stuff without sql injections.
It's the most common vulnerability. https://www.owasp.org/index.php/Top_10_2013-A1-Injection
Edit: Slack's in PHP, I thought it was in RoR for some reason. Oops.