Is there any way to hash a password with bcrypt before sending it with POST method?

Question

I want to know if there is way to hash a password with bcrypt, before i send it through the POST method from the login to the processing page, to improve the security of login script. I can not use SSL protection to do so.

Answer 1

Unfortunately, even if you did what you propose, it would still not result in a secure connection, thus rendering it vulnerable to a Man in the Middle attack. As discussed in the below comments, any hashing you do client-side renders the password pointless as it will require you to send the hash over the wire, to compare to another hash server-side. The attacker (MitM) could just use the hash to authenticate in this case.

If you want secure communication, you must (at least) implement TLS/SSL.

Answer 2

If you hashed a password with bcrypt, given a sufficiently strong password, and a salt, the password would be safe.

If the hash that was passed in didn't match the hash on the server, you could refuse access.

However, the main problem with your design is that now the password is no longer required to gain access to the system. The hash now becomes all that's needed to authenticate. The hash has thus become a suitable replacement for the password. Well, you've just passed that pseudo-password in the open, unencrypted, to an unverified server.

Passwords should be hashed before they are stored on the server using bcrypt or something similar. However, passwords should generally be passed in to the server (in clear text over an encrypted connection) and hashed there so that you can ensure that the client actually knows the password.

One alternative to that method, and instead of SSL, that you might consider is Digest authentication, but this only works because every call to the server is re-authenticated. If you use any kind of token based session, it could be available to replay and MitM attacks, so it must be encrypted. Also, Digest authentication is kind of old, and not as cryptographically secure as TLS, and there's no server identity verification, so we still end up back at HTTPS (SSL/TLS).

HTTPS (SSL/TLS) provides server identify verification and provides full end to end encryption, which is what you should use. You could mimic all the protections that SSL provides, but it seems like a lot of work trying to do something that's already there and implemented so easily.