- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 4 May 2012 18:43:39 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 4 May 2012 11:43:39 UTC