Hi Gunter+BugTraq See my comment below. Thanks, -Amit On 23 Mar 2005 at 10:23, Gunter Ollmann wrote: > > > >It should be noted that with this modified scheme: > >a. A calculation done for one username+password pair is useless for > >another pair (perhaps with the same username), because both the > >username AND the password are part of the hashcash string. > > > I would not normally recommend the use of passwords in this manner. > Basically, a password mapped to a user/customer should not really be > stored anywhere at the server end - instead a hash of the password is > stored (therefore, should anyone gain access to the database - they do > not have the passwords). In practical terms, this means that when a > customer submits their auth details to the server, it calculates the > hash of the submitted password and compares it to the hash it has stored > in the backend database. > > For your proposal, the server would need access to the real password to > verify the hashcash. Perhaps if the client-side sends a hashed value of > their password instead? > Exactly! Which is what I suggested in my email (the "modification to the modified method"). Here's the text from the bottom of my original email: <FROM_ORIGINAL_EMAIL> Regarding the fact that the password is used in the modified method: As I said above, this is both less elegant, and in some cases may be considered less secure (the original method was potentially unexposed to the password). However, a simple modification to the modified method ;-) can take care of this shortcoming. Instead of providing the username and the password, it is enough to provide, say: salt ^ ":" ^ HASH(username ^ ":" ^ password ^ ":" ^ salt) the system can then send a pass/fail status to the "normal" username+password authentication system, along with the above value, which the authentication system can (and must) verify. That is, the system doesn't have to know the username and the password. It is enough for it to verify that the hashcash was calculated for the specific username and password that are provided. While this indeed takes care of the username+password exposure in the system, it also necessiates a tighter integration with the standard authentication system (which now must verify the hash value). </FROM_ORIGINAL_EMAIL> Regards, -Amit
