Re: New Input type proposal

> 
> 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).

Thanks Philip, I had this issue in mind as well. One solution could be to link the hash input somehow to the field containing the username, so that the client can use the username as salt (I know here the known salt could be an issue, but for the moment :) ).

> 
> 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").

You brought up a very good point, which I apparently completely missed. I dont have a solution out of the box but I will see to come up with some.

> 
> 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?

The problem, as you mentioned, is the fact that the client must not know the extra salt and so can never compute a proper hash.


Thanks for your input Philip,
Alexander
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Received on Thursday, 10 January 2008 18:02:53 UTC