- From: Thomas Pike <thomasp@opera.com>
- Date: Thu, 10 Jan 2008 17:59:05 +0100
- 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