|
|
Posted by Harlan Messinger on 01/09/08 20:15
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).
But since the hash, not the password, is what gets access to the
application, how is this helpful? Having the value of a string called a
"password" is not an end in itself. The point is that the administrator
has the data he needs to get into the application. And if you're talking
about a situation where the administrator has access to the application
itself (this isn't a given, but you've just added it to the scenario),
then why does it matter at all whether the administrator can see the
password or the hash or anything else?
>> 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
You mentioned addressing this with SSL. Your rationale for your approach
was to shield the password from the administrator as well.
> - as
> well as, partly, against the Administrator, so that he cannot simply
> reveal the user password, which is currently possible however.
OK, this is the first time you've mentioned the issue of the
administrator giving it to someone *else* instead of just knowing it
himself.
>
>> 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?
It applies by virtue of the fact that you haven't put the administrator
at any kind of disadvantage in terms of gaining access to the
application, which is what you had been claiming was the advantage of
your approach. You finally added the missing piece, above, a case where
your approach *does* provide additional protection.
Navigation:
[Reply to this message]
|