New Input type proposal

[Alexander Mueller]

Hi,

the reason behind my email is the proposal of a new Input type named "hash"

<input type="hash" />

I am now going into detail about why I'd consider it as important and
technical information as well as comparisons to current techniques.


What should it do and be?
-------------------------
Visually it can be identical to the known "password" type (a textbox
masking its characters). The major difference would be its technical
implementation respectively its output/result to the server.


What would be those differences?
--------------------------------
An input field of the type "password" transmits its content, just as any
other regular textbox, unencrypted to the server.

An input field of the type "hash" should hash the given text and
transmit only the hash to the server.


What would be the advantages?
-----------------------------
As mentioned, a password field only masks its text (so that it cannot be
read by bystanders) but does not actually encrypt or hash it, in order
to provide a secure transmission.

This does not only mean that the given text is transmitted in plain text
over the network (unless SSL is used) but also that the owner or
administrator of the destination server can always reveal the actual
password. Further it is making replay attacks possible or at least much
more simple.


What would be the exact technical implementation?
-------------------------------------------------
A hash input field would be defined similarly to a password field via

<input type="hash" hash="md5" salt="" replaysalt="" />

- The first attribute (type) would indicate that a hash field should be
displayed.

- The second attribute (hash) would indicate the hash algorithm to be
used (md5 in this example or also sha1 or any other available on the
client).

- The third attribute (salt) would be an optional (but recommended) one,
which should provide the result with the typical "hash salt" (to prevent
precalculated tables). A site using a salt would always need to indicate
the same salt, in order to get the same result.

- The fourth attribute (replaysalt) would be an optional attribute as
well, very similar to the third. However in this case the salt should be
randomly calculated on each request and stored on the server side (via
sessions for example). It is applied to the hash result of the content
and the general salt. Its primary use is to prevent replay attacks.

Note: The replay salt should only be used on read or verification
processes (like a logon) as otherwise (upon setting the password for
example) the server would never be able to determine the original or raw
hashcode.


Why a hash field if SSL already provides secure transmissions?
--------------------------------------------------------------
It is correct, that HTTPS provides a secure way between the client and
the server. However HTTPS does not prevent that the Administrator of the
destination server is acquiring the actual plain text data. A hash input
field would do this. Additionally it provides a semi-encryption as well
as replay protection to non-SSL connections.


Are there any open technical or security issues?
------------------------------------------------
I am only aware of one, the way how client side access (via JavaScript
for example) to a hash field is handled. While write access should
probably always set the passed value, read access is a bit more
difficult. Should the returned value be the computed hash or the actual
value? Although I tend to the former, this should still be discussed.
Related to this would be whether key event handlers should be called or
not (they could be used to reveal the entered text).

Should there be other concerns, I'd really welcome opinions.




Concept Implementation
----------------------
I have developed a first very basic extension for Firefox 2. The
functionality as mentioned here is already implemented, however it does
not introduce a "hash" type but rather extends the "password" type (by
applying a hash to all password fields with a given hash attribute).

You can find "Hash Input" at http://www.alcomp.net/hashinput


Please let me know any comments or suggestions you have.

Thank you,
Alexander Mueller

 

[J.O. Aho]

Hi,

the reason behind my email is the proposal of a new Input type named "hash"

<input type="hash" />

I am now going into detail about why I'd consider it as important and
technical information as well as comparisons to current techniques.

I can't see any extra advantage of your input has, more than it will just
consume more bandwidth for transporting the data. The has type will always be
the same for a site, as the passwords will always be stored in that type, a
site that uses md5 hashed passwords will never request a sh1 hashed password,
as then they can't validate the password is correct.

The method will be predictable and complicated to use and just gives a false
feel of extra security.

 

[Alexander Mueller]

I can't see any extra advantage of your input has, more than it will just
consume more bandwidth for transporting the data.

Well, I listed the advantages in the original posting. Please reread it
again to see what I am trying to accomplish with the hash type.

The has type will always be
the same for a site, as the passwords will always be stored in that type, a
site that uses md5 hashed passwords will never request a sh1 hashed password,
as then they can't validate the password is correct.

I never talked about a mixture of hash types.

It is about the secure transmission. The hash for a password will never
be the same for a site but only for identical passwords (which is a
required behaviour).

The method will be predictable and complicated to use and just gives a false
feel of extra security.

Can you explain why? The only difference is that the hashing occurs
locally and so gives a much better security to the actual data. Its
neither more predictable nor complicated than the current solution.


Alexander

 

[richard]

Hi,

the reason behind my email is the proposal of a new Input type named "hash"

You have posted this "email" to a usenet newsgroup which is not
maintained, or staffed by any one particular company or organization.

You would need to impose your request on the creators of each
individual browser. IE, FF, opera, pan, slrn, xnews,xananews and so
on. Along with maybe trying to convince the w3c.org people to make it
a viable include.

Then after a few years, it might get developed. However, no guarantees
that it will.

 

[Alexander Mueller]

I can't see any extra advantage of your input has, more than it will just
consume more bandwidth for transporting the data.

As to the traffic, yes, it will generate more traffic as long as the
actual password is shorter than the hash (32 bytes for MD5, 40 bytes for
SHA1). But considering only a 5 byte long password I would say the extra
traffic of 27-35 bytes is worth the added security (some HTTP headers
often take more).

Alexander

 

[Alexander Mueller]

You have posted this "email" to a usenet newsgroup which is not
maintained, or staffed by any one particular company or organization.

The "email" happened because I took the text straight from a copy which
was sent to w3.org.

You would need to impose your request on the creators of each
individual browser. IE, FF, opera, pan, slrn, xnews,xananews and so
on. Along with maybe trying to convince the w3c.org people to make it
a viable include.

I did, see above

Then after a few years, it might get developed. However, no guarantees
that it will.

Well, for Firefox there is already a concept implementation .

Alexander

 

[J.O. Aho]

J.O. Aho wrote:

I never talked about a mixture of hash types.

It is about the secure transmission. The hash for a password will never
be the same for a site but only for identical passwords (which is a
required behaviour).

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.

 

[Alexander Mueller]

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. This can then be compared to the
stored hash code. The only difference is the computation of the hash
happens locally - no brute force, no same passwords.

Alexander

 

[Jeff]

Sorry I dont really know what you are exactly meaning.

I think he's talking about the salt. Do you pass the salt with the
form submit, if you do, what is the security advantage?

All this looks a bit like unix password encryption where no one knows
the password, only if it is wrong. What would the application be?

Jeff

 

[Alexander Mueller]

I think he's talking about the salt. Do you pass the salt with the form
submit, if you do, what is the security advantage?

A salt is always used to have a hash which is different from the regular
hash (to prevent precomputed hash tables). In case of salt, it certainly
always have to be the same.

As to the replay salt, this would only be used to prevent replay attacks
and would or better should always be differently. Of course it wouldnt
be used to store the password hash.

All this looks a bit like unix password encryption where no one knows
the password, only if it is wrong. What would the application be?

Well, yes, hashes are used in Unix too, but it is a general solution and
most websites use a hash to store passwords with the exception that the
server is generating the hash.

Alexander

 

[Harlan Messinger]

I can't see any extra advantage of your input has, more than it will just
consume more bandwidth for transporting the data. The has type will always be
the same for a site,

The attribute tells the *browser* what kind of hash to create.

as the passwords will always be stored in that type, a
site that uses md5 hashed passwords will never request a sh1 hashed password,
as then they can't validate the password is correct.

The browser doesn't have pre-existing knowledge that such-and-such site
uses MD5 hashed passwords (though a default hash method could be defined
in the standard, just as there is a default value for the enctype
attribute of the form tag).

 

[Harlan Messinger]

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]

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

 

[Harlan Messinger]

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?

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.

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.

 

[Disco Octopus]

Hi,

the reason behind my email is the proposal of a new Input type named "hash"

<input type="hash" />

Please let me know any comments or suggestions you have.

Thank you,
Alexander Mueller

A few years ago we had implemented a similar concept using javascript
and hashing of the password pre posting.

As others have mentioned, it did not prevent hackers from obtaining
the hashed value, which of course was the same value as to be
retrieved on the server.

Perhaps naivety led us to feel that if the hacker did not know exactly
what was entered into the form (pre hash), then this was at least some
form of security.

I think it is a great idea that you have, and I do hope that it will
be at least investigated to the nth.

 

[Alexander Mueller]

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. Whether he is allowed to access it directly is
another issue.

then why does it matter at all whether the administrator can see the
password or the hash or anything else?

Password and Replay protection.

You mentioned addressing this with SSL. Your rationale for your approach
was to shield the password from the administrator as well.

In terms of SSL, yes. But for HTTP it would also provide additional
security layers.

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.

Not only necessarily to someone else, but also abusing it for other
accounts of the user.

Alexander

 

[Alexander Mueller]

Unfortunately Disco Octopus' posting isnt listed on my newsserver, so I
have to reply to myself .....

A few years ago we had implemented a similar concept using javascript
and hashing of the password pre posting.

As others have mentioned, it did not prevent hackers from obtaining
the hashed value, which of course was the same value as to be
retrieved on the server.

Perhaps naivety led us to feel that if the hacker did not know exactly
what was entered into the form (pre hash), then this was at least some
form of security.

Of course, attackers can obtain the hashed value, but this is a simple
replay attack and not the primary target of the hashing idea itself.
Here the replay salt comes into play.

I think it is a great idea that you have, and I do hope that it will
be at least investigated to the nth.

Thank you, if you use Firefox 2 please have a look at the mentioned
extension to see the actual concept.

Alexander

 

[Harlan Messinger]

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


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


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]

A few years ago we had implemented a similar concept using javascript
and hashing of the password pre posting.

As others have mentioned, it did not prevent hackers from obtaining
the hashed value, which of course was the same value as to be
retrieved on the server.

Perhaps naivety led us to feel that if the hacker did not know exactly
what was entered into the form (pre hash), then this was at least some
form of security.

Of course, attackers can obtain the hashed value, but this is a simple
replay attack and not the primary target of the hashing idea itself.
Here the replay salt comes into play.

I think it is a great idea that you have, and I do hope that it will
be at least investigated to the nth.

Thank you, if you use Firefox 2 please have a look at the mentioned
extension to see the actual concept.

Alexander

 

[Alexander Mueller]

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

Okay, but then we are in a completely different area. Administrative
access is always more than just user access.

Alexander