
Why doesn't OWASP recommend to hash passwords both on the client and the server? - lmcarreiro
Since the recent problems with GitHub and Twitter:<p>- https:&#x2F;&#x2F;www.bleepingcomputer.com&#x2F;news&#x2F;security&#x2F;github-accidentally-recorded-some-plaintext-passwords-in-its-internal-logs&#x2F;<p>- https:&#x2F;&#x2F;www.bleepingcomputer.com&#x2F;news&#x2F;security&#x2F;twitter-admits-recording-plaintext-passwords-in-internal-logs-just-like-github&#x2F;<p>I was wondering, why isn&#x27;t the best practice to bcrypt the password both on the client and the server? Since I won&#x27;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.<p>- In case I log the entire request when an exception is thrown, if an exception happens in the login&#x2F;signup request, I would never get access to the user plaintext password<p>- 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&#x27;t have access to the plaintext password, so it would never compromise the user&#x27;s account in other sites and services (even for those users that reuse their passwords)<p>Cross-posted from my stackoverflow&#x27;s question: https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;50701933&#x2F;why-doesnt-owasp-recommend-to-bcrypt-the-password-both-on-the-client-and-the-se
======
thebrain
Because then you'd have to expose how you did the hashing.

~~~
lmcarreiro
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.

