Re: New Input type proposal

Alexander Mueller wrote:
> Harlan Messinger wrote:
>>
>> OK, so the password has been left out of the server side entirely. 
>> Instead, to access the application you need the hash value, and the 
>> server administrator has access to *that*. So just substitute the word 
>> "password" for the word "hash" and the server administrator is now 
>> able to intercept the value of the hash that will give him access to 
>> the application.
> 
> Correct, but the Administrator always has access to the application 
> under any user account, if he wants. The point is, he does not have 
> access to the actual password (nor does anyone using a sniffer).
> 
>>
>> The point of an application storing a hash instead of the original 
>> password is that it only accepts the password for authentication, 
>> computing its hash when the it's provided and comparing it with the 
>> hash it has in its user lookup table.
> 
> Sorry, but thats not exactly the point. For the application it wouldnt 
> matter if it has to compare the hash of a given password with a stored 
> hash or simply the given plain text password with a stored plain text 
> password.

Right, that's what I already said (see below): both would be equally 
weak situations. It's for that reason that a truly secure application 
*stores* the *hash* but *expects* the *password*. Your proposal is 
compatible only with an application that has this other security hole.

> The point is to add security against attackers - as you mentioned - as 
> well as, partly, against the Administrator, so that he cannot simply 
> reveal the user password, which is currently possible however.
> 
>> If someone hacks the user table and finds the hashes, it won't do the 
>> hacker any good because the application doesn't provide any interface 
>> for accessing the system by providing the hash directly.
> 
> Correct.