Re: New Input type proposal

On 2008-01-10, Alexander Mueller <noemail@[EMAIL PROTECTED]
> wrote:
> 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 ha****ng 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 ha****ng 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.

All you're protecting is the identities of people's pets. There is
however some value in this as some users may use the same password for
lots of websites.

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

Can he? I thought root could change anyone's password to something else
and log in to their account, but he can't see their actual password. The
actual password is not stored anywhere, so no-one can reveal it.

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

Well you make each special number one-time use only. You use it once and
then get given another one, which you can also use only once.
Fortunately there are plenty of numbers.

If the number is not use-once then munging it with the password doesn't
help. The replay-attacker just needs to capture the munged
password+number.