Yup, the future is clearly client side hashing. I wonder if we could get the latest and greatest from that field built into the next jquery etc so people become more likely to use the routines. ...
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.
Hm, I guess I always assumed we would end up with SCrypt or something similar running on the client side with a nonce etc so the server never even sees the plaintext password.
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.)
There is a secure auth mode for SSL called TLS-SRP, RFC 5054. It is quite clean, deriving a session key and authenticating the session in the same number of round trips as a regular TLS handshake. It is secure against dictionary attacks.
What scheme would allow for that, though? Except for public key cryptography?
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.
yeah, I know what you mean. I do think it's solvable though.
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.
I'm sorry. I thought you mean Javascript challenge-response, which is a very common and very evil suggestion as a way to get SSL-like security without having to do SSL.
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.
A few years ago I stoped someone from implementing that. The problem is if you intercept the hash you can use it like a password because the system at the other end would never see the original password.
You can prevent this circumvention by only allowing the client side generated hash to be good for one login attempt. This is done by giving the client a unique challenge string for each login request and hashing the password with the challenge string.
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.
Security is a hard problem. Unless the server knows the password they can't validate Hash(challenge + password). If you intercept both the challenge and the resulting hash you can brute force the password. If you have a method of safely sending the password in the first place you should probably use that all the time instead of trying to build a JavaScript system to avoid sending the password in the clear.
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.
The future is hopefully something more secure than client-side hashing, probably SRP, or it’ll be NTLM all over again. It would be nice if web browsers implemented it directly, but until then there are JavaScript libraries like http://server.denksoft.com/wordpress/?page_id=27 .
Do not implement crypto algorithms in Javascript. Very dangerous. Also, there's no way to serve them securely unless the whole login process is SSL/TLS anyways.
I think more people should be worried about the janitor with night time server access and a big Vegas debt to pay than the government of Iran, to be honest.
That being said, point taken. While both are important variables to address, one is just plain bad practice.
Client-side hazing (with JS) is a cute hack that's completely useless for improving security. If there's a man in the middle, they can strip the protection code before you fill in the form.
It's not completely useless: it's slightly helpful against an attacker that can snoop but not modify.
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.
In practical terms, there is no such attacker. The ability to watch packets in real time is the ability to silently redirect them, or to insert fake packets into the stream.
The traffic manipulation part of the attack is also extremely easy, and not particularly noisy.
For most applications, Javascript crypto is completely useless.
Consider the case of someone getting their information by triggering some sort of debug mode on the router, or using some sort of side channel. More plausibly, consider the case where someone can break your over-the-air encryption (but not in real-time). It may be extremely rare, but strictly speaking it's not impossible.
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.
Why must it be stored in clear? Why not encrypted rather than hashed? That still allows password retrieval. Of course encrypted data is only as secure as the DB and keys/decryption code ...
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.