Re: New Input type proposal

Hi Philip,

a quick follow-up to my first response.

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

Additional to the linking idea mentioned previously, another solution might be a user defined hash. The user would need to define a personal hash used for all hash input fields. One problem might appear when the user uses another computer or only reinstalls the browser without setting his hash, as all hashes would compute different results.

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

According to Wikipedia this seems to be an issue with Digest Authentication as well

http://en.wikipedia.org/wiki/Digest_authentication

  "One consequence of Digest authentication design is that the server must know the password (i.e. store it in plain text) or store the same HA1 (MD5) hash that is used to calculate the client's response (see example , below). This means that if the password database at a site is compromised the attacker will be able to impersonate any user whose access credentials are stolen. Such a compromise should not affect other sites if the MD5 hash is stored rather than the password, because the realm information is used as a salt. Unfortunately the scheme prevents use of different salts being used for each individual password held on the server."



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 Friday, 11 January 2008 12:04:16 UTC