Re: New Input type proposal

On Jan 9, 2008, at 8:58 AM, Alexander Mueller wrote:

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

I don't think this provides much security advantage without the  
"replaysalt" attribute. If the hash is your actual authentication  
credential, then an attacker who sniffs it could just log in as you.

So the only worthwhile part of this is the ability to hash the  
password combined with a one-time salt (the "replaysalt"). However,  
that feature does not seem workable. The server would have to know at  
the time you submit the form what "replaysalt" value it sent you. But  
there's no way to know that without sending it (or some other session  
token) along with the request, which makes it once again replayable.  
Using something more like http digest authentication may be more  
effective in defending against replay attacks, but still leaves the  
account registration process unprotected.

I'm not sure it's worth providing stronger protection to unencrypted  
connections. All sorts of man-in-the-middle attacks are possible.

Regards,
Maciej

Received on Friday, 11 January 2008 01:54:58 UTC