Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Slack was hacked

slackhq.com

Post reply on HN
Print view View original

301–310 of 526 posts

Re: Slack was hacked

#301

Post by elchief »

specialk wrote: post #182
FiloSottile wrote: post #130

I 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…

Is there any significant evidence that peppering passwords helps? I've seen arguments for and against peppering out on the big bad internet. Everyone has opinions but there are few people's opinions about crypto that I actually trust. The best article I've seen against this technique is by ircmaxell [0]. Nicely summed up in this sentence "It is far better to use standard, proven algorithms then to create your own to…

It can help in the following scenarios:

1. Hacker steals db but does not compromise web servers (because the hmac pepper key lives on the web servers and not in the db)

2. Hacker can run SQL Injection via web server, but cannot otherwise access web server memory/process

3. HMAC key is stored in a hardware security module and hacker cannot gain physical access

Re: Slack was hacked

#302

Post by rudolf0 »

patcon wrote: post #156
rudolf0 wrote: post #100

Earlier quoted context omitted.

If you're small, cloud may be better, but if you're large it often isn't.

Large does not mean you have better security, as I understand. (see Sony)

Yes, but you at least have the money and resources available to have better security. If you choose to squander those resources and not dedicate a large enough budget to your security department, that's your fault.

Small companies typically can't afford competent and professional security analysts, engineers, penetration testers, and auditors.

Re: Slack was hacked

#304

Post by BrainInAJar »

Klinky wrote: post #120

Was an admin account compromised in a situation where 2FA could have prevented the unauthorized access? If that's not what happened, then 2FA seems a bit hand wavy if it's not directly related to this security incident.

I actually am coming to the conclusion that 2FA is dangerous. It's recommended any time there's any kind of breach as if it were some kind of panacea for security, when in most cases the cause of a security breach is a database intrusion.

2FA keys are stored unencrypted so if the db is breached they're already cleartext (no boil the oceans bcrypt collision needed) and the extra layer of security theatre from 2FA only encourages bad practices like password reuse & easy passwords.

Re: Slack was hacked

#305

Post by BrainInAJar »

dragonwriter wrote: post #148
dmazin wrote: post #134

Why do I have to install Google Authenticator some sort of other app for 2factor here? Why can't you send me a text like everyone else does? EDIT: Slack responded that they do not support SMS yet .

Because SMS is not even remotely a secure communication channel, and the point of two factors is proof of possession of two different classes of things (that you have some device and that you know some secret), and using an insecure channel to send a message weakens the proof of the have half of that, in much the same way as using a weak or published password weakens the know half. Ideally, you want as strong as prac…

> Because SMS is not even remotely a secure communication channel

Neither is 2FA, it's a key stored completely unencrypted in both your phone and the the host's db.

Re: Slack was hacked

#306

Post by rnovak »

EugeneOZ wrote: post #300
FiloSottile wrote: post #130

I 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…

Recommendations related to Security, should start from words "I'm {name}, known expert in IT Security, my works can be found here: {url}". Otherwise such advices should be ignored.

Could not agree more. In fact, here is Bruce Schneier's quote[1]:

    Anyone can invent a security system that he himself
    cannot break. I've said this so often that Cory Doctorow 
    has named it "Schneier's Law": When someone hands you a  
    security system and says, "I believe this is secure," the  
    first thing you have to ask is, "Who the hell are you?" 
    Show me what you've broken to demonstrate that your
    assertion of the system's security means something.
[1] https://www.schneier.com/blog/archives/2011/04/schneiers_law...

Re: Slack was hacked

#307

Post by mmatants »

Klinky wrote: post #120

Was an admin account compromised in a situation where 2FA could have prevented the unauthorized access? If that's not what happened, then 2FA seems a bit hand wavy if it's not directly related to this security incident.

Agreed: 2FA protects against password leaks on other sites from being applied to the system in question. In this case it would have been more reassuring to hear them disclose what was the attack vector (e.g. social engineering, email trojans, etc) and explain how they will reduce the chance of a similar compromise in the future.

Re: Slack was hacked

#308

Post by alexdowad »

Zolmeister0 wrote: post #247

Dear All - Your passwords should be considered compromised. Hashing is merely a deterrent, it does not prevent cracking.

That's exactly what I thought the moment I read the post. The fact that Slack used bcrypt is good, and if they used a high number of iterations that's better, but neither will help you if your password happens to be on the crackers' list of 10,000 most common passwords.

Re: Slack was hacked

#309

Post by worklogin »

eridius wrote: post #297
JackC wrote: post #250

Earlier quoted context omitted.

ircmaxell makes a good point in that comment -- not that the concept of a pepper doesn't work, but that a two-way encryption function is a better choice than a hash function for applying the pepper. Your pepper will be a long, random key that is known to your app server but not your database server. If you store passwords as: bcrypt(bcrypt(password, salt), pepper) then you spend a lot of cycles bcrypting your long, r…

> what's the risk that someone gains access to your DB but not your app server, vs. the risk that in implementing the pepper, you somehow screw up and store something easily crackable? The question is irrelevant anyway, because if someone gets access to your app server, they get the secret in both cases (pepper and encryption). So the first risk there is present in both cases, which just makes this a static "what's t…

The question is not irrelevant. It's blindingly obvious that salt+pepper protects against DB-only attacks. Injection that does a DB dump, or vulnerabilities in the DB server that don't exist in the app.

So yes, S+P protection won't save you if the app server is completely compromised, but it does protect you in case DB only is.

And the ability to S+P seems pretty simple to implement and document. Why is everyone panicking that it's hard to do?

Re: Slack was hacked

#310

Post by worklogin »

EugeneOZ wrote: post #300
FiloSottile wrote: post #130

I 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…

Recommendations related to Security, should start from words "I'm {name}, known expert in IT Security, my works can be found here: {url}". Otherwise such advices should be ignored.

Could not disagree more. Perhaps one should use their own reasoning and the ability to peer-review in conjunction with 'appeal to experience' rather than shut out discussion.
Post reply on HN