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
