Weekend project: Password hasher bookmarklet for Firefox(randomexperiment.com)
randomexperiment.com
Weekend project: Password hasher bookmarklet for Firefox
http://randomexperiment.com/experiments/javascript/superpass.html
2 comments
Because 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.
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.
Hi,
This is inspired by the Password Hasher addon for Firefox. It will hash a password and generate unique strong password from the same input, varying by websites where it is called.
Reason I made it is 1) it has a custom salt, so a hacker cannot potentially bruteforce with this as a layer if you have set your 'unique master password', and 2) this is bookmarklet - no strong dependency on Firefox.
Sharing since some of you may find it useful too.
This is inspired by the Password Hasher addon for Firefox. It will hash a password and generate unique strong password from the same input, varying by websites where it is called.
Reason I made it is 1) it has a custom salt, so a hacker cannot potentially bruteforce with this as a layer if you have set your 'unique master password', and 2) this is bookmarklet - no strong dependency on Firefox.
Sharing since some of you may find it useful too.
Thanks for making this. Although the best security would be a unique salt per account, that would make the portability of the app a lot tougher.
Either way, this is a great way to prevent brute force attacks from determining a user's password, as well as preventing a serious incident should a website store credentials in plain text, then get compromised.
Of course, in a perfect world, everyone should be using unique, random passwords for each account they have on the Internet... but this is a great way to protect people that are using relatively insecure passwords across the board.
I'd suggest allowing custom salts so that users can enter their bookmarklet on other browsers, enter their "custom salt," and be able to get additional randomness. If this were to catch on, we wouldn't want people adding the salt to cracking tools etc (although that would be a lot more work/processing power on their part).
Sorry this was long winded. Cool idea, nice implementation!
Either way, this is a great way to prevent brute force attacks from determining a user's password, as well as preventing a serious incident should a website store credentials in plain text, then get compromised.
Of course, in a perfect world, everyone should be using unique, random passwords for each account they have on the Internet... but this is a great way to protect people that are using relatively insecure passwords across the board.
I'd suggest allowing custom salts so that users can enter their bookmarklet on other browsers, enter their "custom salt," and be able to get additional randomness. If this were to catch on, we wouldn't want people adding the salt to cracking tools etc (although that would be a lot more work/processing power on their part).
Sorry this was long winded. Cool idea, nice implementation!
Thanks for the comment. Not sure if I followed the custom salt part - unless it is already implemented at the bottom of the page, where I call the salt as master password in the custom bookmarklet. Would love to know your thoughts in case you meant something else.
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.