Closed Bug 212617 Opened 21 years ago Closed 18 years ago

Remember password does not work if javascript trigger modifies password onsubmit

Categories

(SeaMonkey :: Passwords & Permissions, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: iamsure, Assigned: mwu)

References

()

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030612
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030612

Mozilla should remember the password in forms as-of onsubmit, not post onsubmit:

To improve security for non-https connections, we have implemented a md5
javascript login feature. Upon submit of the form, the password entered is
changed to the md5sum of the password entered, and sent. 

Remember password then remembers the md5sum, not the value in the form as-of
onsubmit.

A different implementation, that takes the entered password, md5sum's it, and
puts it into a second variable, and then clears the password value has similar
problems - Mozilla remembers the cleared password value (the changed value
post-onsubmit).

The only alternative left is to leave the password in its original form, which
results in transmitting the password in cleartext.. a problem we were trying to
prevent.

Reproducible: Always

Steps to Reproduce:
1. Sign up for player account
2. Type in username and password (have it remember password)
3. Notice password gets converted to md5sum
4. Logout
5. Relogin

Actual Results:  
Password field is auto-filled with md5sum

Expected Results:  
Password field should be auto-filled with pre-onsubmit password.
Product: Browser → Seamonkey
Please note that this often-seen-on-the-web procedure is totally useless if your
goal is to prevent sniffing the password on the wire. Any bad guy would of
course sniff the md5sum and retransmit it in order to gain unauthorized access,
without the need of knowing the original password. Essentially, the md5sum *is*
the cleartext password. The only use of such procedure is to keep a server admin
from accidentally seeing a password that a client might also use for other purposes.

For more security, use at least HTTP digest authentication as described in RFC
2617. You might also consider basic auth over HTTPS.
No, this is wrong. A carefully-written JS would include a timestamp to prevent replay attacks.
HTTPS connections would require a certificate, which such scripts work around. (Self-signed certs are 
not trusted and issue a warning which would be bad in some situations.)
Just a thought, but this bug looks like a duplicate of bug #235765.
*** Bug 235765 has been marked as a duplicate of this bug. ***
Blocks: 235765
bug 235765 is not a dupe, Firefox has its own password manager implementation.
Assignee: dveditz → nobody
Depends on: 257781
Assignee: nobody → michael.wu
This bug should have been fixed by the non-passwordmanager specific changes in bug 257781. (at the same time, it has caused the regression in bug 343182)
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.