Open Bug 1570319 Opened 5 years ago Updated 2 years ago

"No username" in case of secure autosaved passwords is not intuitive enough

Categories

(Toolkit :: Password Manager, defect, P3)

70 Branch
defect

Tracking

()

Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- unaffected
firefox68 --- unaffected
firefox69 --- disabled
firefox70 --- wontfix
firefox71 --- wontfix

People

(Reporter: aflorinescu, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [passwords:generation])

[Short version:]

  • differentiate between autosaved generated passwords and the rest of the cases that might generate an empty username entry
  • mitigate the accidental deletion of autosaved secure passwords due to the fact that users might not logout/login in order to update the changed password right away and it's possible that a "No username" / password might be accidentally saved over the autosaved secure password - which is actually the new changed password.
  • improve the user experience while trying and filling the login with the original user/password.

[Long version:]

Taking into account the possible scenarios where the generated password is going to be used (pass_change, account creation) and also considering that Fx not always catches the right combination of u/p and also the fact that the management section allows creating empty usernames, QA would like to suggest that maybe using some obnoxious string like SECURE_AUTOSAVED_PASSWORD as username for the autosave would improve the user experience while using the generate feature.

We think that having an explanatory username for the autosave will also aid into improving the situations in which, after password change, the user/password combination is the original one and the changed password is stored into the autosaved one.

To exemplify:

  • Current user interaction:
  1. user credentials are saved: about:logins - 1 entry Myuser/MyPassword
  2. user changes password using pass generation: 2 entries 1. Myuser/MyPassword 2. "No username" / gen3rat3d_passw0rd
  3. the user logs out and accesses again the login form: autofill populates Myuser/MyPassword (since the no username is not considered a valid username) -> login fails
  • Proposed user interaction:
  1. user credentials are saved: about:logins - 1 entry Myuser/MyPassword
  2. user changes password using pass generation: 2 entries 1. Myuser/MyPassword 2. SECURE_AUTOSAVED_PASSWORD / gen3rat3d_passw0rd
  3. the user logs out and accesses again the login form: no autofill happens and the username will display two options: Myuser and SECURE_AUTOSAVED_PASSWORD, thus making it obvious to the user that in the case of the login failure, the generated password is there and therefore a bit easier to figure the fact that he needs to use the generated password and update the original login.

[Note:]

  1. This report encapsulates a few usability concerns related to password generation, and although, the good practice would dictate this bug would get split into several actionable items, we couldn't find a good way to just do that, at least not before the initial review and feedback.
  2. We've decided to originally log this as a defect, rather than an enhancement due to the fact that we consider usability high priority

I think bug 1569917 would help with this to make it clear the user should update to add the username. I will read this closer later. I'm talking to Adrian about this on Slack now.

Flags: needinfo?(MattN+bmo)
Blocks: 1571647

Could we get a priority set to this bug please? Thanks

I was waiting to see how bug 1569917 would turn out. I personally don't think it's a P1 now that we addressed it.

P2 for now but it may become P3. Ryan, what do you think about this bug for 70?

Depends on: 1569917
Flags: needinfo?(MattN+bmo) → needinfo?(rgaddis)
Priority: -- → P2

I agree on de-prioritization for now. We can discuss more in depth if we feel it merits digging in on for 70, but the proposed fix is not ideal.

Flags: needinfo?(rgaddis)
Priority: P2 → P3
Whiteboard: [passwords:generation] [skyline] → [passwords:generation]
See Also: → 1560468

Still happening on 86.0.1 (64-bit). The workaround I've found is:

  • generate a password
  • it will then pop up a "key icon" in the address bar. click on it
  • I select the correct username in the dropdown and click to update

Also, unrelated to this bug (but I could not find an open bug for this):
FF is generating always the same password for a given website: https://www.reddit.com/r/firefox/comments/ledb6e/why_is_ff_repeatedly_generating_the_same_passwords/

Severity: critical → S3
You need to log in before you can comment on or make changes to this bug.