Re: New Input type proposal

Alexander Mueller wrote:

J.O. Aho wrote:

As you mentioned your system would prevent the administrator from
knowing your
password, then the password has to be hashed already at the site, and
therefore the hashing has to be the the same in the form as on the
site, or
else you would always fail the login or the site has to spend long
time with
cracktools to be able to find out the password and then has it the way
it's
hashed on the site.

Sorry I dont really know what you are exactly meaning.

Again, please reread my initial posting, I guess everything should be
clear then . The system wouldnt know the plain text password (which it
doesnt need) but only the hash code.

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.

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

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.

Alexander Mueller wrote:

Harlan Messinger wrote:

But since the hash, not the password, is what gets access to the
application, how is this helpful?

Please! Reread my initial posting, all your questions should be answered
there. All advantages are listed there.

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.

Its not about getting into an application. This is always possible. Its
about protecting the password and preventing replay attacks.

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),

It isnt a given? In most cases the Administrator has access to the
application itself.

I mean "access" in the way we're using it to apply to anyone
else--access to *use* the application.

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.

Alexander Mueller wrote:

Harlan Messinger wrote:

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.

Sorry, but what should be weak about this? You havent backed your
statement with nothing. Please state facts and not only rumors.

I explained it already. Sorry if it went by you.