Firefox Master Password System Has Been Poorly Secured for the Past 9 Years | Hacker News Reader

Firefox Master Password System Has Been Poorly Secured for the Past 9 Years

bleepingcomputer.com

101 pointsekianjo71 comments

Master passwords have a very narrow threat model that they are actually protecting against: it's protecting against people who have access to the password database (i.e., filesystem access) but not people who have access to ptrace-privileges (i.e., the ability to read the password directly out of process memory). Which pretty much means the only realistic use case is someone stole your laptop, but full-disk encryption is a much more relevant solution.

Mozilla has known for a very long time that the master password system isn't very effective. Even a decade ago, I remember them recommending not using it.

Can I clarify the distinction between the two capabilities? Are you saying that if I download and execute e.g. “fake-meme-creator” which turns out to be malware for whatever reason, then it can read the filesystem as any normal process can, but it cannot access ptrace?

If this is the case, I’d consider it to be useful because in general I don’t trust apps as a rule.

The way most systems are configured, your fake-meme-creator could access ptrace and the filesystem.

What is "most systems"? A few years ago this was true.

A decent distribution nowadays sets /proc/sys/kernel/yama/ptrace_scope to disallow any process to spy on other processes.

ptrace_scope was apparently introduced in 2011-2012, see https://github.com/torvalds/linux/commits/a2e5790d841658485d...

For more information:

https://www.kernel.org/doc/Documentation/security/Yama.txt

https://en.wikipedia.org/wiki/Ptrace

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... (via https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening... )

Yeah but anyone developing will likely turn that off as it interferes with attaching gdb/strace/etc

That's why my passwords in text file and I consider it fine. If someone breaks into my machine and I won't notice it, password will be keylogged anyway. The only true defense would be hardware-protected external password storage, but I'm not aware of any.

Yubikey

Are you sure it can store passwords and decrypt them with required touch? What's its memory?

You can use a YubiKey for a portion of a master password. This is best used by manually typing "correct" and autocompleting the latter portion with plenty of entryop of the password/phrase "battery horse staple" from the key. This way, if someone steals the key, you've still got a secret.

You'll still need a password manager to store the unique passwords for your services.

https://www.yubico.com/support/knowledge-base/categories/art...

https://www.yubico.com/wp-content/uploads/2015/11/Yubico_Whi...

EDIT: Explanation

I think that advanced malware can intercept this master password and decrypt all data. I had in thought some hardware, which stores all passwords, reveals only metadata and to actually retrieve a single password, you have to physically interact with device (tap it, for example). In this case even if malware has full control over your PC, it can't retrieve all passwords, only those you've actually used.

People looking over your shoulders, you sending a screenshot where you forgot the open file in the background.

I agree a text file is 'secure' enough for you but a lot of password systems also hide the password in the UI which is a pro inho (I use KeePass).

How often do you send screenshots on the internet without looking at them before you send? I mean, I know if I screenshot a browser for example some nerd will comment on all my bookmarks other tabs etc (because if it's someone else posting the screenshot the nerd is me).

A file in a place not immediately obvious to a casual browser without obvious references to what it is seems broadly fine to me. (I don't bother, Instead just re-use passwords because I'm a horrible person)

> Which pretty much means the only realistic use case is someone stole your laptop

There is also case of "someone stole your backup", which is also quote realistic, especially when using third-party storage services.

The “narrow threat model” actually applies to a very common social scenario where people share computers. For instance a family member might want to play Steam games, or print, or simply browse the web. Most people are not going to create a guest account for that. There passwords are then at risk if not adequately protected.

Even in work contexts, “hey can I use your computer to print something? Mine is frozen” is very common.

There was a similar discussion on the chromium tracker when they started storing passwords. I believe Chrome now use OS services (DPAPI on Windows and Keychain on MacOS) to protect passwords.

workstation access + admin user[1] = game over from a security point of view.

at that point they can install a rootkit and bypass all your fancy DPAPI/keychain protections.

[1] before you say "but I got password on my sudo!", there's nothing preventing someone from aliasing sudo to

    sudo bash -c "/tmp/evil.sh; $*"

> Mozilla has known for a very long time that the master password system isn't very effective. Even a decade ago, I remember them recommending not using it.

A feature that users would be better off not using is a feature that should be removed, IMHO.

While I would generally agree that the master password in Firefox is rather... non-ideal, to use a friendly term, I think the article is blowing it a bit.

Most users that I know use the master password system in combination with a very long master password. That should protect against some brute-forcing but everyone should at best not use the master password at all.

I think Mozilla might be better off by removing the internal password manager entirely and instead providing an interface for password managers (and ship a simple one with firefox that doesn't have a password protection, users can then pick a proper password manager on their own)

Don't most users just stick with the default though? The shipped password manager going from one with a master password to one without would just mean most users have less security.

Most users don't use the master password at all so most users will have the same security.

Users with master password will have to be informed they need to find a new solution.

I'm not sure I see the point here, what is the threat model? I guess it does not include laptop protected by full disk encryption?

The threatmodel of the masterpassword is usually a variation of "attacker on your local system".

...who can keylog your master password?

It still makes the attack harder, I grant, but not that much harder.

A keylogger on your system could keylog your master password.

A password manager itself has a similar threatmodel but it holds (usually) more valuable information than just passwords (in my case TOTP, Bank Data, Credit Card, etc.)

PM's are also usually better equipped to deal with this (Keepass uses a Secure Desktop on Windows)

Firefox's master password is "good enough", so to speak. It's unlikely someone will attack you either way but if someone does then FF's system should hold out a day or two if you picked a reasonable password (a modern PM can put up much better brute force defence)

Good point. Nowadays, keylogging the master password is AFAIK easier for an attacker than tracing processes. This is still current: https://blog.invisiblethings.org/2011/04/23/linux-security-c...

I wish Linux would implement a modern Secure Attention Mode (it has one but that kills all processes).

It could be as simple as having a syscall that connects a process directly with the keyboard and does not let any other process intercept any keyboard input until the program lets go or times out (180s, after that the program isn't allowed to get SAM anymore for another 180s)

I feel that kernel-level handling would get messy. Just to name one thing that comes to mind: how would you handle multi-seat systems? Oh, or accessibility; say, there is no physical keyboard, just a touchscreen and onscsreen keyboard that you've just blocked from displaying. Yes, you could handle it, but by the time you've hit a few of these the code will be... inelegant.

I've actually thought about this for a bit and it's not as complicated.

If a physical keyboard is present, the program is assigned to the keyboard of the current user's seat (works with sudo since that only sets effective UID/GID not real UID/GID)

Additionally, a program with root privileges (or a special CAP) can register itself as a HID in which case the SAM captures any HID's + keyboards of the current seat.

Any complex setup would therefore be pushed out of the kernel but still provide reasonable security. An additional edgecase can be seen in debuggers which can be reasonably circumvented by having the SAM mode provide a few pages of memory that aren't mapped into any memory but the current process so a debugger can't read the password.

A software keylogger would require strict root privileges to circumvent this system.

Well to be fair, no other major browser even has a master password feature. I think the master password is good to stop "causal" hacking - by friends, family and/or un-tech savvy thieves.

Only the world's most popular browser also has it. https://www.ghacks.net/2013/12/04/google-chrome-gets-master-...

Sort of...

The difference being that I can still "use" the passwords without this prompt (FF does not allow this) and I'm still able to view the entire PW database, which will show me usernames (but not passwords).

So, in fairness, Chrome has "sort of" implemented this feature (albeit in a laughable insecure way) and quite obviously have left it to rot (2013?!) on the digital vine.

Safari does, by way of the OS Keychain.

Must be a feature of MacOS - I don't see it within Safari for Win

Safari for Windows was canceled many major versions ago.

Please stop using Safari on Windows. There has not been a single update to Safari for Windows since 2012.

Ha - I don't "use" Safari, just have it installed on my PC for those random times I try (and fail) to replicate a client's website issue. I should probably uninstall, and use an emulator.

Yeah, in addition to potential security problems, I have to imagine that an old Safari for Windows is not a particularly faithful reproduction of the behavior of modern Safari anymore.

Well if you dont use a master password, the passwords are available with the Show passwords button. Firefox's saved passwords feature is not meant to protect against theft etc. (This is actually annoying to me, but I cant really flaw the model; people want what they want and the browser needs to provide it).

This code is actually part of NSS, I wonder whether this affects other applications using the soft token db in a similar capacity.

https://dxr.mozilla.org/mozilla-central/source/security/nss/...

It also processes salt||pw; while that's not a problem per se for password hashing, I generally prefer unique encodings when hashing multiple fields, such as len(salt)||salt||len(pw)||pw.

If there are only two fields, and the length of one is fixed (the salt) then the encoding is unique.

SHA1 (and other cryptographic hash functions) generally already include the length as something that is part of the hash itself, so your “length encoding” is completely redundant in the case of hashing salt|password.

Not sure, but I seem to remember that NSS is also used by Chrome.

Not any more: they went to their own fork of OpenSSL called BoringSSL.

Funny how the solution is always "a new system that's coming very soon"

Instead, they could just have added a for loop

This sounded like clickbait when reading the first bit (SHA1+iterations isn't that bad, as the SHA1 vuln doesn't affect password hashing), but it turns out the number of iterations is 1. That's not SHA1 "with a low iteration count", that's just plain SHA1. And no salt it seems.

Pretty bad indeed, but then again: this is a master password you're setting. The one password to rule them all ought to be strong anyway. If you do that, it's perfectly safe.

> The one password to rule them all ought to be pretty strong anyway.

The problem is that each year definition of "strong password" changes, because of growing performance of CPUs and GPUs.

"Use a password manager" is always a good solution, I know. But well, who will remember the super lengthy password for the password manager? ;)

You can always use XKCD's password methodology ;)

https://xkcd.com/936/

Not really.... https://boingboing.net/2014/02/25/choosing-a-secure-password...

I really, strongly, disagree with the core argument of this post.

His "solution" is to use shorter passwords. The XKCD method is good if you add separators, padding, etc; as expressed featured on xkpasswd.net

I highly recommend generating a password and then adding something unique to it.

For instance, a password I might generate would be:

$66=mine=BODY=spot=STOP=23$-d1j1t

It's memorable enough, and I highly doubt it's easily crackable. Certainly no less than 'tlpw2m'.

Even just //44$random$WORDS$11// is effectively just as safe, in the real world. Especially if you use gibberish words that aren't in any commonly used dictionary.

That blog post does not give any convincing argument against XKCD-style passwords. It seems to incorrectly assume they are "security by obscurity".

Honestly, I had a good laugh until I saw who wrote that. To be fair, I think Bruce is saying that most people will fail to pick truly random words, which is fair.

However, as you point out, it provides no argument against passphrases, aside from referring to them as a "trick". I still don't know how people look at the XKCD explanation (where Randall Munroe actually does a pretty good job of correctly and succinctly detailing the strength of the two password styles [1]), and call it a trick. The only trick is that your mind has an easier time remembering passphrases than it does remembering a similar strength random string.

[1] Specifically, Randall already assumes that the cracker knows that the password is a passphrase, and has the 1000-word list it was picked from.

Those pushed into FUD against XKCD password scheme can simply add more words. All arguments in https://www.explainxkcd.com/wiki/index.php/936:_Password_Str... remain, including the ease of remembering.

You still definitely have to accept at least four words actually randomly generated (this is important, else the scheme falls apart horribly). Accepting 6 random words is pretty secure IMHO.