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.
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.
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.
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)
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.
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.
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.
> 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.
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.
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)
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.
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.
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).
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.
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.
From the article, the password is salted at least:
"I eventually found the sftkdb_passwordToKey() function that converts a [website] password into an encryption key by means of applying SHA-1 hashing to a string consisting of a random salt and your actual master password."
Passwords with 128bit of entropy have always been and will for the foreseeable future be secure with any password hashing algorithm that is not completely broken (i.e. uses a cryptographic hash function and a seed). 28 random alphanumeric characters fulfill the requirement and are reasonably fast to type, e.g. m7wdgdorhvi3jerzyztc2u642at
> The problem is that each year definition of "strong password" changes
Luckily, you can change your password.
Also, you could say the same thing for the hashing algorithm. Every year you'd want to up your iteration count or even upgrade algos (e.g. use memory-hardness when scrypt was released).
It works both ways, but overestimating is never a bad idea: if someone hacks you now and cracks it in five years, some passwords may still be in use.
I don't think the definition of "strong password" has changed much in the last ten years. The hashing schemes for storing passwords have changed, sure, but I think having sixteen or more characters with numbers, capital letters and symbols has been recommended for years now.
I have not heard anyone argue for requiring >=10 characters (9 is the highest requirement I've ever seen). 12+ I've heard being said as "if you really want to do it properly" in security reports for clients, but we know that'll hardly ever be followed for anything other than high-security places like sysadmins at a bank. I've never heard anyone say 16+, let alone it being the standard recommendation for years.
Most (all?) places that discover that 9+ is not good enough for the most valuable credentials, move to 2FA instead.
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.
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.
You still definitely have to accept at least four words actuallyrandomlygenerated (this is important, else the scheme falls apart horribly). Accepting 6 random words is pretty secure IMHO.
Thank heaven these days we have the KeePassXC browser plugin, finally obviating even the temptation to rely on flimsy internal browser storage.
UI- and convenience-wise, this is as good as LastPass used to be - and perhaps still is; I dropped them the day they were sold to some nefarious LockMeIn-entity.
I don’t think it’s an unreasonable guess than most people who use a master password in Firefox do so to prevent family/friends sharing their PC from easily discovering their passwords.
I can’t imagine them being too concerned with brute force attacks.
It's interesting how little attention this issue received throughout nine years of time, especially when you see a 5-year gap between updates/comments on the bug thread.
Haha, it was just the attitude I'm seeing suggests that we're somehow at the behest of Mozilla engineers and we just have to wait, but that's one of the great benefits of open source, we really aren't.
And I haven't looked but I imagine changing the encryption algo isn't a huge task, I wasn't suggesting that a non-Mozilla worker implement something huge like zaarn's suggestion, which fwiw I think is awesome as I don't use FF built-in password manager and find it just gets in the way.
I looked into this a while back and remember about as much. I think it was also in the category of things that was harder to change with legacy addons than it is now.
That's nothing new. At least Thunderbird is full of annoying even 10 years old bugs. Some important, some just annoying. I bet there's many more hidden because of security.
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.