Rails - May 2009 - Re: A Letter to the Authors of Web Authentication Libraries

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-sbuyVjPbboAdnm+yROfE0A@public.gmane.org

-- 
Posted via http://www.ruby-forum.com/.

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-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.

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