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 with some 's that gets
submitted when you click an .
B) Some JS. A that gets submitted by JS calling form.submit().
C) All JS. A set of 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.
Thanks,
Jacob
