Return to Answer

When you hash passwords on the client, the shared secret between client and server is no longer the cleartext password but the hash of the cleartext password. Your password is no longer monkey, your password is now $2a$04$RuNMmxnNakaesRjxjI3IAO70b2zK8lb5eRLb./huDLJ0OkWC0ikGm (bcrypt hash of "monkey"). The server would then hash this hash again and compare it to the hash-hash it already has in the database for that user-account.

So anyone who somehow obtains that hash can compromise your user account.

The only advantage you have in this scheme is that the server is never aware of the user's cleartext password, not even in memory. This makes it provably impossible for the server to steal the cleartext passwords, even if it had malicious intentions.

Keep in mind that this scheme requires that the client always uses the same salt for hashing the same password. Otherwise re-hashing the hash on the server-side won't yield the same result. But you can use different salts on different clients and you can change the salt when you change the cleartext password.

When you hash passwords on the client, the shared secret between client and server is no longer the cleartext password but the hash of the cleartext password. Your password is no longer monkey, your password is now $2a$04$RuNMmxnNakaesRjxjI3IAO70b2zK8lb5eRLb./huDLJ0OkWC0ikGm (bcrypt hash of "monkey"). The server would then hash this hash again and compare it to the hash-hash it already has in the database for that user-account.

So anyone who somehow obtains the client-calculated hash can compromise your user account.

The only advantage you have in this scheme is that the server is never aware of the user's cleartext password, not even in memory. This makes it provably impossible for the server to steal the cleartext passwords, even if it had malicious intentions.

Keep in mind that this scheme requires that the client always uses the same salt for hashing the same password. Otherwise re-hashing the hash on the server-side won't yield the same result. But you can use different salts on different clients and you can change the salt when you change the cleartext password.

When you hash passwords on the client, the shared secret between client and server is no longer the cleartext password but the hash of the cleartext password. Your password is no longer monkey, your password is now $2a$04$RuNMmxnNakaesRjxjI3IAO70b2zK8lb5eRLb./huDLJ0OkWC0ikGm (bcrypt hash of "monkey"). The server would then hash this hash again and compare it to the hash-hash it already has in the database for that user-account.

So anyone who somehow obtains that hash can compromise your user account.

The only advantage you have in this scheme is that the server is never aware of the user's cleartext password, not even in memory. This makes it provably impossible for you to steal user passwords even if you have malicious intentions.

Keep in mind that this scheme requires that the client always uses the same salt for hashing the same password. Otherwise re-hashing the hash on the server-side won't yield the same result. But you can use different salts on different clients and you can change the salt when you change the cleartext password.

When you hash passwords on the client, the shared secret between client and server is no longer the cleartext password but the hash of the cleartext password. Your password is no longer monkey, your password is now $2a$04$RuNMmxnNakaesRjxjI3IAO70b2zK8lb5eRLb./huDLJ0OkWC0ikGm (bcrypt hash of "monkey"). The server would then hash this hash again and compare it to the hash-hash it already has in the database for that user-account.

So anyone who somehow obtains that hash can compromise your user account.

The only advantage you have in this scheme is that the server is never aware of the user's cleartext password, not even in memory. This makes it provably impossible for the server to steal the cleartext passwords, even if it had malicious intentions.

Keep in mind that this scheme requires that the client always uses the same salt for hashing the same password. Otherwise re-hashing the hash on the server-side won't yield the same result. But you can use different salts on different clients and you can change the salt when you change the cleartext password.

When you hash passwords on the client, the shared secret between client and server is no longer the cleartext password but the hash of the cleartext password. Your password is no longer monkey, your password is now $2a$04$RuNMmxnNakaesRjxjI3IAO70b2zK8lb5eRLb./huDLJ0OkWC0ikGm (bcrypt hash of "monkey").

So anyone who somehow obtains that hash can compromise your user account.

The only advantage you have in this scheme is that the server is never aware of the user's cleartext password, not even in memory. This makes it provably impossible for you to steal user passwords even if you have malicious intentions.

Keep in mind that this scheme requires that the client always uses the same salt for hashing the same password. Otherwise re-hashing the hash on the server-side won't yield the same result.

When you hash passwords on the client, the shared secret between client and server is no longer the cleartext password but the hash of the cleartext password. Your password is no longer monkey, your password is now $2a$04$RuNMmxnNakaesRjxjI3IAO70b2zK8lb5eRLb./huDLJ0OkWC0ikGm (bcrypt hash of "monkey"). The server would then hash this hash again and compare it to the hash-hash it already has in the database for that user-account.

So anyone who somehow obtains that hash can compromise your user account.

The only advantage you have in this scheme is that the server is never aware of the user's cleartext password, not even in memory. This makes it provably impossible for you to steal user passwords even if you have malicious intentions.

Keep in mind that this scheme requires that the client always uses the same salt for hashing the same password. Otherwise re-hashing the hash on the server-side won't yield the same result. But you can use different salts on different clients and you can change the salt when you change the cleartext password.