Many web sites have a user name and password login system, and do not
use SSL. As a consequence, users' passwords are transmitted over the
internet unencrypted. This puts them at risk, particularly if the user
is on a shared ethernet segment, or open wireless network.
For many years I have provided a JavaScript MD5 library (http://
pajhome.org.uk/crypt/md5/), which can be used to perform a challenge-
response login. This avoids passwords being transmitted unencrypted,
although the security is not as strong as SSL. A number of web sites
currently use this technique; for some years Yahoo did, although they
now have SSL login.
However, the use of JavaScript MD5 is not widespread. I think this is
because few authentication libraries support it. It is possible for a
library to provide JavaScript MD5 as an authentication mechanism, with
the details hidden from the application developer. In fact, it's quite
easy to implement, and there is a lot of guidance on my site.
So, this is a call to the authors of all web authentication libraries.
Add JavaScript MD5 as an authentication mechanism. And then let me
know, so I can link to you from my site. If you need any help
implementing it, drop me a line, I'll do what I can.
I think supporting this mode would be a big selling point for any
authentication library. And if support becomes widespread, the
internet becomes a little bit safer for everyone.
Best wishes,
Paul
[This was rejected on the rails-core list, but I believe it is
relevant to the Rails community]
Many web sites have a user name and password login system, and do not
use SSL. As a consequence, users' passwords are transmitted over the
internet unencrypted.
[...]
For many years I have provided a JavaScript MD5 library (http://
pajhome.org.uk/crypt/md5/), which can be used to perform a challenge-
response login. This avoids passwords being transmitted unencrypted,
although the security is not as strong as SSL.
This sounds promising on the face of it. But thinking about it a little
more: the MD5 hash would be transmitted just as insecurely as the
password. What's to prevent someone from just sending the intercepted
hash to the server in the same way that they'd send an intercepted
password? I really don't see the extra security in this approach.
Also, it seems to me that use of this library would break the login form
if JavaScript isn't turned on. This is not ideal.
[...]
I think supporting this mode would be a big selling point for any
authentication library. And if support becomes widespread, the
internet becomes a little bit safer for everyone.
Unfortunately, it looks to me like if support becomes widespread,
everyone will have a little more of a *false sense* of security (for the
reasons I outlined above), and everyone will have more requirement to
use JS.
Best wishes,
Paul
[This was rejected on the rails-core list, but I believe it is
relevant to the Rails community]
It may be. But it certainly has nothing to do with the Rails core.
Just to clarify:
1) The hash is different for each login, so an attacker can't do a
simple replay
2) If JavaScript is not available, you'll usually want to allow the
login, although it will be unencrypted. This can be done quite easily.
Which means that if the challenge exists, we don't need the client-side
crypto anyway, right? (Or rather, we only need it to hide the password,
not to prevent unauthorized logins.) This is essentially what Rails
already does with form_authenticity_token.
I must confess my ignorance of Rails here, but it sounds like
form_authenticity_token is there to prevent cross-site request
forgeries? That is certainly a good control to have, but JavaScript
crypto on passwords solves a different problem - network sniffing of
the password.
Out of interest, what's your take on when a user wants to retrieve
their password? Not talking about regeneration or resetting here, tho
that works.
My take is that there should be no way for the user to retrieve their
password. Forgotten password should generate an code that is sent to
their email, usually within a link, and when the user clicks the link
they get a chance to set a new password.
If you really want users to be able to retrieve passwords, you can
always store them in the database as plaintext. I don't recommend it
though.
