Remix.run Logo
▲ Ra8 2 hours ago

> Whenever I've written authentication, passwords are hashed on the client side and never transmitted in the clear.

Unless I'm misunderstanding what you're doing, this achieves nothing.

Hashing the password on the client side makes the hash the password, and MITM attacks are still possible.

▲Maskawanian 2 hours ago | parent | next [-]

Sure, you could MITM still if all you do is that, as with anything it depends on what you are defending against.

If you are defending against clear text being discoverable, then bcrypt hashing with a unique salt on the client is good enough.

If you are trying to prevent MITM you can combine that salting with public/private key transmission of the bcrypt hash to the backend (effectively the same idea as pass keys without the downsides).

MITM just affects your service, and doesn't always matter depending on what the service is, for example, a recipe manager doesn't need to have bullet proof security.

▲Ra8 2 hours ago | parent [-]

What if the hash you're sending is discovered? I can use that to login to the service; it offers the same protection as a plain text password.

▲Maskawanian 2 hours ago | parent [-]

As the hash is being encrypted with the public key in the client, that would require that the client be compromised. In which case the original password is already exposed at that point, thus a discussion of the transport is no longer the concern.

▲MBCook an hour ago | parent | prev [-]

Correct. The hash effectively is the password at that point.

If you’re storing the hash unencrypted in the DB, and it’s “just” a hash so why not, you’ve gone backwards.