crypto-browserify to SHA crypt pass in browser, don't send to server in clear

[lefnire]

I'm not sure that this is strictly necessary, since we're encrypting / storing with SHA & salt on server - and protecting clear text sends with SSL. Opening topic here in case people have something to say.

See conversation here, and crypto-browserify

[Pandoro]

After reading about SSL Man-In-The-Middle attacks I would feel safer about them being sent in an encrypted way. But I agree that using SSL should in general be safe enough. As you mentioned in HabitRPG/habitica#525 though, if it really simplifies other things, I guess it wouldn't hurt to implement it at some point when your plate is cleared from other critical bugs.

[SLaks]

Note that you cannot easily achieve perfect security here.

Unless you switch to a zero-knowledge proof, you can either block attackers that sniff the network (under SSL), or block attackers that have your database, but not both.

If the client sends the hash, sniffing attackers can send the same hash later to log in as that user.

If you do challenge-response (server sends user's salt + a nonce, client sends hash of hashed-salted-password+nonce), db-stealing-attackers can compute that hash from the stored salted hash in the database.

Either of these approaches will prevent attackers from getting the plaintext password (no matter what), so they will only be able to attack the site they sniff / steal.

Also, either approach will break scriptless login (which Derby is otherwise somewhat good at)

[lefnire]

thanks for that follow-up SLaks, really good information. Sounds like we're at a bit of an impasse with how to handle this - could do encrypting to prevent plaintext sniffing, but at the risk of breaking Derby scriptless login. I'll mark this down from critical and address later