Stopping XSS in the application is obviously the responsibility primarily of the developer. That being said, XSS still happens. As a result, people playing other roles in the use of the web application (primarily browser vendors and servers) have implemented piecemeal protections that partially mitigate XSS by narrowing the attack surface or eliminating attack vectors. Iframe injection is mitigated by the X-FRAME-OPTIONS header, and by frame busting code. Cookie theft is partially mitigated by the HTTPOnly flag. There are also emerging techniques which promise to be even more effective such as Content Security Policy.

I think that disabling autofill by default would partially mitigate the theft of credentials. It would not be a complete mitigation though because the user could still be tricked into entering his credentials. Obviously LastPass needs to weigh the benefit of this with the loss of usability. Its not my place to make that call and it sounds like you guys have put some thought into it. I might have done it differently, but I respect your judgment. Its not going to stop me from using LastPass.

Bottom line is that if the website has an XSS vulnerability, then the attacker can do pretty much anything. They can steal cookies, capture keystrokes, even redirect inject a rogue iframe on top of the actual page that asks the user to log in. So, no amount of increased security by the password manager can fully protect the user. All the password manager can do is ensure that the user’s other 100 sites aren’t also compromised by teaching the user good habits regarding never to re-use passwords.

Regarding making the default to associate the credentials to a single page: this would break autofill for a large majority of sites, including some of the most popular sites in the world, and we would be immediately inundated with requests to reverse this behavior. Examples include:
- People sign up for new services using a register page, and then sign in with a sign in page
- A website changes the page where their sign in form is located (this has happened for even the most popular of sites like Twitter)
- A website allows you to sign in on more than one page
- etc.

It even extends past the page to the domain level. eg: If you have a login on google.com, and want to log in at gmail.com or youtube.com. (we have an ‘equivalent domains’ feature to address these automatically for users).

Regarding disabling autofill by default: it’s a similar story. People use a password manager not just for increased security, but also for convenience. Not autofilling by default, doesn’t increase security in any way if the end website has a vulnerability. Further, it would force many people to decide that using a password manager was just too cumbersome and was more work than ‘doing it themselves’ — leaving the user even more susceptible at the end of the day.

Thanks.

if XSS is possible on a website than an attacker can read the password field and that is it, i guess?

As for the idea that XSS could be used to capture user login regardless, I don’t think this is entirely true. A large percentage of applications have distinct login pages that don’t display any user provided content (think Facebook or Gmail). While this is a common design idium, it has the added benefit of protecting against the attack you describe.

I think it would be a much better default for the password manager to associate a set of credentials with a page rather than with a domain. I do understand your security/usibility concern though as this would not work well on applications with login forms on every page. Maybe a good compromise would be to associate the creds with the domain, but to associate the auto-fill settings with the page.

I realize that you LastPass is highly configurable and thats one of the great things about the application. Unfortunately, the people who stick with the default settings are probably the same people who would click on a link to http://goodguys.com?msg=%3cscript%3epwn()%3c/script%3e . Especially for a security product, I think its important to tip the scales towards security in the security/usibility balancing act.

I know you guys do a lot of work to protect people’s credentials on the server side and I really appreciate your companies overall security posture. But, I still feel that the point where your application actually interacts with the DOM is currently the weakest link.

All that in mind, I still agree that LastPass is way better (for many reasons) than the browsers’ built-in password managers. BTW, sorry to pick on your guys in this article. LastPass is what I use, so its what I tested.

- Ben

Good work and thanks for your post and detailed explanation.
Also appreciate that you are an avid LastPass user and your words of praise.

First off, I fail to see why you are (or if you are) blaming the password manager for this issue. If a 3rd party site is vulnerable to an XSS attack, then interception of the user’s credentials will occur when the user logs in whether or not they use a password manager to do so.

So, strictly speaking, this isn’t the password manager’s ‘fault’ and is not being caused by the password manager.

I do see your points that:

(1) the password manager possibly makes capturing the credentials on a vulnerable site perhaps easier due to autofill, and due to autofill on the whole domain rather than just a page

(2) the password manager should try to use mechanisms to perhaps make it more difficult for a vulnerable website to be taken advantage of.

With respect to (1):

There is always a balance between security and convenience and we have tried to strike a good balance in that by default LastPass will autofill credentials based on 2nd level domain.
However:

- LastPass has the ability for the user to control whether a user’s login should be autofilled or not. (for all their sites, or on a site by site basis)
- LastPass has the ability for the user to control whether they should be re-prompted for their master password prior to autofill.
- LastPass has the ability to control whether autofill should occur on a 2nd level domain-wide basis, or just for an exact URL match.

With respect to (2):

We really have tried to do as much as possible to protect end users, such as:
- LastPass allows users to control whether LastPass should warn them before automatically filling insecure forms.
- LastPass allows users to be notified by email if any of their usernames or passwords change.

We also recognized that LastPass.com itself is a possible source of XSS so have implemented CSP in browsers that offer it (https://developer.mozilla.org/en/Introducing_Content_Security_Policy) and where it’s not available we have implemented CSP internally within our browser extensions.

The one last thing that I should point out is that all of the above LastPass features I have mentioned above aren’t present within the default browser password managers, which is one of the many reasons why we feel LastPass is significantly more secure than a browser’s default password manager.

Thanks,
Sameer Kochhar
LastPass