121–130 of 526 posts
> No financial or payment information was accessed or compromised in this attack. This wouldn't be my first concern. It would be all of the confidential communication that happens within slack.
Agreed. The content of the chat's would be potentially much more important in my mind.
Earlier quoted context omitted.
Not sure why this is being downvoted. Setting up IRC on a .onion isn't even difficult. Setting it up with SSL is only a touch harder.
Setting up an ircd is not a bad idea. Then we just need to find the ircd and client that does what Slack does. (Which is totally possible, but I'm not sure it exists?)
I remember "SILC" which is not IRC, but if I remember correctly it had this. Mainly when you join a room, you should not get tabula rasa. You enter into some context, and if the last message was posted 4 days ago, your context starts 4 days ago, and the datestamps all reflect this.
There are other features of Slack that make it worth using, but this is the one thing I don't know if IRC can support at all, that I see every other serious chat system doing.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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.
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.
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....
Literally was arguing with someone like two days ago that using Slack for sensitive data was a bad idea, guaranteed to blow up in your face sooner or later. Nothing sweeter than "I told you so".
Earlier 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.
Host your own IRC if you care about the privacy and security of your communication. There is no reason why you can't take 10min to setup a IRC with SSL on your own. Yes, Slack is awesome, lots of features, but it's not yours!
Agree with you in one sense of being responsible for your own security, but by this logic I should keep all my money under the mattress instead of the bank, no?
Can you say the same about cloud services?
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…
Why would you assume that? There are plenty of ways to hack into stuff without sql injections.
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 simple, free and you can retroactively apply it.
EDIT: I addressed some of the points raised in this thread here https://blog.filippo.io/salt-and-pepper/#editedtoaddanoteonr...