New Input type proposal

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

-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

Received on Thursday, 10 January 2008 15:37:28 UTC