Hacker News new | past | comments | ask | show | jobs | submit login

The post notes that the breached database is the user table, which would not contain chat history. I agree that making this abundantly clear makes sense.



This makes it sound like other data was compromised for some specific users. Since they didn't go into how they know it was only for only these users, I'm not very confident about this.

> 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. Unless you have been contacted by us directly about a password reset or been advised of suspicious activity in your team’s account, all the information you need is in this blog post.


This is actually an interesting point. A compromised user table could conceivably be used for all sorts of nefarious purposes. If the attackers "having access" to the information in that table includes the ability to modify that table, then it is pretty much open season on Slack. For example, an attacker could replace a target user's password-hash with a hash that the attacker knows the plaintext of. Depending on the implementation of the random salt, the attacker may have to replace the salt as well. Then, the attacker logs in as the user, downloads the desired chat history, logs out, and sets the password hash to the original. Not enough information was really given in the blog post, but by the sounds of it, some teams experienced more targeted attacks.


I would suspect things like "being used from a completely new country" or something similar. Could be those are the accounts with weak passwords that the attacker tried the top 10,000 passwords against.


If you get the user table, you can log in. If you can log in as (some) users. If you can do that, you can see (some) chat history.

edit you can log in if and when you crack some of the hashes.


Incorrect. You can't login with a password hash, you need a password.


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?


No, a simple password like "slack123" should be easy to crack with any usable password storage method.


Not necessarily easy. If they're using a decently high cost for their use of bcrypt, we're talking hours to days (or more) per user, even when only considering weak passwords like that.


True, I guess it's possible to crack a password for a single user, especially one with a weak password. I was more thinking that it's unlikely they'll be able to crack the passwords of everyone who was in their database, and given that Slack has so many users it's unlikely for any single person that his/her password will be cracked.

Of course, even if they can't steal everyone's passwords, maybe the hackers will try to crack the passwords of higher profile targets.


GPUs are fast enough to crack a very large percentage of passwords in a short time by brute force, if a simple algorithm was used, even with salt.


With a separate salt for each password not even the NSA can crack that (that we know of). With a single salt for all of them, maybe.


Sure they can. Anyone can. It just takes a long time per password to crack (that time is a function of the cost/# of rounds of the hashing function).


No kidding. That's why I put (some) users. Because brute-forcing the hashes will give you some password plain texts.

I guess that I missed a step in the explanation where you attack the hashes.

However I see that they say that they are using some best practices (bcrypt, "salt per-password") so this attack will be largely mitigated.


Depends on the nuances of the system. If you can pass-the-hash, you can get in.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: