[whatwg] password-related feedback on forms

[Ian Hickson]

On Thu, 16 Jun 2011, Sean Connelly wrote:
> 
> Websites commonly need to store login information for users.  Web 
> developers may naively store the password in non-secure ways 
> (plain-text, md5 with no salt, etc).  It has become common for hacker 
> groups to target websites to get a data-dump of all users/passwords, and 
> using this information, try to compromise accounts on other websites.

This is a true problem.


> ## Proposed Solution:
> 
> Add an attribute to <input type="password"> called "hash".  For example:
> <input type="password" hash="sha1" salt="something">
>
> This will indicate to the browser that it needs to hash the value 
> locally before sending it to the server.  This hash should include a 
> site-specific salt, so that the same password typed on two different 
> sites will hash to different values.  I propose the default salt to be 
> the origin as an ASCII string (protocol + host + port, ex: 
> "http://example.com:80"), and the default hash to be "none" (in order 
> for backward compatibility).

It has to be a per-user salt, not per-site. If you do it per-site, then an 
attacker just has to hash all the common passwords and common dictionary 
words and other likely words to get a big table they can compare against 
the hashes. If it's per-user, the complexity is multiplied by the number 
of users, which makes this dramatically harder.

Unfortunately it's not clear how you would do a per-user salt. All the 
user agent has is the username, which you don't really want to use as a 
salt since that would preclude changing it.

(We can't rely on the author providing a unique salt; the assumption here 
is that the author is not familiar with good security practices. If the 
author was able to do that, then we wouldn't have a problem to solve in 
the first place.)


On Thu, 16 Jun 2011, Sean Connelly wrote:
> 
> This strikes me as abnormal; I'm not aware of the browser injecting form
> values for any other functionality.

There are quite a few actually.

   <input type=hidden name=_charset_>
   <input type=text name=a dirname=b>
   <input type=image name=c>

After an activation of the image, the above results in the following 
fields and values:

   _charset_ = utf-8
           a = 
           b = ltr
         c.x = 0
         c.y = 0


> > [just pick a single hash]
> 
> The disadvantage to this approach is that, years from now, the default 
> may be compromised (like md5).

At that time, we could provide a way to change the hash function.


> By always forcing the webmaster to choose a value, it helps to make it a 
> conscious choice, as opposed to "just add `hash` to all input tags" 
> behavior.

We are assuming here that the authors are not able to make a good 
conscious choice. If they were, there wouldn't be a problem for us to 
sovle in the first place.


> If there is a default hash, then it will be the first target for hackers 
> to break.

I'm pretty sure they don't need any more motivation. :-)


On Fri, 17 Jun 2011, Aryeh Gregor wrote:
> 
> The problem is it solves much less of the problem than hashing is 
> supposed to solve, but to the uninitiated it looks the same as a real 
> hashing scheme.  It gives a false sense of security that probably 
> outweighs any actual security benefit (which is very limited).

Agreed, unfortunately.


On Mon, 11 Jul 2011, Bjartur Thorlacius wrote:
> >
> > boolean passwordEquals(in HTMLInputElement otherPassword);
>
> I believe this to belong to CSS. User agents could either ask or require 
> users to input error-prone and important fields twice, without 
> submitting the same value twice.

That's possible. CSS or some components framework.

(I haven't added passwordEquals() because it's trivial to just compare 
them by doing a.value == b.value, and we can't realistically remove the 
capability to do that so there's no win from the method.)


> Note that the confirmation input in 
> <http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-required-attribute> 
> is optional.

That's intentional. If they don't match, there's already an error, so 
making it required doesn't help.



On Sun, 23 Oct 2011, Michael Herold wrote:
> 
> **Suggestion**
> Add a new possible value "auth" to the HTML <form> //method// attribute.
> If input elements named username/password are present they are used to
> authenticate. Otherwise the first input element is used as username and
> the first input[type=password] element is used as password.
> 
> The aim would be to create custom login and logout dialogs without
> JavaScript.

I don't understand what problem this solves. Can you elaborate?


> **cookies**
> Putting a session (+user) in a cookie.
> - broken by standard (none standard SLD fix in every browser)

Not sure what you mean here.


> - disabled or not supported by many clients for various reasons

Cookies work pretty uniformly as far as I can tell. After all, that's what 
almost every site uses.


> - leaves footsteps on hdd per definition

No more so than HTTP auth, right?


> **HTTP-Auth**
> Basic or Digest Access Auth
> - the "right" way to authenticate

I don't see why it's right. It has all kinds of problems -- poorly defined 
session duration, depends on the password being unchanged during the 
session, and we'd have to add all kinds of APIs to make it possible to do 
custom login/logout, handle session closure, support OAuth et al, handle 
account creation and handling "forgot password" paths, etc.


> - the browser may give the user the full controle/overview over page
> logins

Sites seem to do this pretty well themselves, currently. Is there a need 
for more?


> - very simple to set up

I'm not sure it's really that much simpler than cookies.


On Thu, 27 Oct 2011, Robin Aaberg Garen wrote:
> 
> I fret frequently when I see the unsupported features of the HTTP 
> protocol not being used because of missing support in browsers and 
> servers. Like the PUT and DELETE.  And this enchancement of the AUTH.

There's two ways to fix that... add support for the features, or remove 
the features altogether. :-)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'