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
Confirming, couldn't find dupes. See also bug 16489.
Assignee: firefox → bryner
Status: UNCONFIRMED → NEW
Component: General → Password Manager
Ever confirmed: true
OS: Windows XP → All
QA Contact: general → davidpjames
Hardware: PC → All
Version: unspecified → Trunk
Mass edit: Changing QA to default QA Contact
QA Contact: davidpjames → password.manager
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.
Depends on: 285790
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.
Component: Password Manager → General
QA Contact: password.manager → general
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?!!
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?
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.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.