[whatwg] password-related feedback on forms
ian at hixie.ch
Fri May 4 11:43:39 PDT 2012
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
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"
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).
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
> 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:
> 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
I don't understand what problem this solves. Can you elaborate?
> 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?
> 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
Sites seem to do this pretty well themselves, currently. Is there a need
> - 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg