Master password in Firefox or Thunderbird? Do not bother
palant.de
palant.de
There are ~100,000 people in the world that would think to run a GPU password cracker on your Firefox master password hash, if they had access and wanted to snoop.
There are ~1,000,000,000 people that would think to open your browser and go to a website you use to try to gain access to it.
In some sense, although it's hard to quantify security, using a master password is 10,000x more effective than not.
Only wish these password management functionalities (not tool itself, but whole mess switching back and forth between target app/password manager) are more pleasing than the way it is now on mobile...
Also this is the first I've heard that iCloud keychain sync only syncs keychain items created from App Store applications, and color me quite skeptical on that. Apple previously restricted the iCloud file and Key-Value Store functionality to App Store apps, but for keychain syncing it's just a single flag given to the item when creating it. Also I just checked the documentation for kSecAttrSynchronizable and there's no mention whatsoever of it being restricted to App Store apps.
The iCloud issue is discussed towards the bottom and references the Chrome ticket to remove support:
https://bugs.chromium.org/p/chromium/issues/detail?id=466638
It sounds like the real problem here is the fact that iCloud keychain doesn't have an access control list so apps can only access items within their same App Group, which means Firefox can't see Safari passwords and, if Firefox switches to iCloud keychain, no other browser can read passwords from Firefox. Though honestly this doesn't sound like a big deal to me (especially since the "Firefox can't see Safari passwords" is already the situation).
The Chrome bug does claim that Mac apps could not use the keychain access groups entitlement without being in the App Store but I can't find any hint of that being true today. I believe Apple relaxed the iCloud restrictions at some point so it's possible that this used to be true and isn't anymore.
It would actually be a lot easier to gather passwords if all applications used the OS store.
If anything, the new iMac pro has a Secure Enclave, which means we can soon expect in some number of years that most computers will as well.
Do you know that windows has had password stores for many decades?
I don't know about Macs but PCs have a Smart-Card like Chip called TPM build in for about 20 years by now.
One of the main functions a TPM offers is the secure storage of encryption keys.
I wonder such a feature comes only now to Macs with about two decades of a delay?
There is no absolutely no need for your password to be this long. Even just twenty characters is within spitting distance of 2^128.
No it's not. User-chosen data is rarely random, so it's safe to say that Santosh83's password is not random. This article claims English has 1.46 bits of entropy per character[1]. If Santosh83's password is regular English, then it would have ~105 bits of entropy.
>Even just twenty characters is within spitting distance of 2^128
Someone[2] sent bitcoins to a brainwallet secured only by the phrase "it was the best of times" (24 characters). The bitcoins were stolen in 4 seconds. 20 characters is not enough. You need to do actual entropy analysis. And don't use quotes from anywhere. Crackers crawl the internet and build databases of all the quotes they find online. This tends to include book quotes, movie quotes, etc.
[1] https://www.gwern.net/docs/statistics/1996-teahan.pdf
[2] https://www.reddit.com/r/Bitcoin/comments/1ndsxi/a_test_of_b...
Sure, perhaps it's just a phrase or something, but once you start calling part of a post a lie where do you stop? I'd rather not get into such a mess.
Yes, "from the full set" likely means that it's higher than 1.46 bits/character. But it doesn't mean it's much more.
The average password isn’t random. But GP was not describing anything remotely close to an average password in the first place.
Turns out (according to GP) it isn’t random. But I stand by my point that it was a reasonable assumption given the available data.
KeePass reports it as having 222 bits entropy although I don't know how accurate an analysis that is.
The way current browsers operate, makes it really inconvenient to use a master password, because each time you visit a page for which a password is stored, it will prompt you to enter a master password. This way you can't have a feature where master password is forgotten after for example 10 minutes of not using it.
Such behavior makes one either to not use master password at all, or enter it and be in memory for the entire time a browser is running.
Also pressing Command+Enter or Ctrl+Enter log in to a website was so much faster and convenient than the current way.
[1] Note I'm talking about actual Opera browser which sadly no longer exists, the current Opera browser is just a Chrome with a different skin.
I guess the moral of both stories are, if you want your passwords really encrypted, lock your OS user account and use full drive encryption.
Because I don't have time to read the source code of every version of every open source library/tool, or make sure the deployment process of all software I use is secure, or keep track of who controls these projects.
>And if you do, why are passwords so much more sensitive than your entire browsing history, all your emails
Because none of that allows anyone to take over my important accounts, steal my money or take my backups hostage. It's also much more difficult and inefficient to upload or parse gigabytes of documents and emails or keep a keylogger running undetected than it is to upload one small password file to the attacker's server.
>not-passphrase-protected SSH keys?
I don't have any of those.
Every application shouldn't have to reinvent encryption of its storage just so other apps can't read the data.
1. A 16-character password has 128 bits.
2. A 128-bit password takes 2^128 guesses.
3. The GTX 1080Ti does 8.5 billion guesses per second.
4. WolframAlpha tells me that $ \frac{2^128}{8.5 \cdot 10^9} $ seconds are $ 1.269 \cdot 10^21 $ years.
So, am I wrong, or did Palant, when he said passwords would take seconds to crack, assume passwords would be significantly shorter?
EDIT: Assuming a 16-bit all ascii lower case password, it’d still be 80 bits, which, given assumption 3, would still result in 4.51 million years, according to WolframAlpha.
I'd count 6 bits per letter (64 different characters) as a rough estimate for realistic passwords.
That’d still be 80 bits, and still secure enough.
"This article estimates that the average password is merely 40 bits strong, and that estimate is already higher than some of the others. In order to guess a 40 bit password you will need to test 2^39 guesses on average. If you do the math, cracking a password will take merely a minute on average then. Sure, you could choose a stronger password. But finding a considerably stronger password that you can still remember will be awfully hard."
E.g., we can assume that everyone has read the famous XKCD on passwords, and is using passwords that are a bunch of words after another, in lowercase ascii, which would get us somewhere around 80 bits of security, and still keep it memorable.
Guess I should dump the password store and go all-in on the 1Password extension.
To me is seems that this feature of browsers is really only meant as a protection against non-advanced attackers accessing an unlocked computer. For this scenario, having a stronger hash would do nothing.
Having a stronger hash would mitigate against exfiltration off the device by malware, but if malware can exfiltrate files off your device it's very likely they can e.g. read your passwords from memory, or keylog until the next time you input the password. It would also mitigate against someone being able to dump your password db off your filesystem if they get physical access to your computer, but full disk encryption does that better, and also protects all the rest of your personal data that's stored on the device.
Historically this is why Chrom{e,ium} has been resisting introducing this feature. Its uses are very limited against "real" attackers.
Mozilla spending time on cool tech rather than dumb migrations between password schemes that provide no value seems like a good tradeoff.
> Anybody who ever designed a login function on a website will likely see the red flag here
A login function on a website and a master password for your local system have very different threat models. Applying one to the other is a helpful heuristic but ultimately leads you in the wrong direction.
If we ask 'who is the attacker in the situation' the answer for both is very different.
The attacker we worry about in web logins is generally remote. The attacks we are primarily concerned with are:
a) They can dump hashes, often through SQL injection
b) They can attempt to bruteforce passwords remotely
With a local attacker for a local password db we have to assume that the attacker is executing locally on the system. Our threat model generally does not include the ability to exfiltrate the db in an encrypted state - at least, that isn't where you start.
Threat modeling is critical to security - there are a billion things like this that Could Be Better but we use threat modeling to prioritize. At some point someone asked "who are we protecting against?" and the answer was "a very, very specific type of attacker that we do not see often". And so yes, they focused elsewhere.
edit: To be clear, I don't work for Mozilla and actually have no idea if my "at some point" comment is accurate! I'm just saying that's generally how it goes. It could easily be the case that this just slipped through the cracks or some such thing. I do not know Mozilla's internal threat model, I can only guess.
I would say they should really use FDE. An attacker with that level of control can do a lot - FDE is designed for this type of attacker.
But yes, that is one attacker that this would protect against.
> With remote compromise of the system it is presumably possible to access the key if the browser is running via debuggers, it is at least a bit more work.
No need for debuggers, though that would certainly be one way to do it. This is not hard at all for an attacker, we see attackers hijacking processes all the time. Forcing the attacker to do 'a little more work' is not really the best place to spend time.
Firefox's threat is, in my opinion, malicious web pages, malicious extensions, or malicious use of/ abuse of their services etc (can't even imagine what abuse they see for their recent file sharing system). These probably take a significant amount of time and resources - these are the attackers they are probably dealing most days, if I had to guess. An attacker with unlimited offline access to an unencrypted hard drive seems pretty out of scope and better solved by the OS (I believe modern Windows and OSX systems actually FDE by default now). An attacker with full execution on the system also seems out of scope.
They could probably fix this master password thing pretty easily, it sounds simple enough and they might just because it's been called out, but my expectation is that this would probably not be a high priority otherwise.
I would also be concerned about users making the assumption that if they use a master password that they are safer from attackers - that it 'raises the bar', when it is unlikely to meaningfully for almost any attacker. A false sense of security is not a good thing.
I'm not a browser developer so I could be totally off and this could all be stuff they're super concerned about.
Edit: Looking through some mozilla bugs starting with the one citrin_ru mentions reminded me that unless they fixed it recently (which I don't think is the case) the master password doesn't encrypt cookies, so it is even less useful for most people than it might seem (and it doesn't normally meet my expectation of helping with a stolen disk).
This sentence is a strawman as you've invented the opponent's argument (literally no one has mentioned the NSA), just for what it's worth.
Your assertions that:
a) An attacker would have to rely on keylogging
b) Keylogging is a substantial barrier for attacker
are unfounded.
Note that full disk encryption offers exactly no protection if you forgot to lock your computer. Not that full disk encryption is common, almost nobody does that.
Honestly, it really boils down to "Do you want to use Linux and not have a half broken client running in Wine".
Either way, 1Password is nice :) I use KeepassXC myself which I can recommend.
Leaving filenames unencrypted means that anyone who can view your encrypted data (e.g. GitHub, GitLab, your local admin — whomever) knows which sites you frequent & care to protect.
PS: KeepassXC has an open issue to work on integrating itself as the system keyring (eg. providing the system keyring). If anyone is interested in working on it, check out https://github.com/keepassxreboot/keepassxc/issues/1403 !
This means that any government Mozilla must obey can do the same thing.
Mozilla Accounts are thus fundamentally insecure and must not be used. It breaks my heart: they went from having the world's best password-sync security to having its worst. Even Google's system is quite so blatantly security-hostile. When your concern for your users is less than Google's, you really are doing something wrong.
Can you elaborate on this? What do you mean by 'protected' and 'high entropy key'? It makes it sound like they aren't key stretching, which seems unlikely. Can you provide a source here?
> Worse, they use dynamically-downloaded JavaScript to handle your password, which means even if you use a high-entropy passphrase Mozilla can at any time send you malicious JavaScript and snarf your passphrase.
I'm unsure why you think Mozilla would do this, or why you would be using Firefox at all if you expect them to push malware to your system.
> This means that any government Mozilla must obey can do the same thing.
I'm not sure this is true, mostly because it lacks any sort of precedent.
I can't be sure, but I believe GP is referring to how Firefox Sync originally encrypted all the data locally with a long key before uploading it to Mozilla servers. To sync your data onto a new device you would have to transfer the key, which was done by generating a 16 char temporary password at one end, and then typing it at the other. Your private key data would then be sent, encrypted, to the new device.
At some point, if memory serves, Mozilla decided this was too complicated for ordinary users, and now only stores your sync data protected by whatever password you type in - which is going to be potentially brute-forceable.
bscphil did a good job of it. They stretch the password into a key, but a 24-bits-of-entropy key still has only 24 bits of entropy, no matter how much you stretch it.
Their previous system actually used properly-secure encryption keys.
> I'm unsure why you think Mozilla would do this, or why you would be using Firefox at all if you expect them to push malware to your system.
There's a difference between trusting them to provide a bit-for-bit identical binary to everyone, and trusting them to never send malicious JavaScript to one person. Downloads are public & could at least in theory be verified by the community at large, while a single JavaScript download could be subverted once and the world would never notice.
As for the why — I explained why afterwards. Not just Mozilla has the ability to steal your passwords: any government which can force it to comply can also snarf your passwords. As for precedent, court orders require third parties to do things all the time.
The only way to build a secure system is to build a system one couldn't subvert even if one wanted to, or were forced to. Mozilla completely, totally and utterly failed at that.
I would love to see if you can prove this. Please see their latest audit:
https://blog.mozilla.org/security/2017/07/18/web-service-aud...
https://medium.com/mozilla-tech/how-firefox-sync-keeps-your-...
When you enter your Firefox Account password, we first strengthen it by applying some cryptographic hashing, and then derive two separate keys: an authentication key, and an encryption key. The authentication key is transmitted to the server to prove that you own the account. A bug in TLS might cause this key to be leaked, and someone who intercepts this key could use it to authenticate to your account. But they cannot use it to access your sync data, because: The encryption key is used to encrypt your sync data before it leaves your machine. Since this key is never transmitted to the server, it cannot be leaked by a bug in TLS like the one that affected Cloudflare.
Go to https://accounts.firefox.com/signin and view source. Note that it loads https://accounts-static.cdn.mozilla.net/bundle-75dd38d5a7f98... and https://accounts-static.cdn.mozilla.net/bundle-75dd38d5a7f98....
The signin page itself may be edited at any time to point to different files, or to additional files, which load JavaScript which steals your password and sends it to Mozilla's servers. Game, set, match for your security.
Please do not spread FUD. This is hn. Mozilla cannot see your passwords.
See the latest security audit: https://blog.mozilla.org/security/2017/07/18/web-service-aud...
https://medium.com/mozilla-tech/how-firefox-sync-keeps-your-...
They process your password with JavaScript they deliver to your browser; they can at any time choose to deliver different, malicious JavaScript which sends them the raw password instead.
It's not FUD; it's the honest truth. For details, see my note https://news.ycombinator.com/item?id=16565382
If you're generating passwords from urandom, you can do this slightly nicer with:
head /dev/urandom | LC_ALL=C tr -dc "[:graph:]" | head -c 21
1. In case it's not obvious, 21 is the number of characters this will generate. Change that to generate more or fewer characters.
2. LC_ALL=C isn't necessary on some systems, but it's necessary on Mac OS and some others where `tr` expects UTF-8 encoded input on Mac OS unless that is overridden by the environment variable.
3. If you are generating a password for one of those dumb systems that restricts which characters you can use, you can change `"[:graph:]"` to something like `'A-Za-z0-9~!@#$%^&*_='` depending on which characters are allowed.
1Password is closed source and stores your passwords on a server which, should it ever be hacked, could easily cause all sorts of issues. If they received a secret order to compromise your accounts Lavabit-style, they wouldn't even have to be hacked--they might willingly backdoor their own product.
I use KeePass or KeePassX (depending on platform) which never require me to store my password database on someone else's computer.
Yes, they provide a cloud option where you can store your passwords on their server for synchronization purposes. But you don’t have to use it. You could just not use synchronization at all, or use a file stored on Dropbox, or iCloud, or other cloud provider of your choice. And if you use only a local file, you can still choose to sync that over the local network with approved clients of your choice with their built in network sync server.
The 1Password authors have been pretty open about how distributed their team is, and how no one single government would be able to convince them to do those kinds of things — the other developers would find out and then the game would be over.
They are also open about the crypto algorithms they use.
As for KeePass or KeePassX, which version do you use? Which of the dozens and dozens of different implementations do you use? Which database format do they support? Do you build the binaries yourself with trusted compilers? Where do you get those trusted compilers and how can you be sure that they haven’t been compromised?
Your options are:
A. Go to jail for contempt of court, which is a crime for which you receive no due process or appeals.
B. Give the control over to the government. Yes, your coworkers will find out about it, but you can always get another job.
Are you actually confident that all of the 1Password devs would choose A? Only one of them has to choose B.
I admire Ladar Levison for shutting down Lavabit rather than running a compromised business, because his bravery is the exception, not the rule. There are far more companies out there who have simply handed over the keys to the government when placed under minor duress, and I'm not sure on what basis you're assuming 1Password is going to be one of the exceptions.
> They are also open about the crypto algorithms they use.
Look, I'm sure the 1Password guys are nice, upstanding people, but implementing crypto correctly is hard, really hard. Sure, they are probably telling the truth about what algorithms they use. But did they implement them correctly? Would they tell you if they hadn't, given it would hurt their business?
> As for KeePass or KeePassX, which version do you use? Which of the dozens and dozens of different implementations do you use? Which database format do they support? Do you build the binaries yourself with trusted compilers? Where do you get those trusted compilers and how can you be sure that they haven’t been compromised?
Obviously security is relative, and you can point out ways in which my process is insecure. Indeed, you missed some (my computer could have a virus that keylogs my passwords--my password DB is on two drives which I connect via USB). But literally all of these apply to 1Password as well, so I don't think any of this proves that KeePass is just as insecure as 1Password.
And very notably, these are all security tradeoffs. I get something for every decrease in security I've accepted. The only thing you get for storing your passwords on someone else's computer is that they store them for you and let you access them from multiple devices, which is not something I want or need. I'm not sure you get anything at all in exchange for your password manager being closed-source--that's entirely for 1Password's benefit, not yours.
I looked into a number of password managers already. So far, 1Password is the only one where I can believe that they got the crypto right (other than my own, obviously). But I'll certainly try to find flaws in their implementation. There is a nice bug bounty on those.
Storing your password database on someone else's computer might not be a bad thing if it is securely encrypted. In the end, most people have more than one device these days. If your solution is doing manual "synchronization" then the result will often turn out less secure.
There's a reason the master password was removed for a while while rolling out the new synchronisation infrastructure; the assumption is that the data is protected by the key stored and generated locally - and that that key is protected by full disk encryption.
If you can read the key, it is assumed you already can read everything the key protects.
I do agree with the poster that this isn't always a great set of assumptions.
But still; one strong master passphrase generated through diceware or similar will allow you to use the password manager; and then you can use secure, high entropy "pass keys" for everything else (random passwords with ~128 bit entropy).
I honestly assumed the warning dialog i saw all those years was to tell me that, not that i needed to set a make believe password. that's is the only bad part, the make believe part. the suggestion on the article of using a slighter less-easy to crack schema for the make believe part is equally bad.
Edit: apparently Chrome's head of security also used to think so, and even called people that thought what the article suggest a "novice" https://news.ycombinator.com/item?id=6166886 seems that somebody lost a political battle at some point.