2 ms·

You cannot gain access to a system with the hashed passwords, unless you modified the system to accept them. In that case you could just modify the system to no

You cannot gain access to a system with the hashed passwords, unless you modified the system to accept them. In that case you could just modify the system to not require a password at all. In fact, that is in a sense what you would be doing anyway. It does outlaw hashed passwords in practice. EDIT: as others have pointed out, you could simply store the plaintext passwords in another file with greater security, and have hashed ones in the DB. An even better option would be simply to get the hell out of france. Or, start a consulting business in france to help people comply with this, and rake it in.

praptak 16y ago
It strongly depends on the wording of the law and on the usual million things that affects how laws are interpreted. Maybe just providing a freshly generated password that gives access to the account in question is enough to satisfy this law?
tlrobinson 16y ago
Couldn't you simply change the app to accept the password hashed or unhashed? e.x. change ... WHERE user.password = hash(input) to ... 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?
- JonnieCache 16y ago
  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?
- kwantam 16y ago
  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 :)

praptak 16y ago

It strongly depends on the wording of the law and on the usual million things that affects how laws are interpreted. Maybe just providing a freshly generated password that gives access to the account in question is enough to satisfy this law?

tlrobinson 16y ago

Couldn't you simply change the app to accept the password hashed or unhashed? e.x. change ... WHERE user.password = hash(input) to ... 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?

JonnieCache 16y ago
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?
kwantam 16y ago
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 :)