Closed Bug 1608835 Opened 6 years ago Closed 5 years ago

Decide if Firefox + Thunderbird should continue to offer the master password feature

Categories

(Core :: Security: PSM, task)

Product:
Core
Component:
Security: PSM
Type:
task
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: KaiE, Unassigned)

References

Details

(Whiteboard: [passwords:master-password] )

I'd like to reach a decision if we still consider the Master Password feature relevant.

Because Firefox and Thunderbird share much of the underlying code, it would be ideal if we could reach a consensus whether both apps still want support it, or if it should be dropped by both.

The intention of the MP is to protect access to the user's saved logins, and to the user's private keys (used for SSL/TLS client authentication or for email encryption).

Arguments for dropping the MP:

  • the protection it provides is incomplete. It could be argued that an attacker, who is able to steal files from the victim's computer, is also able to install software on the victim's computer, too. By installing a key logger, the master password can be obtained by the attacker.
  • full disk encryption and OS user login and screen lock are stronger mechanisms to protect the user's files, while the computer isn't in use
  • availability of full disk encryption features, or user home directory encryption, in operating systems is widely available, compared to the time when the MP feature had been introduced
  • the MP feature currently isn't very user friendly, and we've never had gotten much resources to improve it. For example, when bringing up the prompt, we don't say why. The user interface is very simple, and consequently, it might be easy to use a JS prompt to trick the user into entering the MP.
  • especially in Thunderbird, users who enable the MP are annoyed, because it's not implemented in a good way. Having multiple protocols enabled that each require a saved login at application startup, we bring up multiple password prompts in parallel, which the user has to fill in one after the other. In order to fix that, we'd have to change the login manager APIs to be async, reject parallel access with a kind of "would block", and refactor all code in TB to use the new async APIs (retry later if the password cannot be obtained/stored immediately)

Arguments for keeping the MP:

  • For users who cannot use full disk encryption on the computer they're using (e.g. a shared computer), maybe the MP feature is "better than nothing"
  • it might be much easier to steal files from the user's computer, as copying a file might require less privileges than installing software
  • installing a key logger to get the master password requires a more sophisticated attacker and a higher amount of criminal energy, so using a MP at least gives protection against drive by attacks
  • it also protects logins/key saved in unprotected backups of the user's home directory, which might be on portable drives or in cloud storage

Are there other arguments for one or the other side?

How could we reach a decision on this topic?

The first argument against the MP "It could be argued that an attacker, who is able to steal files from the victim's computer, is also able to install software on the victim's computer, too" is void. Sure, an attacker with access to a running system can steal files install keyloggers. The same can happen with full disk encryption. If the user walks away from an unlocked machine, the attacker can open files which are automatically decrypted by the system. They can also run processes as the encrypting user and "phone home" decrypted information. Once a system is compromised, there is no protection, neither from a MP nor from full disk encryption.

MP and full disk encryption are in principle the same with two differences. For MP the "crypto store" is far smaller, only the password database. And the software doing the encryption is different.

Here some arguments against full disk encryption by the OS:

  1. At least for Windows, it's NOT available on all flavours. Last I looked, the was no Bitlocker for W10 Home.
  2. It's integrated to the OS. And Windows isn't open source. Also, there are people using dual boot, Windows+Linux and I doubt that they will be able to use Windows' encryption.
  3. It's not portable between Windows systems: Windows files are encrypted for one user on a particular machine using the user's security ID (SID) which is something like S-1-5-21-1175651296-1316133944-203321314-1005. If you create two users Kai on two different Windows machines you get two different SID's . If you now copy a file via an USB medium from one machine to the other, you can't read it on to new machine unless you copy it to the USB medium decrypted, but hey, then the protection is gone. Note: I haven't greatly experimented with this, but I know that encrypted files copied onto a USB medium can generally NOT be opened on a different machine from the USB or when copied onto the new machine. A solution would be to create users on all machines with the same SID, but that it tricky stuff. I use three machines (2 offices, 1 laptop) and synchronise via a USB disk.
  4. In the olden days, there were people repairing broken magnetic drives. I think they would have had a bad time repairing a disk where the content wasn't only damaged, but also encrypted.

I pretty much agree with Jorg. I think it's safe to assume that the average user is NOT using full disk encryption. It takes special effort to set up, even if you have Win10 Pro, which costs extra. Even on Mac, I would be surprised if the majority of users know what FileVault is, how to turn it on, and what it does.

I shouldn't contradict, but just for the record: Dell ships laptops with W10 Pro with the disk already encrypted.

There's a bit of mixing apples and oranges here: full disk encryption is one thing, but simply using the OS user login to protect your data will go along way to protect against casual access. An attacker with physical access will eventually get in, but that's not casual.

"OS user login" - what's that? The credentials you use to log on as a user? And if you block the screen when you walk away or get the screen saver to do it? Well, if you "casually" lose your machine, without any encryption, people can just read out the hard drive without even starting the machine.

What is the apple and what is the orange?

That, AFAIK, the master password was designed only to protect against very casual access, basically the case where you (back in the day) only really had one OS login, and multiple profiles of the application - then one other family member wouldn't be able to instantly access your passwords without hacker skills. We're talking about a design from late 1990s or early 2000 when people actually shared computers and logins like this more. And PCs didn't carry around, so you would not "lose your machine".

Btw. this bug is a dupe of bug 1223185 but I've duped that here since it has more current context though bug 1223185 has some ideas that are still useful.

Whiteboard: [passwords:master-password]

It's not portable between Windows systems

From what I've seen of other discussions on this topic, "portability of the bytes on disk" needs to be called out as either an explicit goal, or an explicit non-goal. And it's easy for reasonable people to disagree on which it should be.

Well, for people synchronising installations by copying profiles, it's surely a goal. There's not so much need for synchronisation in Firefox, but there is in Thunderbird.

The master password was to protect the database from compromise if the database is handed out to someone else. (The database is grabbed from a backup, the database is stored on a shared filesystem, etc). None of these situations have anything to do with keyloggers, or other such attacks.

From an NSS perspective, we definitely still need it. Under the covers, the master password is nothing more than the PKCS #11 password for the database slot on NSS's softoken. The need for that password is not going away in other NSS usages. From a firefox/thunderbird perspective: you could 'get rid of it' by not enabling it any more, or providing UI to manage it 'as the master password', but you still have to keep all the mechanisms within your application to handle async password prompts from NSS because 1) other PKCS #11 module (aka smart cards) can and will require password login, and 2)

My feeling is you should still keep it. It's still useful, and it's very difficult to remove without creating pain for those who have set a master password. I think it's perfectly fine to decide that a normal installation wouldn't set it, and to hide the UI for doing it a bit more (falling back to just managing it from the token manager UI), but removing it all together would be quite the production to do right.

You could stop using SDR to manage passwords, though I'll give my anecdotal reason why I wouldn't want that: My wife used to not save her login/passwords in Firefox because she didn't want to worry if a house guest was around that they could get into our bank account from firefox (she doesn't have a password on her windows login). Once she was assured that setting a master password meant that people couldn't access those passwords as long as she shutdown firefox every time (which is a lower cost to her than logging out of windows), she actually started using the feature. Just my 2cents on one other user that would be annoyed at losing master passwords.

bob

Bugzilla's not a great place to have a discussion like this (and in any case the discussion seems to have dissipated here).

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.