Since the recent problems with GitHub and Twitter:<p>- https://www.bleepingcomputer.com/news/security/github-accidentally-recorded-some-plaintext-passwords-in-its-internal-logs/<p>- https://www.bleepingcomputer.com/news/security/twitter-admits-recording-plaintext-passwords-in-internal-logs-just-like-github/<p>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.<p>- 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<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'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)<p>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