Identify popular sites that munge usernames/passwords and create a plan to not save munged values
Categories
(Toolkit :: Password Manager, task, P2)
Tracking
()
People
(Reporter: MattN, Assigned: sfoster)
References
(Depends on 2 open bugs)
Details
User Story
Username Sites: * stockplanconnect.morganstanley.com: username "myusername" becomes my*****me on blur, "use" becomes "u*e" * td.com: myusername is transformed to: myu••••ame (U+2022 / BULLET), "use" becomes "•••", "user" becomes "u••r", "usern" becomes "u•••n" * 401k.com / fidelity.com: longerusername is transformed to ***********ame, "usern" becomes "**ern", "user" becomes "*ser", "use" is left as "use" * online.citi.com: someuser is transformed to so****er, "usern" becomes "u***n", "user" becomes "u**r", "use" becomes "u*e", "us" is left as "us" * netbenefits.com: myusername becomes *******ame * us.hsbc.com: myusername becomes "x" A simple match for /[•*]{2,}/ may catch the low-hanging fruit on the username-munging issue. Password sites: * https://personal.yesbank.co.in/netbanking/entry - turned "somepassword" into 094BF55C273618D8AFC41F75D33B7193 * https://retail.onlinesbi.com/retail/login.htm - wrong password: Dummy@123 * … We don't have enough data yet to know if the password-munging issue is a) widespread, and b) solvable in a practical way.
Sites, mostly financial ones, will sometimes obfuscate/munge usernames and/or passwords for various reasons and then we sometimes ask to save those garbage values in the password manager. It's not always clear to the user that we aren't saving the correct value since they may think that we are also censoring the values in the same way for their benefit when, in-fact, we will save the munged values.
Some sites munge upon blurring the field, some munge as you type more characters, some only munge before submitting. This bug is about creating a plan to not save the munged values, not necessarily to offer to save the correct values. We should identify some popular sites and see how we could detect a masked/munged login value (e.g. see which characters they use and the patterns). We can also look into how other password managers handle this.
Example username masking/munging
Username: [jsmith ] => Username: [***ith ] (from 401k.com)
Reporter | ||
Updated•6 years ago
|
Assignee | ||
Comment 1•6 years ago
|
||
So far I have:
- http://www.td.com/ (from bug 1531651)
- myusername is transformed to: myu••••ame (U+2022 / BULLET)
- alongerusername is transformed to alo•••••••••ame
- https://401k.com (redirects to https://fidelity.com/) (Bug 1313699)
- sfoster is transformed to ****ter (ascii asterix)
- longerusername is transformed to ***********ame
- https://online.citi.com/
- someuser is transformed to so****er (ascii asterix)
- alongeruser is transformed to al*******er
Assignee | ||
Comment 2•6 years ago
|
||
I've tried out about 20 personal/online banking login forms and I've not yet found other examples of the username being transformed in this way. So if anyone has examples, please add them here. capitalone.com (from the user story) does not reproduce for me (anymore?)
Assignee | ||
Comment 3•6 years ago
|
||
The sites I've tried so far. Where there was a choice, I've just tried the consumer online banking login. Its possible there are different forms and schemes for other account types for a given bank. Some sites have a multi-page login where they challenge an unrecognized username.
-
https://www.kiplinger.com/login/ - no issue
-
https://jpmcsso.jpmorgan.com - no issue
-
chase.com - no issue
-
bank of america - no issue
-
Citibank - does munge the username as you type it. No passwordmgr prompt "
- they use a input name=username which has class userMask, autocomplete=off and another display:none input where they copy the actual username to. The real one has name=username, aria-describedBy the label, the masked one has class userMask,
- They have 5 type=password fields. All but the last one are positioned offscreen. The label for attr points at the real one, has autocomplete=off, aria-describedBy and aria-label
- someuser becomes so****er, alongeruser becomes al*******er
-
https://www.bankofamerica.com/ - No issue
-
https://connect.secure.wellsfargo.com - no issue
-
https://www.capitalone.com/ - no issue
-
https://online.columbiabank.com - no issue
-
- userid challenge, but no sign of munging?
-
https://onlinebanking.huntington.com - no issue
-
https://www.suntrust.com/personal-banking - no issue
-
https://www.ucbi.com/Personal - no issue
-
https://retail.onlinesbi.com/retail/login.htm
- Didn't munge username, but wrong password: Dummy@123
-
https://www.washingtonfederal.com/personal-banking - no issue
-
- Didn't munge username, but wrong/dummy pasword
-
https://online.woodforest.com/ - no issue
-
IDCF Bank - No save password prompt.
-
https://www.greatwesternbank.com/personal/banking/ - no issue
-
https://www.amerisbank.com/personal-banking/ - username challenge,
-
https://www.amerisbank.com/personal-banking/ - no issue
-
https://personal.yesbank.co.in/netbanking/entry - No username munging, but turned "somepassword" into 094BF55C273618D8AFC41F75D33B7193
-
https://www.bankatunited.com/Personal - Missing username from save password prompt
Assignee | ||
Comment 4•6 years ago
•
|
||
- https://www.ally.com/ - No issue
- https://www.bank5connect.com/home/home
- Login opens new tab, no save password prompt
- https://www.tiaabank.com/banking/online-banking - No issue
- https://www.discover.com/online-banking/ - No issue
- https://www.axosbank.com/ - No issue
- https://www.fnbodirect.com/
- Multi-step login. No username in save password prompt.
- https://www.statefarm.com/finances/banking - No issue
- https://www.synchronybank.com - No issue
- https://www.firstib.com/
- No username in save password prompt.
- https://www.nationwide.com/personal/login
- Requires you to select account type. Presumably you could have the same username but different account type and different password for cases like this
- No issue with username/password in save password prompt
Assignee | ||
Comment 5•6 years ago
•
|
||
- https://stockplanconnect.morganstanley.com/
- username "myusername" becomes my*****me on blur
- no save password prompt so I can't confirm if we would save the original or munged username.
- https://netbenefits.com Fidelity Net Benefits
- Munges username on blur, and this is what we offer to save; myusername becomes *******ame
- https://www.americanexpress.com/
- Apparently used to mask values in the username field
- Will reportedly mask a remembered username (i.e. mikesurname becomes mike*******)
- https://united.com/ mileageplus signin
- No issue
Reporter | ||
Comment 6•6 years ago
|
||
Please edit the user story to keep it updated with the sites that do munge.
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 7•6 years ago
|
||
- https://us.hsbc.com
- has 2 step login and verifies the username so I can't confirm without an account, but reportedly at the end, the password manager has just the letter "X" for the username
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Updated•6 years ago
|
Reporter | ||
Updated•6 years ago
|
Reporter | ||
Updated•6 years ago
|
Assignee | ||
Comment 9•6 years ago
|
||
This investigation/plan has gotten as far as it is likely to for now. We can open a new bug when we have new data.
Here's where we ended up:
We spotted a pattern with various sites transforming the username as-typed to partially mask it. This masked/"munged" value was being presented in the save password prompt and saved as the username for that login. Bug 1427624 addressed this by clearing the username (so the user could re-input it) whenever we matched a pattern of 3 or more "*" or "•" characters in the username.
Some sites were causing us to prompt with a single 'X' as the username. This turns out not to be a symptom of the site deliberately munging the value and is now being tracked in bug 1546749.
Munged/transformed passwords represent a different kind of problem, and there was no clear pattern or generalized fix. In cases where we end up saving the wrong password, the cause is typically a 2nd type=password field in the form rather than directly manipulating the value the user entered. Sometimes the field exists to confound password managers, sometimes it is necessary in the context of the specific form. I didn't identify any single change we could make that would have positive impact on user's experience without creating as much or more risk of regression or site-compatibility failure. We can revisit this if we get more reports and data to work with.
Comment 10•6 years ago
|
||
Given the fix && verification in bug 1427624 and the fact that this seems to be more like a investigation task, I would assume this should be a qe-, MattN could you please confirm that there's nothing QA needs to do here?
Reporter | ||
Comment 11•6 years ago
|
||
That's correct.
Description
•