4 ms·
Cool idea. Slightly tangential, but I've often wondered why more websites don't do a hash "pre-pass" on the client-side in JavaScript, anyway. That way, they
by waffle_ss 14y ago
Cool idea.
Slightly tangential, but I've often wondered why more websites don't do a hash "pre-pass" on the client-side in JavaScript, anyway. That way, they never actually see your raw password on the server, they end up storing a hash of a hash (plausible deniability in case of a leak?).
For the people that don't have JavaScript, the server could always just do a double hash if the first one fails - although maybe there is some keyspace-reducing insecurity introduced here that I'm not mathy enough to immediately see.
- vicaya 14y agoBecause it only marginally increases security as stored hash = hash2(hash1(pw, salt1), salt2) = hash'(pw, salt1, salt2). Javascript hashing can only add minimal equivalent expensiveness of the combined hash. OTOH, once scrypt is builtin to most browser, we can offload scrypt (with large memory factor) in the browser and use a cheaper bcrypt on the server side. Again this doesn't really increase security that much besides saving server resource. One added benefit of the above approach is that it makes DDoS harder and more defensible.