Firefox prompts twice to save a password: once with the password and once with the munged client-side hash/encrypted value
Categories
(Toolkit :: Password Manager, defect, P2)
Tracking
()
Webcompat Priority | P1 |
People
(Reporter: moz, Assigned: serg)
References
(Depends on 2 open bugs, Blocks 1 open bug, Regression)
Details
(Keywords: regression, Whiteboard: [passwords:capture-UI])
Attachments
(1 file)
808.40 KB,
video/mp4
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Steps to reproduce:
- Visit a specific website
- Enter my login data (username + password) and log in
- When asked, confirm saving login data (you sometimes get asked twice. If you get, confirm twice.)
- Log out
- Log in again using the stored username/password
Actual results:
At 2., login works fine.
At 3., it saves an incorrect password. If you open the password manager (chrome://passwordmgr/content/passwordManager.xul) and show the password for this site, it shows something very long beginning with "rsa:BzP/" and it has 349 chars.
At 5. I get an error message dialog "Message too long for RSA" and cannot login.
If you look into
Expected results:
At 3., save password without breaking it.
At 5., log in just fine.
Additional info:
I have some experience in software development and debugging. If you tell me what to do, I may be able to help debugging.
Reporter | ||
Comment 1•4 years ago
|
||
It seems like other websites are affected too. There is a report on this site: https://www.romantica.chat/faq/bekannte-probleme/firefox-passworthandling/
You can reproduce this issue on that website by trying to log in with these credentials:
E-Mail-Address: name@example.com
Password: abcdef
Comment 2•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Comment 3•4 years ago
|
||
Thank you for the report. I believe this is a regression from the formless capture
(In reply to Christian Stadelmann from comment #0)
When asked, confirm saving login data (you sometimes get asked twice. If you get, confirm twice.)
I believe the double-prompt is the problem… the first prompt would have the correct password but it gets replaced by the 2nd one. I think we would need to address this with a UI like Chrome has recently added with a dropdown for the password: https://cl.ly/b687986d0924
…
At 3., it saves an incorrect password. If you open the password manager (chrome://passwordmgr/content/passwordManager.xul) and show the password for this site, it shows something very long beginning with "rsa:BzP/" and it has 349 chars.
The site is using a library to do client-side encryption (see handleFormSubmitRequest
from https://www.romantica.chat/typo3/sysext/rsaauth/Resources/Public/JavaScript/RsaEncryptionWithLib.min.js?1505826096).
That library should submit the required value with an <input type=hidden>
or through JS, not modify the field's value.
Can you confirm that setting the about:config preference signon.formlessCapture.enabled
to false
fixes the issue?
Reporter | ||
Comment 4•4 years ago
|
||
(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #3)
Thank you for the report. I believe this is a regression from the formless capture
(In reply to Christian Stadelmann from comment #0)
When asked, confirm saving login data (you sometimes get asked twice. If you get, confirm twice.)
I believe the double-prompt is the problem…
You are right, if I look closely I always get a double-prompt for saving the password, sometimes in a way that I first see the normal (correct) prompt with a short passphrase and then a few (milli-)seconds later the prompt gets updated with the way-too-long password.
[…]
Can you confirm that setting the about:config preferencesignon.formlessCapture.enabled
tofalse
fixes the issue?
Only if I restart firefox after setting that preference. In this case yes, it fixes the issue for me on two sites tested.
Comment 6•4 years ago
|
||
Reproduced on affected Nightly 73, Beta 72 and Release 71, marking flags accordingly.
As a note, if you check the password in the Save door-hanger, for the first 2 seconds you can see the masked "abcdef" and then it instantly gets replaced by the RSA version of it.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 8•4 years ago
|
||
Lowering to P3 since we will implement a mitigation in bug 1560468.
Comment 9•3 years ago
|
||
Attaching recording for amazon.com
Comment 10•3 years ago
|
||
Reproduced on Windows 7 with Nightly v79.0a1 from 2020-06-09.
Reproducible on Windows 10 - Firefox Nightly 79.0a1 (2020-06-09) (32-bit)
Reproducible on Ubuntu 18.04 LTS - Firefox Nightly 79.0a1 (2020-06-10) (64-bit)
Updated•3 years ago
|
Updated•3 years ago
|
Comment 15•3 years ago
|
||
I think the solution to bug 1560468 is what will resolve this - the user will be able to pick the other password value. So maybe this will end up being a dupe?
Comment 16•3 years ago
|
||
This bug was reported long ago and was not fixed. When using sites affected by this bug I had to switch to Chrome to avoid the issue. A fix would be most welcome!
Updated•2 years ago
|
![]() |
||
Updated•2 years ago
|
Comment 17•2 years ago
|
||
Do we know if there are any plans to work on this? It seems to be creating a compat issue with IMDB.
Comment 18•2 years ago
|
||
I'll flag it for re-triage it. :jgraham, as the original report was a few years ago, can you confirm the steps from the original description in comment #0 are accurate (excepting the password manager references which are now replaced by about:logins).
Comment 19•2 years ago
•
|
||
The webcompat report https://webcompat.com/issues/99277 is from a few weeks ago, and was reproduced by Raul from Softvision, so I'm pretty sure the steps there are still valid.
Updated•2 years ago
|
Comment 20•2 years ago
|
||
Ok, from the webcompat report this can be reproduced at https://www.imdb.com/.
If you have other sites where this happens (the bug description just says "specific websites" but we know this doesn't happen on most) please add them here.
Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 21•2 years ago
|
||
:sgalich given that this is Webcompat priority 1 and an S2, is there an update on getting this assigned?
Assignee | ||
Comment 22•2 years ago
|
||
Dianna, I'll try to reproduce/investigate next week and will report back here.
Assignee | ||
Comment 23•2 years ago
|
||
I can reproduce on imdb.com.
Page script modifies password field and we show save prompt twice, first with correct password and then with "encrypted" version.
Any value in signon.formlessCapture.enabled
does not seem to affect this behavior.
Bug 1560468 would only partially help, we can not expect user to be that attentive.
The problem seems to be that we react to submit event twice and to page navigation twice. Normally it would be ignored because values are not changing, but in this case script modifies value and input field name, tricking us into saving encrypted password.
Updated•1 year ago
|
Comment 24•1 year ago
•
|
||
Hi,
I have managed to reproduce the issue in release 100, but I cannot reproduce the issue anymore in the latest Nightly build 102.0a1 (2022-05-11). Tested using Windows 10, on imdb.com. Just let me know if any other details are needed here.
Comment 25•1 year ago
|
||
(In reply to Alin Ilea from comment #24)
Hi,
I have managed to reproduce the issue in release 100, but I cannot reproduce the issue anymore in the latest Nightly build 102.0a1 (2022-05-11). Tested using Windows 10, on imdb.com. Just let me know if any other details are needed here.
Sergey, are you still able to reproduce or is this fixed? Is bug 1757719 also fixed? (asking because they're both S2)
Comment 26•1 year ago
|
||
(same question for bug 1540727)
Assignee | ||
Comment 27•1 year ago
|
||
:marco, it's fixed by bug 1765381 for most usual case when user enters an email as username.
However, we've found that when user enters something that does not look like email, a different path is executed and we end up showing wrong password again. Bug 1771806 is expected to fix that and this is why we keep this one open for now, so we can come back and verify.
Description
•