Improve the usability of securely generated passwords
Categories
(Toolkit :: Password Manager, enhancement)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr60 | --- | unaffected |
| firefox-esr68 | --- | unaffected |
| firefox68 | --- | unaffected |
| firefox69 | --- | unaffected |
| firefox70 | --- | affected |
People
(Reporter: aflorinescu, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [passwords:generation])
When "Use a securely generated password" option for a password field is used, is not obvious for an user that re-using the "Use a securely generated password" option again will not generate a new password, but reuse the same generated password per session/principal.
Possible suggestions in my opinion:
- Split the label "Use a securely generated password" into two: "Generate & use secure password" when there is no password yet cached and "Use the securely generated password" when we have one generated for that particular principal.
- Add some sort of info when first using generate secure password, although not a very big fan of this, since I cannot envision a slick implementation for this that won't overload the UI.
|
Reporter | |
Updated•5 years ago
|
|
||
Comment 1•5 years ago
|
||
(In reply to Adrian Florinescu [:adrian_sv] from comment #0)
When "Use a securely generated password" option for a password field is used, is not obvious for an user that re-using the "Use a securely generated password" option again will not generate a new password, but reuse the same generated password per session/principal.
Possible suggestions in my opinion:
- Split the label "Use a securely generated password" into two: "Generate & use secure password" when there is no password yet cached and "Use the securely generated password" when we have one generated for that particular principal.
That was bug 1548854 but was cut from skyline scope. This was also brought up in the sec review.
- Add some sort of info when first using generate secure password, although not a very big fan of this, since I cannot envision a slick implementation for this that won't overload the UI.
Yeah, I don't think that will work well.
Description
•