Can we go back to IRC now, please! Slack is not only distracting, proprietary, but it is also pretty expensive. Let the mere mortals use it, but we should stay away!
That cow left the barn a while ago.
Oh, yeah? You haven't heard of Let's Chat [0], for example?
Looks like they require Google Authenticator or Duo Mobile app to do two-factor auth. I'm not interested. Why can't they be like Github and just send me a text message? I don't want a dependency on some other company's product to make Slack more secure.
> 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 pani…
I've already seen one person in this thread taking "S+P" literally, and suggesting `bcrypt(cost, salt + pepper, password)`, which has a very obvious and critical problem. Other "peppering" schemes in the comments here also have significant weaknesses. So yes, even a simple idea like this is easy to botch in implementation -- even if the implementation is just a one-line change!
For those that store the user tables in the same db as everything else, what is the big deal about protecting passwords in particular? The attacker already has much more. If it is because of password re-use then that is what should be prevented.
How does one discover that they were hacked? The post states that the breach occurred during February, and this is the end of March... did it just take them a long time to react and write a post about it, or did they likely discover after the fact? If so, how?
True story: Log into server. Why is server slow? Run `top`. Hmm, `./exploit` is consuming 99% CPU...
Slack has now sent me 6 e-mails about this, to the same address :( They have different names associated in each one (i.e. some have my last name, some have an alias, etc), but all to the same target e-mail address.
See my other comment on the same point in this thread.
Is this actually the sort of people that get attracted to HN? Thinking of others as "mere mortals" and yourselves as gods? Sad picture.
Probably not in that condescending way, but it is useful to keep in mind that people are fundamentally different from you. The trouble is when you think they are inferior beings (their tech skills on the other hand are inferior, no reason to not state that plainly). For what it is worth I have coded Erlang at work and am quite partial to cat pictures, myself.
Well, let's talk about the reality now. By definition, most people are mediocre, not very smart, not very healthy, not very pretty, etc. Most! That's whom Slack targets - most.
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…
From your blog:
hashed_password = scrypt(password, salt + pepper)
store(hashed_password, salt)
Why aren't you storing the (N, r, p) parameters too? Is it because your library's "scrypt" function automatically encodes all the parameters it uses in the returned string? (This is not hypothetical; it's exactly what many scrypt implementations do.) If so, congratulations: You just stored the pepper bits in your database, because they're part of the "hashed_password" value.
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.
Is your reasoning that of an experienced, competent cryptographer? Because mine isn't. I'm not a cryptographer's peer, either, and I'll bet you aren't either. Step one--nobody said step all, but step one--is establishing your bona fides to determine whether it is worth burning cycles on your idea, because proving or disproving cryptography is very hard and very time-consuming. It is a heuristic that, generally speaking, works pretty well.