Hacker News Reader

Comment by tlrobinson | Hacker News Reader

Couldn't you simply change the app to accept the password hashed or unhashed? e.x. change

    ... WHERE user.password = hash(input)

    ... WHERE user.password = hash(input) OR user.password = input

Or was your point that this would eliminate the benefits of using an adaptive hash like bcrypt to slow down brute forcing?

View on HN

Yes, but this would mean you were storing the unhashed passwords in the DB. When your DB is compromised, everyone's password is exposed, likely along with their email. In this world of frequent password reuse, that is pretty much game over.

I don't know why your answer was downvoted, you are spot on.

No he's absolutely not, there's a massive difference between having someone's password that's been reused on X number of sites and having a hashed version of a password that's only valid on one site.

Also if you wanted to make it secure you could restrict hash passwords to work only from certain IP addresses so you either have to be using a company internal machine or say the IP addresses from a police station.

>No he's absolutely not

He was referring to my rebuttal, which was initially downvoted for some reason.

In the example above, the ".password" field is the hashed password. I think 'tlrobinson' was trying to point out that sites only have to keep plaintext passwords if that's what they're given. If, when you first signed up for a site that uses tlrobinson's technique, you provided the hash of your password (instead of your password itself), then the site would never have access to the plaintext (but you'd be able to use the plaintext to log on at a later date since the SQL query checks the ".password" field against hash(input).)

Yes, close, but not exactly what I meant. The password would still be provided in plaintext upon registration, but the application would immediately hash and store it. Then the user can login with their password, which gets hashed and compared to the hashed password in the database. Alternatively the hash can be handed over if required and also used as the password since we also compare the unhashed input to the hashed stored password.

No, you misunderstood. My example was poor, the password in the database is hashed:

    ... WHERE user.hashed_password = hash(input) OR user.hashed_password = input

So the user can provide their password which gets hashed and compared to the stored hash, OR the hash can be given to law enforcement if required and can be used in place of the real password.

This solves the problem of passwords being stored in plaintext (indeed a problem with frequent password reuse) while apparently getting around this silly French law.

Sure if the database is compromised anyone will be able to login to anyone's account, but the database is compromised so who cares?

You could do this without allowing the hashes to act as passwords directly by establishing a "skeleton key" approach:

    WHERE user.password = hash(input) OR hash(user.password + skeleton_key) = input

If the police want to log into a user's account without their password, they combine the hash of their password with the skeleton key, hash that, and submit it as the password.

Of course, now you have to keep skeleton_key a secret. Presumably you wouldn't store it in the same database as the password hashes, so losing the database wouldn't immediately grant access to everyone's account.

I'm not claiming this is particularly secure. In fact, it's kind of the opposite: it's intentionally adding a back door to your authentication system. But at least it's a door rather than a gaping hole :)

Reply on news.ycombinator.com