Re: New Input type proposal

Alexander Mueller wrote:
> A hash input field would be defined similarly to a password field via
> 
>   <input type="hash" hash="md5" salt="" replaysalt="" />
> [...]
> - The third attribute (salt) would be an optional (but recommended) one, which should provide the result with the typical "hash salt" (to prevent precalculated tables). A site using a salt would always need to indicate the same salt, in order to get the same result.

A problem here is that the salt ought to be different for every user, 
because otherwise it's less secure (you'd only have to precompute tables 
once per site, rather than once per user) and you can tell when two 
users have the same password by just looking in the database. But you 
can't make the salt different unless you have a two-stage login process 
(i.e. send username first, then get salt, then send password).

> - The fourth attribute (replaysalt) would be an optional attribute as well, very similar to the third. However in this case the salt should be randomly calculated on each request and stored on the server side (via sessions for example). It is applied to the hash result of the content and the general salt. Its primary use is to prevent replay attacks.
> 
>   Note: The replay salt should only be used on read or verification processes (like a logon) as otherwise (upon setting the password for example) the server would never be able to determine the original or raw hashcode.

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?

> Thank you,
> Alexander Mueller

-- 
Philip Taylor
pjt47@cam.ac.uk

Received on Thursday, 10 January 2008 16:24:21 UTC