W3C home > Mailing lists > Public > public-html@w3.org > January 2008

Re: New Input type proposal

From: Thomas Pike <thomasp@opera.com>
Date: Thu, 10 Jan 2008 17:59:05 +0100
Message-ID: <47864ED9.3010508@opera.com>
To: Philip Taylor <pjt47@cam.ac.uk>
CC: Alexander Mueller <alexm@gmx.at>, public-html@w3.org

Philip Taylor wrote:
> If I'm understanding correctly, this requires the introduction of a new 
> vulnerability:
> 
> When a user registers and logs in by sending "password" as plain text, a 
> sensible server will store (salt, hash(salt, "password")) in its 
> database. Then somebody with read access to the database cannot log in 
> as a user because they don't know "password" and they can't do anything 
> with just the hash, which is good.
> 
> When a user registers by sending hash(salt, "password") and logs in by 
> sending hash(replaysalt, hash(salt, "password")), the server mustn't 
> store (salt, hash(salt, "password")) because anybody with database read 
> access could log in as anyone by calculating the replaysalted hash from 
> their knowledge of hash(salt, "password").
> 
> The server could perhaps store (extrasalt, hash(extrasalt, hash(salt, 
> "password"))). But then it couldn't calculate hash(replaysalt, 
> hash(salt, "password")) to verify the login request (unless replaysalt 
> == extrasalt, in which case replaysalt would be constant, which it is 
> defined not to be). Is there a different way this can work, which 
> doesn't let anyone log in just because they can read the database?

I'd strongly suggest reading RFC2617[1] (specifically the section on Digest 
Access Authentication) which achieves exactly this through HTTP.

It would be too complicated to summarise exactly how this works in this 
e-mail (read the spec if you're interested), but the end result is that:

- The server does not store the password; instead it stores a hash
   (called A1) comprised of the username, realm name and password.

- The client sends a hash comprised of A1, a server-chosen unique value, a
   client-chosen unique value, a counter to guard against replay attacks, the
   HTTP method and the requested URI.

This provides a relatively* secure method of authentication that at no point 
requires the storing or transmitting of password in plaintext.

Whether it would be possible to achieve something similar in HTML alone is 
another matter.


[1] ftp://ftp.isi.edu/in-notes/rfc2617.txt

* Relative to sending the password in plain-text - there are other security 
issues that Digest Authentication alone does not address.

-- 
Thomas Pike, QA Engineer
QA Systems & Processes, Opera Software
Received on Thursday, 10 January 2008 17:00:03 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:29 UTC