Earlier quoted context omitted.
If you get the user table, you can crack the password hashes offline, at your leisure.
While technically true, this seems like it would be computationally infeasible, or at least impractical, given that they were not just hashing but also salting the passwords. Of course, I barely know anything about computer security, but at least it should prevent attacks using rainbow tables I think?
Slack was hacked
171–180 of 526 posts
Re: Slack was hacked
#172It'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…
I think this just goes to show exactly why these systems will become more commonplace. There are only so many security experts to go around. Having all the very best concentrated on a smaller set of services seems like it makes more sense than trying to get a security expert for every service.
Re: Slack was hacked
#173Earlier quoted context omitted.
Why? Encrypting e-mail addresses would break password reset features and phone numbers are generally public anyway (yes you can go X-directory, but the real issue here is why these services require a valid phone number to begin with)
Why would encrypting email addresses break password reset? You can encrypt the database at rest such that the application has a private key that can decode it. That way both the application and the database server need to be breached to obtain anything usable.
It's also worth noting that it wouldn't just be the web servers that require your private key, it would also be any mail servers you use for sending your newsletters and such like (assuming these aren't run on your web servers - which often isn't the case). Then there's your telephone support staff, who would also may need to know your e-mail address so they could do their job effectively. And any other operators that might compile data extracts, eg for 3rd parties where users have given permission for your details to used / sold.
Quickly you're in a situation where your private key is more available across your infrastructure than the e-mail would have been if it wasn't encrypted to begin with.
Now lets look at the cost of such a system. There's an obvious electricity / hardware cost with the CPU time required to encrypt / decrypt this data (after all, CPU time is the general measure for the strength of encryption) and the staffing cost with the time wasted jumping through those extra hoops. The development time, code complexity, etc - it all has a cost to the company.
So what's the benefits in any companies doing this? They don't gain any extra security? This is really more of a privacy policy for their users; and users which are that paranoid about their e-mail address being leaked should either use a disposable e-mail account or shouldn't be using a cloud-based proprietary messenging network to begin with. What's more the chat history might well have your e-mail address in anyway (eg "hi dave, I'm heading into a meeting shortly, but e-mail me at bob@example.com and I'll have a look tonight")
Don't get me wrong, I'm all for hashing / encrypting sensitive data. But pragmatically we need to consider:
1) are e-mail addresses really that sensitive? Or instead should we be encouraging better security for our web-mail et al accounts (eg 2 factor authentication) to prevent our addresses being abused. Given that we give out e-mail addresses to anyone who needs to contact us, I think the latter option (securing our email accounts) is the smarter one
2) instead of encrypting phone numbers and postal addresses, should we instead be challenging the requirement for online services to store them to begin with? If they have my email address, why do they also need my phone number? Postal address I can forgive a little more if there's a product that needs shipping or payments that need to be made.
Re: Slack was hacked
#174Earlier 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.
I get the feeling that you've never done this before and you don't understand the technical challenge and implications of the added complexity you propose here for an essentially free to low-price all-in-one communication online service.
Slack is not the NSA, encryption is not the answer to every security problem out there.
Re: Slack was hacked
#175Earlier quoted context omitted.
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…
You append the salt to the hash, and then re-hash it. Not exactly pretty, but it works.
Re: Slack was hacked
#176Earlier quoted context omitted.
Exactly!!! Encrypting user data should be a common practice like hashing passwords.
Third party authentication should be the norm. Leaving authentication to providers that absolutely know their shit , just like we leave payments to third party services. Of course, that requires a decent protocol, and Mozilla is doing the world a disservice in not marketing Persona better seeing as it's the right solution....
Re: Slack was hacked
#177Earlier quoted context omitted.
Coincidentally, I was just looking into your question; this should answer your concern. "Since every user has their own unique random salt, two users who happen to have the same password get different salted hashes. [If] the dictionary attack is foiled, the attacker cannot compute the hashes of every word in a dictionary once and then check every hash in the table for matches anymore. Rather, the attacker is going to…
running the top 10k passwords on each hash will likely get quite a few hits, and not take much compute time... the overlap to accounts that are owner/admin accounts is unknown.. just the same entirely possible. (not counting for slack's password complexity requirements)
The paper goes into estimated costs as well, but I'm not going to dig through it to figure out how much it would actually cost to run that hardware for a month straight. And of course it's talking about dedicated hardware, which Slack's hacker almost certainly doesn't have.
Re: Slack was hacked
#178Re: Slack was hacked
#179I 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…
Please do not do it: http://stackoverflow.com/questions/16891729/best-practices-s...
Re: Slack was hacked
#180"As part of our investigation we detected suspicious activity affecting a very small number of Slack accounts. We have notified the individual users and team owners who we believe were impacted and are sharing details with their security teams." Assuming the password hashes can't be reasonably reversed, what would have caused suspicious activity on some user accounts? Is this a situation where certain users may have…