1600397 - Firefox prompts twice to save a password: once with the password and once with the munged client-side hash/encrypted value

Status: NEW

(Toolkit :: Password Manager, defect, P2)

Description

[Christian Stadelmann]

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.

Comment 1

[Christian Stadelmann]

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: [e-mail]
Password: abcdef

Comment 2

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

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

Comment 3

[Matthew N. [:MattN]]

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?

Comment 4

[Christian Stadelmann]

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

Comment 5

[Matthew N. [:MattN]]

Thanks. This was caused by bug 1287202 then :(

Comment 6

[Timea Cernea [:tbabos][inactive]]

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.

Comment 8

[Matthew N. [:MattN]]

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

Comment 9

[Timea Cernea [:tbabos][inactive]]

Attachment: Amazon Case

Attaching recording for amazon.com

Comment 10

[Daniel Bodea [:danibodea]]

Reproduced on Windows 7 with Nightly v79.0a1 from 2020-06-09.

Comment 11

[Virginia (please send need info request to Brindusa Tot)]

Reproducible on Windows 10 - Firefox Nightly 79.0a1 (2020-06-09) (32-bit)

Comment 12

[Virginia (please send need info request to Brindusa Tot)]

Reproducible on Ubuntu 18.04 LTS - Firefox Nightly 79.0a1 (2020-06-10) (64-bit)

Comment 15

[Sam Foster [:sfoster] (he/him)]

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

[Angel]

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!

Comment 17

[James Graham [:jgraham]]

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

Comment 18

[Sam Foster [:sfoster] (he/him)]

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

[James Graham [:jgraham]]

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.

Comment 20

[Sam Foster [:sfoster] (he/him)]

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.

Comment 21

[Dianna Smith [:diannaS]]

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

Comment 22

[Sergey Galich [:serg]]

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

Comment 23

[Sergey Galich [:serg]]

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.

Comment 24

[Alin Ilea, Desktop QA]

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

[Marco Castelluccio [:marco]]

(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

[Marco Castelluccio [:marco]]

(same question for bug 1540727)

Comment 27

[Sergey Galich [:serg]]

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