|
|
Posted by Harlan Messinger on 01/10/08 23:05
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.
Navigation:
[Reply to this message]
|