Firefox Master Password System Has Been Poorly Secured for the Past 9 Years(bleepingcomputer.com)
bleepingcomputer.com
Firefox Master Password System Has Been Poorly Secured for the Past 9 Years
https://www.bleepingcomputer.com/news/security/firefox-master-password-system-has-been-poorly-secured-for-the-past-9-years/
73 comments
Since Firefox is open source, instead of just waiting for Mozilla engineers to get around to it, couldn't someone just open a pull request?
Sure. Could you just write a patch implementing the solution? I'll then open a pull request submitting your patch, to save you some work. ;-)
In practice, this only works if you provide the password manager that will be chosen once and for all.
zaarn's suggestion "providing an interface for password managers" is an interesting alternative.
In practice, this only works if you provide the password manager that will be chosen once and for all.
zaarn's suggestion "providing an interface for password managers" is an interesting alternative.
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.
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.
The same was true for GnuPG the last time I looked.
[deleted]
[deleted]
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.
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."
"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."
> 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? ;)
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? ;)
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.
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.
Most (all?) places that discover that 9+ is not good enough for the most valuable credentials, move to 2FA instead.
You can always use XKCD's password methodology ;)
https://xkcd.com/936/
https://xkcd.com/936/
You need to do it properly; the comic is misleading on its own.
https://www.eff.org/deeplinks/2016/07/new-wordlists-random-p...
https://www.eff.org/deeplinks/2016/07/new-wordlists-random-p...
See also: zxcvbn
https://lowe.github.io/tryzxcvbn/
https://lowe.github.io/tryzxcvbn/
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'.
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.
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.
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.
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.
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.
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.
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.
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)
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.
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.
It still makes the attack harder, I grant, but not that much harder.
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)
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.
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)
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)
Funny how the solution is always "a new system that's coming very soon"
Instead, they could just have added a for loop
Instead, they could just have added a for loop
Dixit the biggest blackmailer of the Internet (cf acceptable ads).
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.
I can’t imagine them being too concerned with brute force attacks.
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.
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.
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
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; $*"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.
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).
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)
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)
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
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.
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.
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... )
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
> 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.
A feature that users would be better off not using is a feature that should be removed, IMHO.
> 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.
There is also case of "someone stole your backup", which is also quote realistic, especially when using third-party storage services.
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.
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
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.
Safari for Windows was canceled many major versions ago.
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.
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).
I just _assumed_ that passwords stored in the browser would be vulnerable if someone got physical access to your computer. So never used that feature.
Huh, first time I've heard of Mozilla Lockbox ( https://www.bleepingcomputer.com/news/software/firefox-to-ge... / https://mozilla-lockbox.github.io/lockbox-extension/ ). That's great that they're working on a better alternative to the master password thing; the UI also needed some work (that annoying modal blocking the browser on every restart).
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.
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.