Firefox stores credentials in bad fields
Categories
(Toolkit :: Password Manager, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr91 | --- | wontfix |
firefox99 | --- | wontfix |
firefox100 | --- | wontfix |
firefox101 | --- | fix-optional |
firefox102 | --- | fix-optional |
People
(Reporter: alexvb6, Unassigned)
References
(Regression)
Details
(Keywords: regression)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:98.0) Gecko/20100101 Firefox/98.0
Steps to reproduce:
Create a simple html form with three fields :
<input type="email" name="email">
<input type="text" name="loginField123">
<input type="password" name="passwordField123">
- Leave "email" blank.
- Fill "loginField123"
- Fill "passwordField123"
For your records, when Firefox detects a form with several fields and a password field, it treats it as a login form, as explained here:
https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete
Actual results:
When you post this form (log in to your dummy website), Firefox :
- stores the value of "passwordField123" as the password => This is OK
- stores the value of "email" as the username => This is NOT OK !
I designed my form to have a HoneyPot field named "email", so it should not be populated.
Expected results:
When posting this form, Firefox :
- should store the value of "passwordField123" as the password
- should store the value of "loginField123" as the username
Using Firefox 98, and seeing that bug.
Was previously using Firefox 88, and the bug was NOT present.
So some code was broken in-between.
And it should be properly fixed.
Reporter | ||
Comment 1•4 years ago
|
||
Firefox seems to wrongly head to the "email" field instead of the "loginField123" field if at least one of these conditions are met :
- field have its "name" attribute set to "email"
- OR
- field have its "type" attribute set to "email"
When Firefox detects a login form, it should retain/record/store/save ONLY the populated fields, and NOT make the hazardeous and harmful assumption that "Oh, I bet that this "email" field is the one to consider!".
Comment 2•4 years ago
|
||
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 3•3 years ago
|
||
Set release status flags based on info from the regressing bug 1690865
Comment 4•3 years ago
|
||
:dimi, since you are the author of the regressor, bug 1690865, could you take a look?
For more information, please visit auto_nag documentation.
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 5•3 years ago
|
||
Set release status flags based on info from the regressing bug 1690865
Comment 6•3 years ago
|
||
(In reply to Alex Laforge from comment #1)
When Firefox detects a login form, it should retain/record/store/save ONLY the populated fields, and NOT make the hazardeous and harmful assumption that "Oh, I bet that this "email" field is the one to consider!".
Hi Alex, sorry for the late reply and thank you for your suggestion.
The reason that we are not only storing fields that are populated fields is because we need a consistent behavior between capture and autofill. In a lot of cases, the username field is not just the previous field before the password field, so we need to add heuristics to infer which field is most likely the right username feidl so we can autofill it correctly. The same heuristic also apples when capturing username/password. And yes, our heuristic isn't perfect at this point, sometimes we choose the wrong field.
The best solution for this problem is using autocomplete attribute so browsers don't have to guess which field is the username field. For example, If you add
<input type="text" name="loginField123" autocomplete="username">
then we know which <input> is the username field.
Do you think adding the "autocomplete" attribute makes sense to you?
Updated•3 years ago
|
Comment 7•3 years ago
|
||
The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.
Comment 8•3 years ago
|
||
Please use suggestion from Comment 6 to set autocomplete="username"
.
Updated•3 years ago
|
Reporter | ||
Comment 9•3 years ago
|
||
(In reply to Sergey Galich from comment #8)
Please use suggestion from Comment 6 to set
autocomplete="username"
.
Unfortunately, since the same domain can host many different "login forms", the autocomplete suggestion is not the way to go.
Before opening this ticket :
- My "email" (honeypot) field is already specifying
autocomplete="off"
! - My "loginField123" field is already specifying
autocomplete="username"
!
So the heuristics IGNORES these flags.
That is the real core problem.
Comment 10•3 years ago
|
||
Hi Alex, thank you for the response.
I just tried a form with the following markup, Firefox can identify the correct username field
<form>
<input type="email" name="email">
<input type="text" name="loginField123" autocomplete="username">
<input type="password" name="passwordField123">
<input type="submit" value="Submit">
</form>
Could you help paste the markup of the form (with the suggestion in Comment 6) so I can take a look what the problem is? Thanks!
Reporter | ||
Comment 11•3 years ago
|
||
Your fresh test seems to make Firefox behave correctly. But only because you are using a "virgin" test from, on a domain for which Firefox had never stored any credentials in the past.
However, If your domain had other login forms, and retained the email as the login information in the past, then you'll have Firefox fill the loginField123 for this new login form with the email originating from the other previous login form.
Description
•