Closed Bug 1530814 Opened 11 months ago Closed 9 months ago

Identify popular sites that munge usernames/passwords and create a plan to not save munged values

Categories

(Toolkit :: Password Manager, task, P2)

task

Tracking

()

RESOLVED FIXED

People

(Reporter: MattN, Assigned: sfoster)

References

(Depends on 3 open bugs, Blocks 1 open bug)

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)

Assignee: nobody → sfoster
Status: NEW → ASSIGNED

So far I have:

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?)

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.

Please edit the user story to keep it updated with the sites that do munge.

User Story: (updated)
  • 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
Duplicate of this bug: 1119077
User Story: (updated)
User Story: (updated)
User Story: (updated)
Type: enhancement → task

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.

Status: ASSIGNED → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED

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?

Flags: qe-verify?
Flags: needinfo?(MattN+bmo)

That's correct.

Flags: qe-verify?
Flags: qe-verify-
Flags: needinfo?(MattN+bmo)
You need to log in before you can comment on or make changes to this bug.