Forum: Ruby on Rails A Letter to the Authors of Web Authentication Libraries

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
D17c45370dfe5567af5e47445524511e?d=identicon&s=25 Paul Johnston (Guest)
on 2009-05-05 17:43
(Received via mailing list)
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/), 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]
Dd2d775dea75b381edb1bbf0600a0907?d=identicon&s=25 Marnen Laibow-Koser (marnen)
on 2009-05-05 17:58
Paul Johnston 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://
> 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
marnen@marnen.org
25a538c965e4efca9903d205d97edd8d?d=identicon&s=25 SeanWalberg (Guest)
on 2009-05-05 18:10
(Received via mailing list)
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 <rails-mailing-l...@andreas-
Dd2d775dea75b381edb1bbf0600a0907?d=identicon&s=25 Marnen Laibow-Koser (marnen)
on 2009-05-05 18:17
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
marnen@marnen.org
D17c45370dfe5567af5e47445524511e?d=identicon&s=25 Paul Johnston (Guest)
on 2009-05-05 21:30
(Received via mailing list)
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
3131fcea0a711e5ad89c8d49cc9253b4?d=identicon&s=25 Julian Leviston (Guest)
on 2009-05-06 12:11
(Received via mailing list)
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/
Learn: http://sensei.zenunit.com/
Twitter: http://twitter.com/random8r
D17c45370dfe5567af5e47445524511e?d=identicon&s=25 Paul Johnston (Guest)
on 2009-05-07 04:09
(Received via mailing list)
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
This topic is locked and can not be replied to.