Re: New Input type proposal

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.

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.

> If the hacker submits the hash as though it 
> were the password, the application will hash the hash, and the computed 
> rehash won't match the stored hash.  The application has to see the
> password itself before it will grant access.

Thats correct, but this is the typical system as it is now. How does it 
apply to the mentioned solution here?

Alexander