|
Posted by Ben C on 01/09/08 22:33
On 2008-01-09, Alexander Mueller <noemail@example.org> wrote:
>
> Unfortunately Disco Octopus' posting isnt listed on my newsserver, so I
> have to reply to myself .....
>
> Disco Octopus wrote:
>>
>> A few years ago we had implemented a similar concept using javascript
>> and hashing of the password pre posting.
>>
>> As others have mentioned, it did not prevent hackers from obtaining
>> the hashed value, which of course was the same value as to be
>> retrieved on the server.
>>
>> Perhaps naivety led us to feel that if the hacker did not know exactly
>> what was entered into the form (pre hash), then this was at least some
>> form of security.
>
> Of course, attackers can obtain the hashed value, but this is a simple
> replay attack and not the primary target of the hashing idea itself.
> Here the replay salt comes into play.
I still don't understand the point of the hash.
Never mind the replay salt for now-- what's the basic point of the hash?
I have re-read your original post, and I still don't understand it.
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?
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.
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.
But we can do just the same thing if the password comes as formdata
rather than as keyboard input. We can hash it when it gets there and
only store hashes (in fact this is just what the htpasswd program does).
No need or point or harm in hashing it on the client, but therefore no
need for <input type="hash"> that I can see.
What am I missing?
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?
[Back to original message]
|