Hacker News Reader

Comment by hartator | Hacker News Reader

Some unrelated thoughts I’ve always wondering, why not use bcrypt function on the client side this way the clear password never hit the servers?

It seems so weird to me that the passwords are not hashed leaving the client, and it’s considered good practice.

View on HN

That would mean that you trust the client completely to log somebody in. What's preventing somebody from bypassing the clientside bcrypt check?

As long as the password is sent over a secure channels (TLS) and doesn't leak somewhere on the server (e.g. logs), sending it plaintext from the client is not where most password breaches come from. But stuff like https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco... would provide a solution for that.

I meant both registration and sign in forms, hash the password in JS, so there is no way to bypass bcrypt?

I think you want to be able to verify that the password is secure (greater than a certain length, uses capitals and symbols, etc.)

if you just pass the hash back to the server, you can't verify that the password was secure.

That can also be verified on the client side.

How do you trust the client verified it correctly?

The client attempting to bypass password complexity checks on registration is not part of most threat models. I.e. they're not an attacker, it's more of a user aid.

But you can do the same in JavaScript.

More serious reason is imo js requirement, as I'm not aware of native support of password hashing in HTML forms. Also, different ways of hash keying/salting would make it either complicated or inflexible..

Reply on news.ycombinator.com