Comment by tptacek | Hacker News Reader

Comment by tptacek | Hacker News Reader

Parent Full thread

Argh. The whole concept of "peppers" begs the question. If you can keep attackers from learning a "pepper", keep the attackers from learning the password hashes too. Problem solved.

The reality is that attackers learn password hashes when they pop a database. They don't get them from XSS attacks an they don't get them from CSRF bugs. When attackers pull password hashes, they've got the database. When attackers get your database, they have your server. It's over. Stop pretending. Your database server has vulnerabilities, even in the (extraordinarily unlikely) event that you've configured it perfectly so that the ability to issue a SQL query doesn't hand over the filesystem to an attacker. But more importantly, your app server has a whole new class of vulnerabilities once it can't trust the database anymore.

People who talk about relying on secret keys in their password hashing schemes are doing the world a disservice. Just use a strong adaptive hash and move on.

I agree - I prefaced the whole thing with the assumption that we have a hardened black box that we want to split authentication responsibilities with and can trust to not be compromised, since that's a fundamental assumption of the honeywords concept. If the whole thing is compromised, it's game over, no matter how your auth scheme is split up.

> When attackers get your database, they have your server.

Could you please link me to more info on this escalation vector?

I don't have it in the context of an escalation, but if they can get the database to make a new stored procedure,

http://www.mssqltips.com/sqlservertip/1263/accessing-the-win...

then they can usually do a very large amount of things

>If you can keep attackers from learning a "pepper", keep the attackers from learning the password hashes too. Problem solved.

Isn't it easier to protect one password than protect millions that have to be connected somehow to an internet connected database.

Your pepper could be completely off-internet requiring physical access. That's not likely to be true of your password hashes. You'd likely have to wait a couple of days to get an account verified this way so that passwords submitted could be physically moved to the "pepper pot" [I made that up] and peppered and hashed codes could be returned.

"If you can take one step, why can't you take 10 million? Problem solved."

Tenability of such a scheme could vary!

No, your "pepper" cannot be completely off-internet requiring physical access, since it's required to actually validate an incoming password submission against the password hash.

"Tenability of such a scheme could vary!"

I believe the tenability of your scheme varies from "unpossible" to "suitable for sites with such low traffic that the sysadmin can manually verify every login".

If you are running it through an HSM, wouldn't that accomplish this goal? Take a code, encrypt with HSM, then do hashing, etc. You would have to hack the server then compromise the HSM in order to do an offline attack.

Reply on news.ycombinator.com