1759788 - Password captured after page script fills it with dummy values

Status: UNCONFIRMED

(Toolkit :: Password Manager: Site Compatibility, defect, P3)

Description

[o2k]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:98.0) Gecko/20100101 Firefox/98.0

Steps to reproduce:

When logging into sites that use CHAP authentication, Firefox doesn't correctly remember the password and gets either an empty string or a string of zeroes (one for each password character).

Step 1: Go to https://demo03.vinipad.net/
Step 2: Try to login using any username and password (it doesn't matter if you don't actually log into the site because you don't know the password)
Step 3: After clicking on the "Login" button, a popup will offer to remember the password.

Actual results:

If the password is stored with the "Save" button, that password will be a string of zeroes instead of the actual password entered into the field.

Expected results:

The password stored should have been the actual password, not a string of zeroes.

Chrome, on the other hand, does properly remember passwords on that same site.

Comment 1

[BugBot [:suhaib / :marco]]

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

[o2k]

What more info do you need?

Comment 3

[Sergey Galich [:serg]]

:o2k no more info needed, thank you!
I can reproduce this bug.

The site's script replaces every character in password with 0 in sendForm() function.

sendForm: function() // Prepara entrada del usuario y envía el formulario
	{
		var chs=document.getElementById('hdn_chs');
		var pwd=document.getElementById('txt_pwd');
		var pl=pwd.value.length,dummy='';
		chs.value=sha1(sha1(pwd.value)+chs.value);
		for (var i = 0; i < pl; i++) {dummy += '0';}
		pwd.value=dummy;

		document.getElementById('btn_login').style.cursor = 'progress';
		document.body.style.cursor = 'progress';

		document.getElementsByTagName('form').item(0).submit();
	}

By the time Firefox capture values, they are modified by site's script.

Comment 4

[Sergey Galich [:serg]]

Flagging for re-triage

Comment 5

[Tim Giles [:tgiles]]

:dimi, can you see what Chrome is doing here? I wonder what their heuristics are for a situation like this.

Comment 6

[o2k]

(In reply to Sergey Galich from comment #3)

The site's script replaces every character in password with 0 in sendForm() function.

sendForm: function() // Prepara entrada del usuario y envía el formulario
	{
		var chs=document.getElementById('hdn_chs');
		var pwd=document.getElementById('txt_pwd');
		var pl=pwd.value.length,dummy='';
		chs.value=sha1(sha1(pwd.value)+chs.value);
		for (var i = 0; i < pl; i++) {dummy += '0';}
		pwd.value=dummy;

		document.getElementById('btn_login').style.cursor = 'progress';
		document.body.style.cursor = 'progress';

		document.getElementsByTagName('form').item(0).submit();
	}

By the time Firefox capture values, they are modified by site's script.

The point of replacing the password with zeroes is to avoid sending a single-hashed password to the server, sending instead the combination of the hashed password plus the "challenge string" value, all hashed with sha1 a second time for better security, which is how CHAP authentication usually works.

Chrome somehow manages to capture the password value BEFORE the sendForm() function is executed, but that function is not executed from a "submit" type button input, but from just a "button" type button input with a JS click event, so I'm not quite sure how Chrome knows to store the unmodified password value even before a form submit action is requested.