4 ms·

A password manager provides the exact same benefits as the website hashing the users password client side with a salt - before sending the password as per usual

A password manager provides the exact same benefits as the website hashing the users password client side with a salt - before sending the password as per usual (over SSL and then hashing the hashed password server side also). Why is this not done?

ec109685 7y ago
Huh? If I log out, how does the website let me log in again?
- tomglynch 7y ago
  Insert your password, it is appended with a salt and hashed, and then sent to the server which logs you in.
  - ec109685 7y ago
    What is the salt based on?
shakna 7y ago
Then your password is just the hash and salt. And presumeably you're generating those with JavaScript, which adds a surface to target to exfiltrate passwords. No need to get into the server, just inject some JS or redirect a CDN or... It doesn't actually add any security is the short story.
- tomglynch 7y ago
  > Then your password is just the hash and salt. Yes, and by that it appears random. Which is exactly what we want and what password managers provide. > just inject some JS or redirect a CDN or... This is the case anyway with regular passwords. > It doesn't actually add any security is the short story. Are you sure?
  - shakna 7y ago
    > Yes, and by that it appears random. Which is exactly what we want and what password managers provide. Good sources of randomness, that aren't susceptible to side-channel attacks have only really appeared in browsers (Crypto.getRandomValues) in March of _this_ year. Random is only good if it is a decent CRNG, and we haven't had time to roadtest if we can rely on that yet. Bad random is predictable, in which case you're removing security. > Are you sure? Yes. You're _adding_ a platform that can be attacked, but not introducing anything that is more secure than what is already possible.
    - tomglynch 7y ago
      I don't see what security we would be removing. I am for keeping SSL and server side hashing. I am just suggesting the addition of client side hashing also.
glitch003 7y ago
I do this with the sites I admin. I don't know why it's not more widespread.
pjc50 7y ago
If I key in the same password "PAssword123" for site A and site B, it makes absolutely zero difference if it's hashed before sending on site A if site B is storing it in plain text, because once retrieved from site B it can be used to log in to site A regardless of A's password handling process. The only way round this is to make sure that B doesn't have any information which can be used to compromise A, by sending the password from an external program. (You could just about achieve this from client-side salt+hash as an external program instead of a password manager, but then it's a big pain to change passwords when B is compromised.)
- tomglynch 7y ago
  I'm stipulating that we use a salt, so the (password+websitesUniqueSalt) equals a different hash each time.
  - smolder 7y ago
    Most people wouldn't do that because it's effectively redundant if you trust TLS and that the server is not compromised. However I think your proposed technique would be useful in cases where TLS is broken or the server is in some way compromised, running on low trust hardware, etc. So it's a good precautionary measure. Grandparent is also right that your users password can still be compromised on other services, giving an attacker a way into your own. Password managers don't have that problem.

ec109685 7y ago

Huh? If I log out, how does the website let me log in again?

tomglynch 7y ago
Insert your password, it is appended with a salt and hashed, and then sent to the server which logs you in.
- ec109685 7y ago
  What is the salt based on?

shakna 7y ago

Then your password is just the hash and salt. And presumeably you're generating those with JavaScript, which adds a surface to target to exfiltrate passwords. No need to get into the server, just inject some JS or redirect a CDN or... It doesn't actually add any security is the short story.

tomglynch 7y ago
> Then your password is just the hash and salt. Yes, and by that it appears random. Which is exactly what we want and what password managers provide. > just inject some JS or redirect a CDN or... This is the case anyway with regular passwords. > It doesn't actually add any security is the short story. Are you sure?
- shakna 7y ago
  > Yes, and by that it appears random. Which is exactly what we want and what password managers provide. Good sources of randomness, that aren't susceptible to side-channel attacks have only really appeared in browsers (Crypto.getRandomValues) in March of _this_ year. Random is only good if it is a decent CRNG, and we haven't had time to roadtest if we can rely on that yet. Bad random is predictable, in which case you're removing security. > Are you sure? Yes. You're _adding_ a platform that can be attacked, but not introducing anything that is more secure than what is already possible.
  - tomglynch 7y ago
    I don't see what security we would be removing. I am for keeping SSL and server side hashing. I am just suggesting the addition of client side hashing also.

glitch003 7y ago

I do this with the sites I admin. I don't know why it's not more widespread.

pjc50 7y ago

If I key in the same password "PAssword123" for site A and site B, it makes absolutely zero difference if it's hashed before sending on site A if site B is storing it in plain text, because once retrieved from site B it can be used to log in to site A regardless of A's password handling process. The only way round this is to make sure that B doesn't have any information which can be used to compromise A, by sending the password from an external program. (You could just about achieve this from client-side salt+hash as an external program instead of a password manager, but then it's a big pain to change passwords when B is compromised.)

tomglynch 7y ago
I'm stipulating that we use a salt, so the (password+websitesUniqueSalt) equals a different hash each time.
- smolder 7y ago
  Most people wouldn't do that because it's effectively redundant if you trust TLS and that the server is not compromised. However I think your proposed technique would be useful in cases where TLS is broken or the server is in some way compromised, running on low trust hardware, etc. So it's a good precautionary measure. Grandparent is also right that your users password can still be compromised on other services, giving an attacker a way into your own. Password managers don't have that problem.