41–50 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.
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?
If you have great physical security at your home and don't trust the banks (e.g. their fee schedules), it might be a safer decision.
For most people, it's not.
Slack encourages 2-factor authentication: > Download and install either the Google Authenticator or Duo Mobile apps on your phone or tablet. Hey Slack, I don't have a smartphone. What am I supposed to do?
* You can buy a hardware token. https://www.duosecurity.com/product/methods/hardware-tokens
* You can have Duo call/text you every time you want to log in.
* You can use some other device you have that runs a mobile OS. I had Duo set up on my wifi-only iPad while I was using a feature phone for a few months a year ago. (I eventually gave up on that and got a smartphone, though.)
* You can buy a used/cheap smartphone, iPod Touch, or similar, install either the Google Authenticator or Duo app, and not use mobile service at all. You just need a bit of wifi to enroll.
* You can write an OATH client as a J2ME MIDlet. When I was using a feature phone, I spent some time figuring out how to compile J2ME apps in 2015, by piecing together ten-year-old tutorials. It works fine; if you want me to dig up details let me know. (Alternatively, someone may have written one already, but I didn't search very hard.)
* You can, technically, run an OATH client on your computer. But at that point, you take responsibility for your two-factor auth being slightly less than two-factor.
Earlier quoted context omitted.
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?
Yes we do, keep millions for our customers too; Bitcoin company here. :)
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!
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.
> 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. Is this true even when the attacker is specifically focusing on a single account, or is it only computationally infeasible to recover passwords for accounts in general?
"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 have to re-hash the entire dictionary anew for every salt. A determined attacker who has compromised the server will have to mount an entire new dictionary attack against every user's salted hash, rather than being able to quickly scan the list for known hashes." [0]
[0]: http://www.developerfusion.com/article/4679/you-want-salt-wi...
Earlier quoted context omitted.
My concern are the usernames, emails and phone numbers that were probably not encrypted
ultimately passwords can be changed; internal chat messages regarding personal and confidential data can not be taken back.
* 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 Row-Level Security
* Database server runs on own box in own network zone
* Send logs via write-only account to machine in different network zone. Monitor logs automatically, and have alerts.
* Pepper your passwords (HMAC them with a key in an HSM on the web server (then bcrypt). Don't store key in db). https://blog.mozilla.org/webdev/2012/06/08/lets-talk-about-p...
* Use a WAF that looks for SQL injections
* [Use real database authentication, per user. Not one username for everyone connecting to db. Yes, this is bad for connection pooling]