> MITM attacks won't get access to unencrypted fields. A MITM would let you hijack the JS that controls scrypt/SHA-256, so you're already at game over. You've

> MITM attacks won't get access to unencrypted fields. A MITM would let you hijack the JS that controls scrypt/SHA-256, so you're already at game over. You've got to deliver that to the user in some fashion (TLS!); this isn't a real win for your approach. > External brute force attackers will have to take the burden of heavy hashing. If the attacker is trying targeted access to a site the only thing that's relevant is the time they have to expend - the hash is opaque. If they have the hash from, say, a DB theft, they're already going to have to take that burden. Your approach doesn't seem to add anything. > Storing SHA256 hash instead of scrypt hash on DB means even if DB is stolen, attackers can't use stolen scrypt hashes to authenticate any client. I'm not sure what that means. If you steal my scrypt hash for example.net, how do you use that to authenticate me to example.net? Your approach pushes out complexity to the clients and doesn't seem to win us anything.