Why doesn't OWASP recommend to hash passwords both on the client and the server?

2 points by lmcarreiro 7 years ago | 2 comments

Since the recent problems with GitHub and Twitter:

- https://www.bleepingcomputer.com/news/security/github-accidentally-recorded-some-plaintext-passwords-in-its-internal-logs/

- https://www.bleepingcomputer.com/news/security/twitter-admits-recording-plaintext-passwords-in-internal-logs-just-like-github/

I was wondering, why isn't the best practice to bcrypt the password both on the client and the server? Since I won't change anything that already are the best practices for the server side (salt, strong hash, HTTPS), it can only be safer. The server would consider the already hashed password as the password, and would hash it again before store it.

- In case I log the entire request when an exception is thrown, if an exception happens in the login/signup request, I would never get access to the user plaintext password

- I know that if somebody have access to these only-client-side-hashed passwords, either by MITM (which a lot of companies do in their private networks replacing the SSL certificates) or by logs or a malicious server administrator, they would be able to use it to authenticate in my site, but wouldn't have access to the plaintext password, so it would never compromise the user's account in other sites and services (even for those users that reuse their passwords)

Cross-posted from my stackoverflow's question: https://stackoverflow.com/questions/50701933/why-doesnt-owasp-recommend-to-bcrypt-the-password-both-on-the-client-and-the-se

thebrain 7 years ago |

Because then you'd have to expose how you did the hashing.

lmcarreiro 7 years ago | |

But I'll expose just how I hashed on client side, not how I hash on the server side. The only purpose of this is to protect the plaintext password of the user. I won't stop doing anything that I already do on the server site to protect these passwords.