Open Bug 1198194 Opened 4 years ago Updated 2 years ago

Password logged to browsing history, location bar history, etc.

Categories

(Toolkit :: Places, defect, P2)

defect

Tracking

()

People

(Reporter: psychonaut, Unassigned)

References

Details

(Keywords: sec-want)

The specification for URIs (RFC 3986) provides for a username and password to be included as part of the authority component.  However, the specification is clear that this feature is deprecated and a security risk, and says that applications should not render the password in plaintext or store it in unencrypted form:

> Applications should not render as clear text any data
> after the first colon (":") character found within a userinfo
> subcomponent unless the data after the colon is the empty string
> (indicating no password).  Applications may choose to ignore or
> reject such data when it is received as part of a reference and
> should reject the storage of such data in unencrypted form.  The
> passing of authentication information in clear text has proven to be
> a security risk in almost every case where it has been used.

Despite this, when a user types such a URI into the location bar of a Mozilla browser, the browser saves the entire URI, including the password, into the location bar history and browsing history, and displays it as plaintext when the user accesses the location bar history and browsing history.  This makes it easy for an attacker to observe a user's passwords by shoulder-surfing or by momentary access to an unattended machine.

I did not test this, but I suspect that the password is also saved and displayed in plaintext when a user merely follows a link to such a URI.  I suspect that the password may also be saved and displayed in the download history.

I can reproduce this problem with SeaMonkey 2.33.1 and Firefox 40.0 on openSUSE 13.2 (x86-64).  Note that, unlike Bug 1197791, this problem is not limited to HTTPS URIs, since userinfo subcomponents can be used with many other protocols (HTTP, FTP, etc.).

To fix this problem, the browser could strip out the password before saving the URI to the browsing/location bar/download history.  Alternatively, the browser could save the password in encrypted form, and display the URI history to the user only when they use and provide the master password to the Software Security Device.  (But I am guessing that this would require some rather extensive integration of the browsing/location bar/download history with the Software Security Device.)
Component: Security → Places
Product: Core → Toolkit
Group: core-security
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: sec-want
See Also: → 385605
Priority: -- → P2
See Also: → 130327
You need to log in before you can comment on or make changes to this bug.