3 ms·

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

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.

verysimple 16y ago
I don't know why your answer was downvoted, you are spot on.
- mattmanser 16y ago
  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.
  - JonnieCache 16y ago
    >No he's absolutely not He was referring to my rebuttal, which was initially downvoted for some reason.
- deleted 16y ago
  [deleted]
deleted 16y ago
[deleted]
profquail 16y ago
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).)
- tlrobinson 16y ago
  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.
tlrobinson 16y ago
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?

verysimple 16y ago

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

mattmanser 16y ago
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.
- JonnieCache 16y ago
  >No he's absolutely not He was referring to my rebuttal, which was initially downvoted for some reason.
deleted 16y ago
[deleted]

deleted 16y ago

[deleted]

profquail 16y ago

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).)

tlrobinson 16y ago
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.

tlrobinson 16y ago

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?