280662 - master password should (optionally) encrypt more data

Status: RESOLVED WONTFIX

(Firefox :: General, enhancement)

Description

[Ivan Ičin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050131 Firefox/1.0+ (MOOX M2)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050131 Firefox/1.0+ (MOOX M2)

Currently, master password encrypts only passwords stored on disk. Other private
data are not encrypted.

Probably, cookies are the most important to encrypt, as they contain similar
information to passwords - many sites allow you to auto log-in after you receive
cookie on first log-in.

Maybe encrypting history would be harder, but I guess that those that want more
privacy are ready to accept a bit worse performance, as a trade-off.

Reproducible: Always

Comment 1

[Nickolay_Ponomarev]

Confirming, couldn't find dupes. See also bug 16489.

Comment 2

[David P James]

Mass edit: Changing QA to default QA Contact

Comment 3

[Daniel Veditz [:dveditz]]

bug 285790 is a specific instance. Since each set of data would need its own implementation it's probably better to have this one depend on a bunch of child bugs.

Comment 4

[Justin Dolske [:Dolske]]

The Password Manager is just a consumer of the master password, which is really a thing in the NSS softtoken. Fixing this bug wouldn't involve changing password manager.

Comment 5

[Leon Sorokin]

i just stumbled upon (and vented) about this issue.

http://forums.mozillazine.org/viewtopic.php?f=38&t=2346443

is cookie encryption really that difficult to implement? what's the point of encrypting login credentials when you can open a browser that restores a session into numerous pre-authenticated websites.

clearing cookies on exit is a nuisance of the late-90s era.

the whole Master Password is a fallacy when it comes with a huge asterisk to take extra measures to secure the implementation's wide-open backdoors.

how has this bug persisted for almost 7 years?!!

Comment 6

[Leon Sorokin]

what are the chances of overhauling the encryption and implementing http://sqlcipher.net/ at some point, then give users a choice as to which DBs they want to encrypt?

Comment 7

[Justin Dolske [:Dolske]]

It's generally agreed among UX/Engineering/Product that we don't want to further develop the existing master password functionality, as it's a poor fit for current needs and our current direction in this area.