Firefox Security, in need of an overhaul?

With the rise of addons, Ubiquity, and general saved passwords in Firefox, is the Password Manager in need of an overhaul for the modern web?

If you save passwords in Firefox you may have noticed (if you ever venture into the depths of the password manager) that for some services you have multiple occurrences of the same login details, with slight variations on the access method. A could of examples:

For a hosting account you could have:

  • Control panel accessed through a specific port on the server
  • SSL access to the same control panel
  • Webmail for the account accessed on another port
  • SSL access to the same webmail

For a site like Delicious you could have logins for:

  • Additional entries for Extensions and Ubiquity commands (eg. my one) that use the API and store the password within the prefs (about:config) as well as with random names within the Password manager

Each one of those logins could have your 'old' password saved, so would show you the dreaded 'wrong username/password' message when you accept the auto-filled password, as they are not synchronised with each other.

The reason these are not synchronised is because the web was once a simpler place and saving passwords was just a time-saving thing with no real thought put into designing the user experience.

The massive Password Manager security hole!

Something that really surprised me, or rather, shocked me, was when I found out that the password manager is a free-for-all. The interaction between extensions and the password manager isn't actually managed or secured in any way. Meaning that any extension can access any password! or in deed ALL your passwords with one easy command (they can even clear them all with one command too).

As far as I'm aware this is the case even if you have a master pasword set... once you've entered your master password the extension has full access to your login details.

So what should be done?

Well, firstly, I stumbled into this while making my Ubiquity command and having contributed a patch to the Ubiquity project about naming conventions for passwords saved through Ubiquity. The comments started on the Trac ticket and continued on IRC (read the full transcript):

[23:42] fern: but, using the password manager is a security risk
[23:42] dsample: oh?
[23:42] dsample: how so?
[23:42] fern: any ff extension can just get all your password and email it to anyone
[23:42] dsample: at least if you have 'master password' enabled it all gets encrypted
[23:42] fern: and if you don't?
[23:43] dsample: hmmm, there's no protection from doing that?
[23:43] fern: well, im doing that right now. im getting my own delicious password from the password manager.
[23:43] dsample: well, if you don't use master password (I don't either) it saves it all in plain text, just like the prefs file
[23:43] fern: i could email it to you, for example
[23:43] dsample: hmmm
[23:44] fern: as i said before, password manager is a security risk.
[23:45] dsample: hmmm
[23:46] dsample: has anyone attempted to look at this in the past?
[23:46] fern: i.e. ?
[23:46] dsample: I noticed that the nsPasswordManager of whatever stuff said it hadn't been touched since 2001, is that true?
[23:46] Unfocused: i see being able to use retreivePassword('anyotherverb') as a GOOD thing - users shouldn't be asked to enter their login info more than once for the same service, if two commands use the same service
[23:46] fern: yes.
[23:47] fern: Unfocused: that's true.
[23:47] Unfocused: and actually, most cases the login info should be accosated with a service, rather than any specific commaqnd
[23:47] dsample: Unfocused: true, but then the 'verb' shouldn't be the verb, it should be the service
[23:47] dsample: and password manager should be saving 'service' passwords rather than site passwords
[23:47] fern: like, delicious or jaiku
[23:47] Unfocused: i have a draft blog post on this topic, actually - i should get around to finishing it
[23:48] fern: we can start that, but how?
[23:48] dsample: then it could use the same password for the http, https sites as well as any extension
[23:48] fern: that == save service passwords.
[23:49] dsample: do you think we could create a parallel to Password Manager, maybe a Service Acount Manager?
[23:49] fern: well, we can use the password manager infrastructure to do that.
[23:50] dsample: but let's face it, the UI sucks for that kind of use
[23:50] fern: yes
[23:50] fern: for sure
[23:50] dsample: at least if we were to do it properly
[23:50] fern: but we can use it for now..
[23:50] dsample: I don't think it would be hard to create an addon that replaced password manager with another database
[23:51] fern: ummm..
[23:51] fern: use a sqlite database with cryptographed passwords.
[23:51] dsample: we 'could' use it for now, but then how would be integrate for example the 'delicious' password so that it auto-filled for http as well as https for example?
[23:52] dsample: (at the moment they would be stored as 2 passwords)
[23:52] fern: two urls.
[23:52] Unfocused left the chat room. (Quit: )
[23:52] fern: but its ugly as hell
[23:53] dsample: so we'd need to make something to add every combination of a service's URL and save them all?
[23:53] fern: urgj
[23:53] dsample: exactly
[23:53] fern: that's really ugly.
[23:53] fern: imagine? ftp, http, https
[23:53] dsample: which is why I'm thinking it would actually be as easy, and MUCH nicer to the user if we just replaced the password manager properly
[23:54] fern: but that's not easy
[23:54] dsample: yeah, then extensions have to find the right one for their use, etc.
[23:54] dsample: not easy, but we should be thinking about the User
[23:54] fern: yes..
[23:54] dsample: if we stop thinking of the user then we're building IE
[23:59] dsample: but then saving your passwords anywhere has that same issue
[00:00] dsample: which is why we need a new password manager
[00:00] dsample: one with security built around it
[00:02] dsample: My opinion would be that the password manager should be an encrypted 'box' of it's own, and anything that wants to use it should have to authenticate. Maybe using OAuth
[00:03] dsample: So the extension's API Key would be used to work out if it's a genuine extension and to provide the user with details about it so they can make an informed decision
[00:03] fern: yes
[00:03] fern: like a security certificate
[00:04] dsample: yes, but the problem with security certificates is that they're not free
[00:04] fern: yes
[00:04] fern: but for us, a security certificate would be a "mozilla certificate"
[00:04] fern: or a community certificate.
[00:04] dsample: with something like the publishing process it could automatically check within the code for accesses to the password manager and make sure it's identifying itself properly
[00:18] dsample: hmmm, now I'm sketching I'm wondering... how would we define a 'service' without requiring every site developer to provide some sort of mapping to their different access-points
[00:19] fern: requiring some kind of metadata would be not good
[00:19] dsample: ie. how would we be sure that should actually use the same password as
[00:19] fern: yes..
[00:20] dsample: unless we require the addon developers to do that part of the work
[00:20] fern: umm.
[00:20] fern: how?
[00:20] dsample: or... would we need to create a new community site for linking and 'configuring' the 'service manager'?
[00:21] fern: that would not be ideal
[00:22] dsample: perhaps if it's flexible enough it could save passwords for sites while they're 'orphans' but when they are included in an established 'service' through the site then it changes from a site to a service and merges any of the passwords they had saved for any of the access-points into one unified account detail?
[00:22] fern: good point. really good.
[00:24] dsample: if it advances the browser into a more... dare I say it... web 2.0 way, then maybe it's worth it

So, in case you skipped reading above, basically the result was that the Password Manager really needs a redesign to make it store paaswords for services rather than sites.


Thursday 2 April 2009 14:17 | user icon Alex Leonard

If you don't have a Google+ account you can comment using the normal comment form below

About the author

Portrait of the author

On weekdays I'm a Technical Lead at, having previously been a Solution Architect at Nokia & Nokia Siemens Networks, creating creative software solutions for mobile operators around the world.

In my spare time I'm an avid new technology fan, and constantly strive to find innovative uses for the new gadgets I manage to get my hands on. Most recently I've been investigating Mobile Codes, RFID and Home automation (mainly Z-Wave). With a keen eye for usability I'm attempting to create some cost-effective, DIY technology solutions which would rival even high-end retail products. The software I develop is usually released as Open Source.

I have a Finnish geek partner, so have begun the difficult task of learning Finnish.

Add me to your circles on Google+

The blog
May 2020

Zap the link below with your qrcode enabled mobile to send this page to it
Mobile Code for this page
What's this?