3 ms·

still better than "password used by another account"

by amne 3y ago

lucb1e 3y ago
Not sure if serious. We need this. If you can guess someone else's password by accident, both of you need a password reset and that password needs to go on the denylist. Modern advice for strong passwords is having a length requirement and checking the input against a list of known passwords, for example using the HIBP partial hash API. (Any time you see forced expiration or complexity requirements, you're dealing with a legacy/cargocult system.)
- dragonmost 3y ago
  The server shouldn't even be able to know that a password is being reused as it should be hashed and salted there is no situation where this would be acceptable
  - Falmarri 3y ago
    You can hash them without a salt and store them in a set of passwords not associated to user accounts to enforce uniqueness without having to actually know the passwords
    - duskwuff 3y ago
      That still introduces a fairly serious vulnerability. The lack of salting on the "password uniqueness" database makes it a juicy target; an attacker with access to the database can attack those passwords, then try the ones which are known to be valid from there against the salted passwords in the user database.
      - actuallyalys 3y ago
        I wonder if there’s some way to mitigate this by either only keeping the uniqueness database long enough to identify duplicates and then deleting it or by using this on lower priority systems that people may reuse passwords from for your higher security one. In either case, the small number of bad passwords you would identify that you couldn’t come up with yourself or find on common password lists probably makes this a bad tradeoff.
        deleted 3y ago
        [deleted]
  - lucb1e 3y ago
    Ah yeah that's true, I forgot that it's computationally complex to check that against a whole user base
- actuallyalys 3y ago
  The safe way to do this is to check a password against a list of common passwords, as Jeff Atwood suggests [0] rather than against your other passwords. As other replies point out, you shouldn’t be able to compare your passwords’ plaintext to each other like you’re proposing[1]. [0]: https://blog.codinghorror.com/the-god-login/ https://blog.codinghorror.com/the-god-login/ [1]: I suppose you could salt and hash the user’s password against every other user’s password and their salt, but if you chose an appropriate password hash function and parameters, that would take infeasibly long. Edit: I missed that you essentially suggested this already. Sorry about that. However, I think the way Atwood explains it is useful.

still better than "password used by another account"

by amne 3y ago

still better than "password used by another account"

Not sure if serious. We need this. If you can guess someone else's password by accident, both of you need a password reset and that password needs to go on the denylist. Modern advice for strong passwords is having a length requirement and checking the input against a list of known passwords, for example using the HIBP partial hash API. (Any time you see forced expiration or complexity requirements, you're dealing with a legacy/cargocult system.)

dragonmost 3y ago
The server shouldn't even be able to know that a password is being reused as it should be hashed and salted there is no situation where this would be acceptable
- Falmarri 3y ago
  You can hash them without a salt and store them in a set of passwords not associated to user accounts to enforce uniqueness without having to actually know the passwords
  - duskwuff 3y ago
    That still introduces a fairly serious vulnerability. The lack of salting on the "password uniqueness" database makes it a juicy target; an attacker with access to the database can attack those passwords, then try the ones which are known to be valid from there against the salted passwords in the user database.
    - actuallyalys 3y ago
      I wonder if there’s some way to mitigate this by either only keeping the uniqueness database long enough to identify duplicates and then deleting it or by using this on lower priority systems that people may reuse passwords from for your higher security one. In either case, the small number of bad passwords you would identify that you couldn’t come up with yourself or find on common password lists probably makes this a bad tradeoff.
      - deleted 3y ago
        [deleted]
- lucb1e 3y ago
  Ah yeah that's true, I forgot that it's computationally complex to check that against a whole user base
actuallyalys 3y ago
The safe way to do this is to check a password against a list of common passwords, as Jeff Atwood suggests [0] rather than against your other passwords. As other replies point out, you shouldn’t be able to compare your passwords’ plaintext to each other like you’re proposing[1]. [0]: https://blog.codinghorror.com/the-god-login/ https://blog.codinghorror.com/the-god-login/ [1]: I suppose you could salt and hash the user’s password against every other user’s password and their salt, but if you chose an appropriate password hash function and parameters, that would take infeasibly long. Edit: I missed that you essentially suggested this already. Sorry about that. However, I think the way Atwood explains it is useful.