1892035 - generated password is too short if you first submit a short verification code (type=password) before getting to the password creation form

Status: NEW

(Toolkit :: Password Manager, defect)

Description

[albeec13]

Attachment: Clipboard_04-17-2024_01.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0

Steps to reproduce:

While performing a password reset on the transunion.com website, I clicked the button to use a securely generated password in the password field.

When this happened, I went to the password settings page and found this generated password in the list, and removed it. I then refreshed the page, but it continued to offer the same short generated password, but no longer showed up in the list of passwords in settings.

Actual results:

The password that was generated contained only 4 characters, and there is no way to force a refresh to generate a better one.

The generated password was:
J8t#

Expected results:

The password is usually much longer, and this site's requirements were 12-64 characters. I have never seen such a short generated password before. Passwords this short are a security risk, and if I wasn't paying attention, I could have blindly clicked through with a very insecure, short password.

Ideally, it would be nice if there was some user control over re-generating a new password for cases like this, and even better if there were a configuration page or manual generation section in the password settings page.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Toolkit::Password Manager' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[albeec13]

Attachment: Clipboard_04-17-2024_02.png

Just to add some more detail, I closed the transunion tab and then attempted to start the password reset process all over again from a fresh tab, and I was given the exact same password yet again: J8t#

So, I proceeded to clear all storage for the site, from the Web Developer Tools -> storage page, then also opened up history and removed the transunion.com site from my history completely, and then closed and reloaded Firefox.

This time, going through the same process, I proceeded to the point where Firefox would generate a new password, and once again, it was only 4 characters long, but different this time, with the suggested password being: aL*2

Screenshot added to main bug.

Comment 3

[albeec13]

Since this appears to potentially be a site-related bug, this is the URL which starts the account/password reset process that leads to the page where this bug is happening: https://service.transunion.com/dss/loginHelp1_form.page?

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:serg, could you have a look please?

For more information, please visit BugBot documentation.

Comment 5

[Ina Popescu, Desktop QA]

I've managed to reproduce this issue in Firefox 129.0.2 using Windows10 x64.
However I didn't manage to complete the account creation process, but I've encountered same issue on the sign up form where password "@xW3" was generated in the Create Password and Confirm Password fields .
Setting to New.

Comment 6

[Daniel Veditz [:dveditz]]

On the way to creating an account one of the steps is https://membership.tui.transunion.com/tucm/orderStep1_form.page? where there's a 4-digit "last 4 of your SSN" field that Firefox thinks is a password field. Firefox offers to generate a password for it. If someone clicked the "Securely generate password" option right there it would be short, like this bug says. But I didn't do that. I typed 4 numbers. When I saved that form Firefox offered to save "1234" as the password for the site (which I declined).

The next page is where you can create a password. When I generate a password it's random, but only 4 characters long. The two password fields on this page are maxlength=15, so there's no reason to be limited by the length of a "password" field on a different page, especially since I didn't even save a password!

bug 1551723 is feature request to let people force the genertion of a new secure password, but that would only help if the password algorithm used the generation hints from the current form, not some previous page.