|
|
Posted by Alexander Mueller on 01/10/08 00:03
Ben C wrote:
>
> The problem I have is the same as others have described: the hash is
> presumably sent to the server in a query string or other kind of
> formdata?
Exactly, this is something you cannot prevent.
>
> That data, which is sent in plaintext, is just as good as a password: it
> gets me in. I might as well steal that. Never mind the password. I will
> be able to access the site, just not by typing asterisks into the proper
> form but by typing characters into the browser's location bar instead.
> So what.
Thats a good point and I am glad you brought it up as this is what I
wanted, a discussion about possibly redundancies, flaws or potential
problems.
You are right that the hashing itself does not solve the replay problem
(thats what the replay salt should solve), however this is not its
primary task. The idea behind the hashing is rather not to let the
password leave the client right from the beginning but instead to
"encrypt" the password on its way to the server (particularly over
non-SSL connections) as well as to "hide" it also from the actual
destination.
>
> In comparison, the hash does not log you into a UNIX machine. You have
> to type the actual password. There is supposed to be no way to get in
> with just a hash. Therefore if you store hashes in the passwd file
> instead of passwords it's less of a problem if the passwd file is
> compromised.
Again, the hash is primarily to keep the password itself secret. On Unix
an Administrator can reveal the password just as easily.
>
> As for replay salt, why can't I just require along with the password
> another special number obtained from the server earlier in the session?
> Why is it necessary to munge these two numbers together into a single
> hash?
If you dont do the munging you still have a replay problem. An attacker
simply takes the password along with the "special number" from his session.
Alexander
Navigation:
[Reply to this message]
|