UI guides the user to enter credentials into the wrong site
ipundit opened this issue · comments
General information
- Operating system + version: All
- Browser + version: All
Exact steps to reproduce the problem
This is not a functionality bug, but UI one. It is major UI bug though in that it facilitates a serious breach in security.
- Browse to any login, say https://login.yahoo.com/
- Say now the user wants to go to google log in from there. So, she presses Ctrl+Shift+L and types
google.com enter
to get the following screen:
- What would you do? If you did what I did, I would click the big www.google.com button instead of the globe icon beside it.
- Browserpass then dutifully sent my Google login credentials to Yahoo. It's my fault for pressing the wrong button, but I would say its browserpass' fault for guiding me to press that button in the first place.
What should happen?
I would suggest getting rid of the globe button altogether as per this screenshot:
If I click the big google button and I'm not at google.com, then browserpass would go to google.com and log me in. If I'm already at google.com, then browserpass would fill in the login details and log me in. In either case, my goal of logging into Google is met - the globe icon is not necessary. In fact, I would say it's harmful if its existence guides users to accidentally send their credentials to the wrong site.
Getting rid of the globe button would also solve another use case:
- Browse to any page without a login
- Say now the user wants to go to google log in from there. So, she presses Ctrl+Shift+L and types
google.com enter
to get the following screen:
- Click the big www.google.com button and nothing happens, because there is no form to fill out.
- The user would expect to be logged into Google when she searches for the Google login, and clicks it
If I click the big google button and I'm not at google.com, then browserpass would go to google.com and log me in.
There is one big reason why this is not a desired behavior: you are assuming that credentials from a password entry Y cannot ever be valid on domain X, but it is incorrect. In v3 (which is not released yet) we have a new feature, which encourages you to avoid duplicating password entries if the same credentials are valid on multiple websites. In v3, when you are on domain X and you search and submit credentials for domain Y, browserpass will remember that these credentials are valid for both domains, and next time the credentials will automatically be shown in the popup (so you don't have to search for them again).
For example, in Denmark a lot of websites use "login with national ID", so I can save my credentials in one gpg file, and refer to them on other websites (such as my bank). On a first use I need to use the search feature to find the "national credentials" and log in using them on the bank website. But browserpass will remember than my national ID credentials are valid on my bank website, and next time will put them automatically in the default popup list.
Also, browserpass it's kinda not a bookmark manager, but first of all a password manager 😃. To further protect against accidental form submissions, I set the "auto-submit" option to false by default (user can override this globally or on per-login basis).
Fwiw, though, it would be nice if the big label were to always navigate to the desired site and put my id and password there, and a smaller button for explicitly ignoring that I'm not on a domain which matches the gpg filename. In the interest of security, that would probably be a better choice. If you wish to deliberately use another domain's id/password here, you should be given the option to think about it. :)
I want to use my argument again and say that this is not a bookmark manager, but a password manager 🙂 The current concept is built on the idea that entering a password should be the most easily accessible action, requiring as few keystrokes as possible. When you search a password and hit Enter without focusing on any entry, it fills the form with the credentials from first entry, not goes to a different website as a bookmark manager would.
@maximbaz, I must be missing something here as this sounds like to me that browserpass is specifically facilitating the user to resuse credentials on different sites. The point of a password manager is to allow you to use different credentials to login to different sites, so that when one site is compromised, the attacker will not be able to use those credentials to login to other sites. Lastpass even has a tool called the Security Challenge to help the user find and remove duplicated credentials across multiple sites.
An n-m mapping of logins to sites is to be discouraged, not facilitated.
Comparing Lastpass to browserpass to these two questions, I strongly prefer Lastpass' solution first on security grounds, and secondly on usability grounds:
How does a password manager protect the user from sending credentials to the wrong site?
- Two variants: phishing, and the user accidentally sending credentials to the wrong site
Lastpass:
- Maintains an n-1 mapping of logins to domains.
- It allows the user to choose only those n logins for a given domain.
- However, if the user searches for credentials outside the current domain, he is redirected to the target domain to login, and does not send that target domain's login to the current domain.
- If the same credentials are to be used on a different domain, then the user has to enter those credentials into the second domain, so this creates a duplicate set of logins.
- Lastpass' solution to duplicate logins is to provide a Security Challenge tool to find them, and then encourage the user to change the passwords so that they are different for each domain.
Browserpass:
- Maintains an n-m mapping of logins to domains. m here can be 0 or 1 in v2. I haven't seen v3's implementation yet, but it has been asserted that a design goal is for m to be expanded to be more than one site.
- It allows the user to choose only those n logins for a given domain.
- However, if the user searches for credentials outside the current domain, he is allowed to enter those credentials to the current site. This opens the user to phishing and sending their credentials to the wrong site.
- Browserpass' solution to duplicate logins is to encourage and facilitate their use in v3. I would have to see the implementation before commenting on it.
How does the password manager validate that the login credentials are mapped to the right URL?
Lastpass:
- Upon login to a site, Lastpass saves the (username, password, url) tuple and adds it to its database. The act of logging in is the act of validating the data entry into the password-store database - nice.
- The user can change the mapped URL by editing the login through Lastpass afterwards, and there is no validation done at this step.
Browserpass:
- v3 will provide a tool to add passwords to its database, see Issue #24. I don't know whether the username or URL will be captured, or whether all of this will be collected upon login as v3 is still in development.
- The user can change the mapped URL by editing the login through a 3rd party tool, and there is no validation done at this step. Browserpass implicitly trusts that the tool or at least the results of the tool is not putting in invalid data.
this sounds like to me that browserpass is specifically facilitating the user to resuse credentials on different sites.
Not exactly, browserpass is facilitating the user not to duplicate their credentials in multiple gpg files if two websites share a common account (e.g. amazon.com
and amazon.co.uk
), where changing your password has immediate effect on two domains — with browserpass you only need to change the password in one file.
I expect users to understand that browserpass is a password manager, and it's primary goal is to submit a password. When a popup is first opened, it is only filled with credentials that match the current domain — right here is the guard against phishing attacks. If a user wants to submit different credentials, for whatever reason, they make a conscious decision by pressing Backspace, searching for the right credentials and clicking on them.
The goal is not to provide a useful bookmark manager, so people can navigate to google.com via browserpass. The goal is to protect against phishing attacks, but not stand in a way if for whatever reason user wants to use other credentials on the current domain. There could be legitimate reasons for this, like multiple amazon domains or Danish banks that share the same account.
I wish I could remove the globe button and this entire feature of navigating to different URLs via browserpass, but unfortunately this is needed to support basic auth (#103) — an extension can only submit basic auth credentials to a URL if and only if that URL was opened by that extension.
Ok thanks for the clarification. I learned something today - Lastpass supports that too, but on a per site basis, not a per login basis. This makes sense - if I have multiple logins on amazon.com, then I want all those multiple logins to work for amazon.co.uk. Lastpass' solution for multiple site sharing the same credentials worked so well that I didn't even know it was doing this for me until today - "it just all works."; that's good UX. For example, I have changed my password on amazon.com before, and I can still login to amazon.co.uk, amazon.ca, etc. without having to create or change passwords on those sites - so it's one login for multiple sites and I didn't even know that until now. But crucially; I didn't set that up - Lastpass did that for me.
I've attached the list of equivalent sites that are pre-programmed into Lastpass and you would be free (and recommended) to pre-program into v3:
equivalent sites.xlsx
and a screenshot that shows how a user could add more:
Does this per-site approach as opposed to a per-login approach for equivalent domains solve your intended problem for v3? If so, then fixing the UI so that it prevents phishing and accidental entries of logins into the wrong site would fix a major hole in browserpass' security. As it stands, browserpass' UI would be too dangerous for me to recommend "normal users" to use; see #276 to see what I am defining as "normal user".
The globe icon and basic auth
As for handing basic auth, I see two solutions:
-
My preferred embodiment would be to get rid of the globe icon all together and browse to the URLs for all sites, or login to that site if you're on it. That way, you're handling both the basic auth case and the normal case exactly the same. This is Lastpass' solution BTW and forms a simpler and more consistent UX.
-
But if you're insisting on not supporting the ability to launch a website even the user has provided the URL for you and has just clicked it (what else would a user expect if he has a button with a URL on it and he just clicked it - wouldn't he want to go that site? :), then provide a UI to flag which sites are basic auth sites (or just read a
basic auth: true
flag in the site's gpg file), and display the globe icon only for those basic auth sites.
In the great majority of cases, the globe icon is not there, so the user can't click it. This also handles the case where there is no URL set for a login. Currently, browserpass gives an error when you click the globe icon; avoiding errors whenever possible is a better UX - just don't have the button there if you don't want the user to click it; or can you at least grey it out with a tooltip to explain why the user can't click it?)
The globe icon clutters the UI and is not necessary; in fact, it causes confusion. Lastpass doesn't have it, and it handles basic auth just fine. My vote would be to get rid of it.
#276 is weird, I didn't get a notification that you created it, and I'm not sure if you were notified of my response (I reported this to Github), but I tried to explain the target audience (Bob persona) and project goals in more details. Please have a look.
Regarding the list of "equivalent domains", not only I don't want to introduce a centralized point of trust and maintain such a list for the entire internet (the list from lastpass is suspiciously small), but in my mind it would actually harm Bob if browserpass enforced these "automatic" rules upon him, he might even consider this being an instance of a phishing attack. Bob is tech-savy and wants to be in full control of where his credentials gets matched, no magic.
Regarding the globe button, I'll quote myself from #276: I don't think the experience is that bad. Yes, it was confusing on the first try that you have to press globe button and not the url name, but next time you already know where you need to press - and the button is just 2cm to the right. The globe button should work for every password entry that has a domain name in it, open a new issue if Globe button throws errors for you and describe some context, we will fix it. If you are a keyboard user, there are also shortcuts available, see README.
Bob is tech-savy and wants to be in full control of where his credentials gets matched, no magic.
The only problem I have with this statement is that I have converted my house over to mostly Linux, including the kids and spouse - which are NOT tech savvy.
I've been trying to educate them on gopass
and this browserpass
; but, it has been difficult and a bit too "techie".
This statement above kind of quantifies what I see now are deliberate design decisions in this product.
IMO, BrowserPass can be both: user-friendly, and tech savvy.
It can be user-friendly by making best-practices assumptions of UX workflows (like @ipundit is suggesting).
However, "techies" are used to digging into settings and disabling/changing/adding code to make things work the way they want it to (e.g. to disable "best practices" suggestions, and just force the user to make decisions - like to click the globe icon or not).
@maximbaz would you consider this approach in future design decisions?
The only problem I have with this statement is that I have converted my house over to mostly Linux, including the kids and spouse - which are NOT tech savvy.
Why is this relevant? There are many password managers available for Linux. If the users you refer to here are not tech savvy, browserpass is probably not the right choice for them - they are unlikely to be the kind of user that browserpass is intended for.
I've been trying to educate them on gopass and this browserpass; but, it has been difficult and a bit too "techie".
Choose a different product - this is not the right one.
Would you consider this approach in future design decisions?
We already do. Good UX is important, and where possible we make design decisions that make things easier for users. That trend continues with v3. However, it's important to remember who our target users are - if a UX decision would significantly compromise those users, then it's probably not a good idea, even if it might make things easier for "non-tech-savvy" users.