# A Letter to the Authors of Web Authentication Libraries **URL:** \ **Category:** Rails\ **Created:** [May 5, 2009, 5:43pm UTC](https://www.ruby-forum.com/t/a-letter-to-the-authors-of-web-authentication-libraries/167224 "2009-05-05T17:43:07Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![dohmer](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/439d5e/32.png) [@dohmer](https://www.ruby-forum.com/u/dohmer)\ **Post date:** [May 5, 2009, 5:43pm UTC](https://www.ruby-forum.com/t/a-letter-to-the-authors-of-web-authentication-libraries/167224/1 "2009-05-05T17:43:07Z")
Hi, 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/](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] ---
**Author:** ![dohmer](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/439d5e/32.png) [@dohmer](https://www.ruby-forum.com/u/dohmer)\ **Post date:** [May 5, 2009, 5:58pm UTC](https://www.ruby-forum.com/t/a-letter-to-the-authors-of-web-authentication-libraries/167224/2 "2009-05-05T17:58:33Z")
Paul J. wrote: > Hi, > > 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:// > [Paj's Home: Cryptography: JavaScript MD5](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. ## Best, Marnen Laibow-Koser [http://www.marnen.org](http://www.marnen.org) removed\_email\_address@domain.invalid ---
**Author:** ![dohmer](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/439d5e/32.png) [@dohmer](https://www.ruby-forum.com/u/dohmer)\ **Post date:** [May 5, 2009, 6:10pm UTC](https://www.ruby-forum.com/t/a-letter-to-the-authors-of-web-authentication-libraries/167224/3 "2009-05-05T18:10:48Z")
OP said it’s a challenge-response system. So the server would send a hidden field in the form (timestamp? md5(rand)? ), the client concatenates the password and the challenge, md5’s it, and returns it. The server knows the challenge which prevents replay attacks if the hash is sniffed. Sean On May 5, 10:58 am, Marnen Laibow-Koser \ **Author:** ![dohmer](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/439d5e/32.png) [@dohmer](https://www.ruby-forum.com/u/dohmer)\ **Post date:** [May 5, 2009, 6:17pm UTC](https://www.ruby-forum.com/t/a-letter-to-the-authors-of-web-authentication-libraries/167224/4 "2009-05-05T18:17:40Z") SeanWalberg wrote: > OP said it’s a challenge-response system. So the server would send a > hidden field in the form (timestamp? md5(rand)? ), the client > concatenates the password and the challenge, md5’s it, and returns it. Ah, that makes sense – dynamic salting. > The server knows the challenge which prevents replay attacks if the > hash is sniffed. 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. > Sean ## Best, Marnen Laibow-Koser [http://www.marnen.org](http://www.marnen.org) removed\_email\_address@domain.invalid ---
**Author:** ![dohmer](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/439d5e/32.png) [@dohmer](https://www.ruby-forum.com/u/dohmer)\ **Post date:** [May 5, 2009, 9:30pm UTC](https://www.ruby-forum.com/t/a-letter-to-the-authors-of-web-authentication-libraries/167224/5 "2009-05-05T21:30:47Z")
Hi, 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. Paul ---
**Author:** ![dohmer](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/439d5e/32.png) [@dohmer](https://www.ruby-forum.com/u/dohmer)\ **Post date:** [May 7, 2009, 4:09am UTC](https://www.ruby-forum.com/t/a-letter-to-the-authors-of-web-authentication-libraries/167224/6 "2009-05-07T04:09:16Z")
Hi, > 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. Paul ---
**Author:** ![dohmer](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/439d5e/32.png) [@dohmer](https://www.ruby-forum.com/u/dohmer)\ **Post date:** [May 6, 2009, 12:11pm UTC](https://www.ruby-forum.com/t/a-letter-to-the-authors-of-web-authentication-libraries/167224/7 "2009-05-06T12:11:22Z")
Yep! 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. Blog: [http://random8.zenunit.com/](http://random8.zenunit.com/) Learn: [http://sensei.zenunit.com/](http://sensei.zenunit.com/) Twitter: [http://twitter.com/random8r](http://twitter.com/random8r)