I'd prefer we focus on sites that still store passwords in the clear.
Yes reddit, I'm looking at you. Of course any other site that can actually mail you a forgotten password is in fact doing this too.
Yes reddit, I'm looking at you. Of course any other site that can actually mail you a forgotten password is in fact doing this too.
That said states like Iran might be more likely to garner the most passwords through sniffing, which is a passive activity, than hacking the sites that store passwords insecurely.
That being said, point taken. While both are important variables to address, one is just plain bad practice.
I thought we got the future something like 10 years ago. It was called "TLS".
I know enough to encrypt my password storage, but I never thought to encrypt passwords client-side. I'm interested in knowing what are best practices.
Even if that means a new protocol that uses SSL to send the javascript, etc., and we're 15 years away.
Do you think designing a system where the server never sees (or has the opportunity to store) the plaintext password is the way of the future?
(Edit: more emphasis on future, not short term, ambitions.)
You mean things like 1password. That's fine. I use Keychain and head /dev/random | md5 for any password I don't have to remember.
Seems to me storing hashes and nonces does not work, because without the original password the server can not create new hashes and nonces. So the client would still always send the same thing, which would be equivalent to a password.
one time during undergrad I was talking with Hal Abelson because there was this big stink about the new research building (Stata center) requiring rfid's to get around. Richard Stallman et al were making a huge ruckus about the privacy implications of not having physical keys.
I mentioned some desired attributes of a protocol to let people in without logging it, and started worrying about the implementation details / feasibility. he said "oh don't worry about implementation. this building has people in it who can implement anything." he had this smirk about him.
so give it some experts and time and they'll figure it out.
http://srp.stanford.edu/whatisit.html
http://www.ietf.org/rfc/rfc5054.txt
Now, if only more browsers would support it.
For example, the user browses to http://www.example.org/login. The generated login form on the page contains a hidden field called "challenge" with a randomly generated hash from the server. When the user submits the login form, have the client do a hash(challenge + password) and send this to the server. Upon receiving the hash and checking credentials, the server invalidates the challenge string regardless if the login attempt was successful.
This obviously does not work if the user does not have Javascript enabled and is not preferable to SSL.
PS: You could implement all the security features of SSL in JavaScript but that wold be pointless and slow. If you really wanted to build a custom security system I would recommended using a Java applet, but even with a team of experts it takes years to build something as secure as SSL.
Of course, it's pretty silly to go to the trouble of writing javascript code that can not only be modified, but may have bugs, when you can just use HTTPS.
The traffic manipulation part of the attack is also extremely easy, and not particularly noisy.
For most applications, Javascript crypto is completely useless.
That said, if option A may help in some unusual case, and option B will be effective in all non-catastrophic cases, I know which one I'd choose.
You can see the code for yourself at http://code.reddit.com if you'd like to verify.
All for what? The convenience of letting a user keep the same password they already forgot?
A hash with a salt works perfectly fine for 99% of all situations with very little downside.
Can you elaborate on this?