Open Bug 1600397 Opened 4 years ago Updated 23 hours ago

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)

68 Branch
defect

Tracking

()

Webcompat Priority P1
Tracking Status
firefox-esr68 --- wontfix
firefox-esr78 --- wontfix
firefox71 --- wontfix
firefox72 --- wontfix
firefox73 --- wontfix
firefox74 --- wontfix
firefox77 --- wontfix
firefox78 --- wontfix
firefox79 --- wontfix
firefox98 --- wontfix
firefox99 --- wontfix
firefox100 --- wontfix

People

(Reporter: moz, Assigned: serg)

References

(Depends on 2 open bugs, Blocks 2 open bugs, Regression)

Details

(Keywords: regression, Whiteboard: [passwords:capture-UI])

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

  1. Visit a specific website
  2. Enter my login data (username + password) and log in
  3. When asked, confirm saving login data (you sometimes get asked twice. If you get, confirm twice.)
  4. Log out
  5. 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.

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Password Manager
Product: Firefox → Toolkit

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?

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(moz)
Keywords: regression
Priority: -- → P2
See Also: → 257781
Summary: Firefox updates and destroys password, gives error message "Message too long for RSA" → Firefox prompts twice to save a password: once with the password and once with the munged client-side hash/encrypted value

(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 preference signon.formlessCapture.enabled to false 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.

Flags: needinfo?(moz)

Thanks. This was caused by bug 1287202 then :(

Regressed by: 1287202

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.

Whiteboard: [passwords:capture-UI]
See Also: → 1583150

Lowering to P3 since we will implement a mitigation in bug 1560468.

Depends on: 1560468
Priority: P2 → P3
Blocks: 1641127
Attached video Amazon Case

Attaching recording for amazon.com

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)

Priority: P3 → P2

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?

Priority: P2 → P3
See Also: → 1560468

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!

Has Regression Range: --- → yes
Webcompat Priority: --- → P1

Do we know if there are any plans to work on this? It seems to be creating a compat issue with IMDB.

Flags: needinfo?(sfoster)

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).

Severity: normal → --
Flags: needinfo?(sfoster) → needinfo?(james)
Priority: P3 → --

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.

Flags: needinfo?(james)
Flags: needinfo?(sfoster)

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.

Flags: needinfo?(sfoster)
Severity: -- → S2
Priority: -- → P2
See Also: → 1757719

:sgalich given that this is Webcompat priority 1 and an S2, is there an update on getting this assigned?

Flags: needinfo?(sgalich)

Dianna, I'll try to reproduce/investigate next week and will report back here.

Assignee: nobody → sgalich
Flags: needinfo?(sgalich)

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.

Depends on: 1765381
See Also: → 1540727

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.

(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)

Flags: needinfo?(sgalich)

(same question for bug 1540727)

Depends on: 1771806

: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.

Flags: needinfo?(sgalich)
Depends on: 1783706
Blocks: 1885851
You need to log in before you can comment on or make changes to this bug.