3 ms·
what you're describing is basically cram-md5. Which is nice if you're using plain http and don't want the password to travel over the wire. But both sides need
by Xylakant 15y ago
what you're describing is basically cram-md5. Which is nice if you're using plain http and don't want the password to travel over the wire. But both sides need the plaintext password. Otherwise the hash of the password replaces the password and is just as good as an authentication token as the password itself, i.e I just need the hash to authenticate, not the pw itself.
- ams6110 15y agoThe server needs the plaintext password once, to generate a salted hash. From then on, it can send the salt and a challenge to the client. The client hashes the password, salt and then hashes that with the challenge and sends it back to the server. The server hashes the challenge with its salted hash and they should match. This still has to be done over SSL because otherwise the JS doing this on the client side is subject to MITM.
- Xylakant 15y agowell. but if you're using ssl then you could as well send the password over the wire and have it properly stored with bcrypt on the serverside. And if I control the application I can make the client emit a plaintext password by sending an empty salt. The result is a simple hash of the password which can be reverted with a regular rainbow table. If the client uses bcrypt, I send a work factor of 1 and construct a proper rainbow table (that's rather simple). Or I could just have the javascript send the password in plain. So there's no gain here.
- mikeash 15y agoBut at least you can't recover the password to log into other sites. I thought that the main goal here was to avoid the scenario where an attacker recovers your password on one site and can therefore log in as you all over the place if you made the mistake of reusing it (as most people do).