3 ms·

That seems like a really good way to handle it. Each account has a unique password, then, and it's only available to the admin. As long as the controller's code

That seems like a really good way to handle it. Each account has a unique password, then, and it's only available to the admin. As long as the controller's coded well, this seems like a great solution. (If anyone has any concerns, I'd love to hear them.)

swolchok 17y ago
Well, it doesn't sound bad, until you rephrase it to how it will actually be implemented: How about allowing the contents of the hash column in the database as the password? It only takes one incompetent engineer to sometimes store the raw password in the database, and it takes two to make that work to log in somewhere (presumably an easy defense is to only allow "verbatim logins" using something the same length as a hash).
- brown9-2 17y ago
  Also it would defeat the purpose of having passwords hashed, because a data leak would then expose people's account just as if you were storing the plaintext password.
  - mbrubeck 17y ago
    At the one place I worked where this was actually implemented (spoof a user by entering a hashed password), it only worked from inside the firewall, to mitigate this risk. According to the interview, Facebook has similar restrictions on user spoofing.
ehsanul 17y ago
There's a security issue with this idea obviously. If I'm not mistaken, the whole point of hashing passwords is so that a loss of the user database in some way does not compromise any accounts. You might as well store passwords in plain text if you allow hashed passwords as passwords. It might just be acceptable though, since almost nobody would guess that a hashed password would be accepted as a password. That is, unless they have access to the controller source code too, and check it out (as you'd assume since the database itself has been compromised). A better solution may be to create a second temporary password, hashed in another field in the database, and wipe it out when you're done. It's fine to use an extremely long master password too, making sure it's stored as a bcrypt hash or something. Just run the calculations to make sure that it couldn't be broken in 2^999 years.
- charliepark 17y ago
  Hrm. You're right. Secondary benefit of the hashing is so that a user's re-used password isn't compromised for other sites, but ... yeah. Your dynamically-generated temporary password is probably a better way to go about it. Or the hashed master password. Thanks.

swolchok 17y ago

Well, it doesn't sound bad, until you rephrase it to how it will actually be implemented: How about allowing the contents of the hash column in the database as the password? It only takes one incompetent engineer to sometimes store the raw password in the database, and it takes two to make that work to log in somewhere (presumably an easy defense is to only allow "verbatim logins" using something the same length as a hash).

brown9-2 17y ago
Also it would defeat the purpose of having passwords hashed, because a data leak would then expose people's account just as if you were storing the plaintext password.
- mbrubeck 17y ago
  At the one place I worked where this was actually implemented (spoof a user by entering a hashed password), it only worked from inside the firewall, to mitigate this risk. According to the interview, Facebook has similar restrictions on user spoofing.

ehsanul 17y ago

There's a security issue with this idea obviously. If I'm not mistaken, the whole point of hashing passwords is so that a loss of the user database in some way does not compromise any accounts. You might as well store passwords in plain text if you allow hashed passwords as passwords. It might just be acceptable though, since almost nobody would guess that a hashed password would be accepted as a password. That is, unless they have access to the controller source code too, and check it out (as you'd assume since the database itself has been compromised). A better solution may be to create a second temporary password, hashed in another field in the database, and wipe it out when you're done. It's fine to use an extremely long master password too, making sure it's stored as a bcrypt hash or something. Just run the calculations to make sure that it couldn't be broken in 2^999 years.

charliepark 17y ago
Hrm. You're right. Secondary benefit of the hashing is so that a user's re-used password isn't compromised for other sites, but ... yeah. Your dynamically-generated temporary password is probably a better way to go about it. Or the hashed master password. Thanks.