W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2014

Re: Proposal for a credential management API.

From: Jacob S Hoffman-Andrews <jsha@eff.org>
Date: Thu, 31 Jul 2014 11:19:19 -0400
Message-ID: <53DA5E77.1060701@eff.org>
To: Mike West <mkwst@google.com>, Webapps WG <public-webapps@w3.org>
I like the idea of standardizing some of the interactions between 
password managers and web sites.

I think we should strongly consider ways to integrate XSS 
mitigation. Hopefully before too long most people will be using a 
password manager. With most password managers, if there is a 
transient XSS on example.com, an attacker can use that XSS to trick 
the password manager into autofilling the password for example.com. 
This means, even though the XSS exposure might be temporary, the 
attackers can steal a large number of passwords, extending the 
attack window indefinitely.

Some other reasons that XSS + password stealing is worse than plain XSS:
  1) Passwords are often reused across web sites, so damage from 
password stealing spreads fast.
  2) When the XSS is fully client-side, it is impossible to figure 
out which users had their passwords stolen. There is no way to reset 
their passwords and they may remain compromised indefinitely.
  3) Sites often require re-entering passwords for privileged 
actions like changing email address or adding an SSH key. Adding 
password stealing to an XSS acts like privilege escalation, allowing 
actions that aren't possible with a plain XSS.

Cookies have a very similar problem. If an XSS can grab the user's 
authentication cookies, the attacker can prolong their attack even 
after the XSS hole is closed. Microsoft addressed the problem in 
2002 by adding the 'HttpOnly' flag for cookies in MSIE 6 SP 1. All 
browsers implement it now, to great effectiveness. At a past job, I 
fixed XSS for a top ten web site, and I can testify that it was 
incredibly valuable to know that attackers were not stealing our 
authentication cookies, because we set the HttpOnly flag..

There's no HttpOnly equivalent for password forms, but that's 
largely because password storage by the browser has never been 
specified. As long as we're trying to specify parts of that storage, 
I think we should strive for HttpOnly passwords. It's challenging 
because there are many different login techniques, but I think we 
can make it happen if web sites opt in.

I'd say there are approximately three styles for login form submission:
  A) No JS. A <form> with some <input type=text>'s that gets 
submitted when you click an <input type=submit>.
  B) Some JS. A <form> that gets submitted by JS calling form.submit().
  C) All JS. A set of <inputs> whose contents are extracted by JS 
and POST'ed via XHR to the server.

Clearly we can't make C safe against XSS. But I think a lot of web 
sites currently use A or B, or would be willing to use them in 
exchange for better security.

Here's a rough idea: Define a new attribute 'httponly' for input 
elements. When a text input has httponly=true and the password 
manager saves the input value as a PendingCredential or a 
Credential, the password manager also stores an attribute 
httpOnly=true on the Credential. When the password manager autofills 
forms using a Credential with httpOnly=true, it should fill a 
placeholder value (possibly a numeric identifier for the 
Credential). When a form is submitted, the password manager should 
intercept the HTTP request and replace the placeholder value with 
the contents of the Credential.

Note that this proposal doesn't break password strength meters 
implemented in JS, because it only addresses subsequent autofills of 
credentials. The first time a password is entered, e.g. during 
signup or change password, it is still fully accessible to JS.

Received on Thursday, 31 July 2014 15:19:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:26 UTC