If you have a reset_token you still can log in, even when passwords are hashed. Likely reset tokens were stored in the same table
Slack was hacked
351–360 of 526 posts
Re: Slack was hacked
#352Earlier quoted context omitted.
> 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 read your question as comparing the originally-proposed pepper approach vs the encryption approach, and I said the question was irrelevant because both approaches have the identical risk that the app server is compromised, but only the originally-proposed pepper approach has the risk that it's not actually secure (e.g. because naïvely composing hash operations may be bad, and adding static bits to passwords may also be bad).
But upon reflection I believe you were instead using the term "pepper" to include the encryption approach as well and merely trying to question whether the added security of requiring an app server compromise is worth the risk that you still screw it up somehow. And to that I'd say that it's not difficult to apply an existing block cipher algorithm when storing/retrieving password hashes so I think the risk there is low.
> Why is everyone panicking that it's hard to do?
Everybody's panicking because the originally proposed pepper implementation is a really bad idea. That approach has not been researched for security implications, and there are many reasons to believe that composing hash operations without using a specially-defined operation like HMAC is bad, and adding static bits to the salt or password (e.g. if you use 'pepper.salt' for the scrypt salt or 'pepper.password' for the password) is also bad.
However, I believe the approach of using a block cipher to encrypt your hashes with an app-wide password is reasonable. It's not composing operations badly (encrypting a 256-bit string, or whatever scrypt emits, is perfectly reasonable given a secure key) or otherwise providing an attack vector on the hash algorithm.
The biggest risk I can see with this approach is you have to make sure the pepper is stored securely on your app server, never visible to the database server (and never accidentally committed to an open-source repo, if you're using an open-source server). Not just that, but you have to make sure that you don't accidentally lose it either (or you'll have instantly lost all your accounts). But this is a solvable problem.
Re: Slack was hacked
#353[deleted]
Re: Slack was hacked
#354We've been waiting for over a year for Slack to create a self-hosted version that we can deploy to our intranet specifically because we can't expose ourself to things like this. They've kept insisting that it's around the corner but it doesn't seem to be happening. Hopefully this will spur them to prioritize self-hosted Slack.
Re: Slack was hacked
#355Earlier quoted context omitted.
> 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…
Because it's harder to implement and easier to mess up than using standard encryption, and has unknown characteristics due to the fact that it's rolling your own crypto. Why would you spend the time and effort to implement it when you can do something that is objectively better in every way?
Re: Slack was hacked
#356[deleted]
Re: Slack was hacked
#357Got the email from them about the issue, as a Slack user. Also got 2 other duplicate emails from them (which went into the same Gmail conversation, since same subject), that were empty. Seen this a few times for other services, not sure why it happens.
They probably send a message to you for every team you're on.
Could be, thanks.
Re: Slack was hacked
#358Earlier quoted context omitted.
Huh? This is the first I've heard about this, and searching for "Authy concatenation bug" isn't turning up anything useful.
Here's the write-up from Homokov. The guy is a pen-testing genius: http://sakurity.com/blog/2015/03/15/authy_bypass.html But if you just want the money shot: http://sakurity.com/img/smsauthy.png Yes. Typing '../sms' in the field bypassed the 2nd factor. Just, wow.
Huh. Well now I know. Thanks!
Amazing what you can do with improperly-implemented input sanitation :)
This probably could've been prevented by disallowing non-number inputs, no?
Re: Slack was hacked
#359What the flippin' heck is Slack? I received an email today telling me of this event. Then I had to recover my team and my password, then deactivate my account, and I have never seen this website until I saw that email. Looking at my team, it seems to be created by the guys at , or someone using that website as a base for accounts. That one has a people page and there are links to various places. Now, someone has created an account in my name using my main e-mail address and I have not been e-mail-notified for a confirmation of account, or at least not have been notified that an account is created. Apparently either these lot cannot write proper emails that can pass through spam filters or they expressly allow this sort of malicious account creation. Not surprising that they got hacked.
Re: Slack was hacked
#360Earlier 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…
Once you use Encryption, it's no longer pepper, it's encryption with weak key storage (hard-coded). At that point, genuinely, why not just follow best practices and store the key securely (e.g. using an HSM)?
Certainly storing your key with an HSM is superior and protects against a slightly large class of attacks, but in terms of getting the same protection as salt+pepper was designed for (limiting the damage of a DB-only compromise), encryption, even with weak key storage, is superior. Adding an HSM is just ways we can improve that even further (which aren't really even feasible with the salt+pepper idea).