2 ms·
How would this work when you have to store the hash on a server? A hypothetical client-side hasher doing this means that an attacker would just...send the hash,
by eropple 7y ago
How would this work when you have to store the hash on a server? A hypothetical client-side hasher doing this means that an attacker would just...send the hash, acquired through nefarious means. Just as they'd send the password today. Server-side, that hash would be the password and that itself would need to be hashed before storage.
I don't know why you're talking about "custom hashing algorithms", in JavaScript or elsewhere; you pull a bcrypt/scrypt/Argon2 library and use it.
- topmonk 7y agoYea you're right. But what about this, the client uses the password as a seed to create a public/private key pair, and sends the public key to the server. If it is during password creation, the server stores this public key in relation to the user, otherwise verifies it. Then the server sends a challenge* and the client uses the private key to sign it and return a response. * actually the server would send the challenge ahead of time along with serving the web page
- eropple 7y agoThat sounds like PAKE. I'm not qualified to opine on that; it's above my pay grade. I can see a lot of implementation issues, though, if you wanted to make it a browser component outside the control of the developer.