10 ms·

Master password in Firefox or Thunderbird? Do not bother

137 points by twapi 9y ago

yborg 9y ago
Fixing issues like this is clearly less important than implementing browser-side VR support, I don't see what Palant is on about. As a Firefox user, trading the security of any and all accounts I store passwords for in the browser is something I'd gladly exchange for ... anyway, VR is cool, right? Guess I should dump the password store and go all-in on the 1Password extension.
- delroth 9y ago
  What attack vector would be mitigated by switching to a stronger hashing scheme for this specific use case? And are there other mitigations that exist for this attack vector that would be more appropriate? 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.
  - staticassertion 9y ago
    A lot of people have problems modeling threats. For example, in the article: > 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.
    - joveian 9y ago
      For someone without disk encryption (many people, maybe most?), the encrypted database can be acquired if the machine is stolen while off. I would very much expect setting a master password to protect against that (at least unless other unencrypted personal information is used to take over accounts). 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.
      - staticassertion 9y ago
        > For someone without disk encryption (many people, maybe most?), 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.
        9y ago
  - yborg 9y ago
    The argument that "security is pointless unless it can prevent <nation-state> from obtaining the data" is a really tiresome strawman. If you force an adversary to have to keylog for data of interest you already have substantially increased the complexity of bulk attacks, which is the real threat for most users - mass password farming sweeps that can provide easy access to people's entire digital presence in one go.
    - deleted 9y ago
      [deleted]
    - staticassertion 9y ago
      > The argument that "security is pointless unless it can prevent <nation-state> from obtaining the data" is a really tiresome strawman. 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.
  - palant 9y ago
    Yes, it is stupid to leave your computer unlocked but it happens all the time in every workplace. If spending a minute pulling two files from an unlocked system is all it takes to get access to all of person's passwords - that's scary. And this would be trivial to mitigate, NSS already has everything necessary. 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.
- spondyl 9y ago
  As someone who has been through probably every popular password manager at this point, make sure to decide what you might need in the future. 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.
  - bhhaskin 9y ago
    Should check on password-store. Uses gpg encryption and git for syncing. Can't recommend it enough!
    - eadmund 9y ago
      Bear in mind, though, that password-store doesn't encrypt its filenames, so you should only use it with git-remote-gcrypt or similar (which isn't currently supported by any password-store mobile app, so you can't use it on your phone). 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.
  - scrollaway 9y ago
    Seconding KeepassXC recommendation. Here's an intro to it, and to password managers in general: https://leclan.ch/password-managers/ https://leclan.ch/password-managers/ 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 https://github.com/keepassxreboot/keepassxc/issues/1403 !
    - muxator 9y ago
      I fear to know the answer already, but let me ask anyway: does exist any strong password manager that is integrated with Firefox sync?
      - scrollaway 9y ago
- deleted 9y ago
  [deleted]
- papayawhip 9y ago
  Ah yes, they should re-assign all their generic swiss-army engineers from VR to Security.
  - marcinzm 9y ago
    Presumably they purposefully hired those VR engineers in the first place in which case they should have just hired more Security engineers.
- joveian 9y ago
  It is unfortunate that Mozilla does this without telling the user that you need a good password (or better, generating one for you), but you can just use a good password. 21 random base 64 characters is almost the strength of the 128-bit encryption. You can memorize it easily by writing it down (divide into three groups of seven) and entering it from the paper for two or three weeks. The trick is to try never to get it wrong (you will occasionally anyway, but try not to guess - the right answer eventually come to mind effortlessly before you look at the paper, which should be turned to not normally be visible). On linux, you can use `base64 < /dev/urandom` (or `tr -dc "[:graph:]" < /dev/urandom` which picks from a few more characters) to get the password.
  - kerkeslager 9y ago
    I prefer to use Diceware[1] as I find these passwords easier to memorize. But for a master password it doesn't matter as much since you only have to memorize it once. 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 A few things about this: 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. [1] http://world.std.com/%7Ereinhold/diceware.html http://world.std.com/%7Ereinhold/diceware.html
- kerkeslager 9y ago
  At least Firefox is open source and probably doesn't broadcast your passwords back to the server. 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.
  - bradknowles 9y ago
    Sorry, you’ve got some things wrong about 1Password. 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?
    - kerkeslager 9y ago
      > 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. 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.
eikenberry 9y ago
I don't understand why firefox doesn't use the underlying OS keyring like Chromium does. I can sort of understand why it currently doesn't (legacy code)... but why the lockbox extension instead of proper OS support? The more places your password is stored the greater the chance of one of them leaking them.
- jcranmer 9y ago
  As I understand it, using the OS keyring makes it impossible to do synchronization of the passwords (e.g., between mobile device and desktop).
  - tacomonstrous 9y ago
    This can't be the explanation, since Chrome manages to sync passwords between devices.
    - staticassertion 9y ago
      Are you sure that Chrome uses keyring?
- acdha 9y ago
  There’s a long running ticket to do this on OS X which started out as NIH/apathy but gained a good reason not to as Apple restricted iCloud password support to App Store applications. https://bugzilla.mozilla.org/show_bug.cgi?id=152485 https://bugzilla.mozilla.org/show_bug.cgi?id=152485
  - eridius 9y ago
    That ticket is marked as resolved and the last update is 16 years ago. 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.
e12e 9y ago
This certainly is a usability issue with security implications. But it's salted, so if can have 60-96 bits of entropy in your master password - that should be maintained - and a reasonable level of security maintained. 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).
kuschku 9y ago
I’m sure my napkin math is off, but: 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.
- gweinberg 9y ago
  That would be true if the password were 16 random ascii characters. But of course it's not. It's almost certainly only using printable characters, and probably has something a lot like words in it.
  - kzrdude 9y ago
    Just to chip another little piece off, ascii is a 7-bit encoding, and the 8th bit is clear, so that makes 16 × 7 = 112 bits if we use any ascii byte (0..=128). I'd count 6 bits per letter (64 different characters) as a rough estimate for realistic passwords.
    - Buge 9y ago
      English text has 1.46 bits of entropy per character. https://www.gwern.net/docs/statistics/1996-teahan.pdf https://www.gwern.net/docs/statistics/1996-teahan.pdf
      - kzrdude 9y ago
        You wouldn't use english text for the password, for this reason.
  - kuschku 9y ago
    That’s why I, in the EDIT, then chose to assume 2^5 different characters, which is roughly lowercase ascii plus some special characters. That’d still be 80 bits, and still secure enough.
gcb0 9y ago
i thought everyone knew that every browser saving password was completely insecure and only good for throw away accounts (e.g. hackernews :) 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 https://news.ycombinator.com/item?id=6166886 seems that somebody lost a political battle at some point.
- callumjones 9y ago
  I don’t think this is true for Safari, where the passwords are backed by OS X Keychain.
takeda 9y ago
Not really what article talks about, but I don't understand why browsers while they copied some nice Opera[1] features (Chrome first then FF out of Chrome) none bothered to copy Wand. 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.
- forapurpose 9y ago
  I thought FF copied Opera features before Chrome existed?
vortico 9y ago
The author admitted the stronger-than-needed title in the first comment, but I'd like to make it clear when talking about practical personal security: 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.
- pzxc 9y ago
  The alternative is not to give up on password management completely, but to use a proper password manager like KeePass.
  - unsignedint 9y ago
    I agree with you on this one, KeePass is way to go compared to relying on browser's password manager. 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...
    - cdancette 9y ago
      Android 8 provides an autofill API for this purpose! But it's only working in apps, not in the browser
  - zitterbewegung 9y ago
    What if you took Firefox or chrome and replaced the password manager with a keepass compatible system by default and kept the usability?
    - fyfy18 9y ago
      If password managers are going to become popular for end users it needs to be something that’s built into the browser and interopable. I’d love to see this turned into a standard that all browser and device manufacturers (when I log into an app on my phone the password manager should be integrated) can implement.
Santosh83 9y ago
Everyone suggesting to use a bigger and/or more random string are missing the point that your average user won't do that. As a sort of computer nerd, my master password is 46 characters from the full set of letters, numbers, symbols and in both cases. It took me a week to memorise it flawlessly. Do we really think a regular user will take this effort? Instead they will continue using their simple, short passwords (if they set a MP at all. Most won't), which is why the article is right that a resistant hashing algo like argon2 can only improve security. The issue is not protecting users whose systems have malware. That's obviously a battle lost before its even begun. The issue is someone gaining access to your password DB and then being able to brute-force within reasonable time, which the current key derivation allows and a stronger algorithm can plug that weakness. Presumably the changes are not complicated or labour intensive, so the fact it is an open bug since almost a decade is unfortunate.
- stouset 9y ago
  For what it’s worth, assuming an alphabet of 72 characters (52 letters, 10 digits, 10 symbols), this is ridiculously higher entropy than a 128-bit encryption key. There is no absolutely no need for your password to be this long. Even just twenty characters is within spitting distance of 2^128.
  - Buge 9y ago
    >For what it’s worth, assuming an alphabet of 72 characters (52 letters, 10 digits, 10 symbols), this is ridiculously higher entropy than a 128-bit encryption key. 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 https://www.gwern.net/docs/statistics/1996-teahan.pdf [2] https://www.reddit.com/r/Bitcoin/comments/1ndsxi/a_test_of_brainwallet_passphrases/ https://www.reddit.com/r/Bitcoin/comments/1ndsxi/a_test_of_b...
citrin_ru 9y ago
I expected that Firefox uses KDF with big iteration count. Unfortunately it isn't true: https://bugzilla.mozilla.org/show_bug.cgi?id=524403 https://bugzilla.mozilla.org/show_bug.cgi?id=524403
Too 9y ago
Related interesting read: Why pidgin doesn't store passwords encrypted https://developer.pidgin.im/wiki/PlainTextPasswords https://developer.pidgin.im/wiki/PlainTextPasswords 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.
- fauigerzigerk 9y ago
  And never run any programs that you don't trust with all of your passwords? That doesn't seem realistic.
  - claudius 9y ago
    Why would you run untrusted programs? And if you do, why are passwords so much more sensitive than your entire browsing history, all your emails and e.g. all your not-passphrase-protected SSH keys?
    - fauigerzigerk 9y ago
      >Why would you run untrusted programs? 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.
  - Too 9y ago
    Android and iOS provide sandboxes for applications so you can install less trustworthy apps with smaller risk. Desktop OS's should really catch up here. Maybe not to the extreme level as iOS where there isn't even a concept of file system but at least provide a separate safe storage location for each application. Every application shouldn't have to reinvent encryption of its storage just so other apps can't read the data.
orev 9y ago
The article completely misses the threat model, or the comparison on the threat models. FOR REGULAR USERS, the choice is to either have an easy to remember/guess/same password on every Internet-exposed site, OR to use the password saver with a potentially easy to guess local password while using longer/harder/different passwords on each site. The second model is far stronger than the first, as one now has at least some protection from the enitre Internet and unscrupulous web site operators. A local compromise is bad of course, but that affects both models equally as either the password database is stolen, a keylogger is installed, or any of the number of other issues that arise from gaining local access to a system.
- palant 9y ago
  No, I didn't miss the threat model. I am all for password managers, in fact I am even developing one myself. The sad truth is however, most password managers aren't exactly a shining example of security best practices. This blog post is simply me being disappointed seeing Mozilla do so poorly. As things are now, the master password on the Firefox password manager (a common recommendation meant to improve security) is little more than security theater. But I'm not saying of course that no password manager whatsoever is a better solution.

137 points by twapi 9y ago

Fixing issues like this is clearly less important than implementing browser-side VR support, I don't see what Palant is on about. As a Firefox user, trading the security of any and all accounts I store passwords for in the browser is something I'd gladly exchange for ... anyway, VR is cool, right? Guess I should dump the password store and go all-in on the 1Password extension.

delroth 9y ago
What attack vector would be mitigated by switching to a stronger hashing scheme for this specific use case? And are there other mitigations that exist for this attack vector that would be more appropriate? 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.
- staticassertion 9y ago
  A lot of people have problems modeling threats. For example, in the article: > 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.
  - joveian 9y ago
    For someone without disk encryption (many people, maybe most?), the encrypted database can be acquired if the machine is stolen while off. I would very much expect setting a master password to protect against that (at least unless other unencrypted personal information is used to take over accounts). 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.
    - staticassertion 9y ago
      > For someone without disk encryption (many people, maybe most?), 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.
      - 9y ago
- yborg 9y ago
  The argument that "security is pointless unless it can prevent <nation-state> from obtaining the data" is a really tiresome strawman. If you force an adversary to have to keylog for data of interest you already have substantially increased the complexity of bulk attacks, which is the real threat for most users - mass password farming sweeps that can provide easy access to people's entire digital presence in one go.
  - deleted 9y ago
    [deleted]
  - staticassertion 9y ago
    > The argument that "security is pointless unless it can prevent <nation-state> from obtaining the data" is a really tiresome strawman. 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.
- palant 9y ago
  Yes, it is stupid to leave your computer unlocked but it happens all the time in every workplace. If spending a minute pulling two files from an unlocked system is all it takes to get access to all of person's passwords - that's scary. And this would be trivial to mitigate, NSS already has everything necessary. 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.
spondyl 9y ago
As someone who has been through probably every popular password manager at this point, make sure to decide what you might need in the future. 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.
- bhhaskin 9y ago
  Should check on password-store. Uses gpg encryption and git for syncing. Can't recommend it enough!
  - eadmund 9y ago
    Bear in mind, though, that password-store doesn't encrypt its filenames, so you should only use it with git-remote-gcrypt or similar (which isn't currently supported by any password-store mobile app, so you can't use it on your phone). 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.
- scrollaway 9y ago
  Seconding KeepassXC recommendation. Here's an intro to it, and to password managers in general: https://leclan.ch/password-managers/ https://leclan.ch/password-managers/ 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 https://github.com/keepassxreboot/keepassxc/issues/1403 !
  - muxator 9y ago
    I fear to know the answer already, but let me ask anyway: does exist any strong password manager that is integrated with Firefox sync?
    - scrollaway 9y ago
deleted 9y ago
[deleted]
papayawhip 9y ago
Ah yes, they should re-assign all their generic swiss-army engineers from VR to Security.
- marcinzm 9y ago
  Presumably they purposefully hired those VR engineers in the first place in which case they should have just hired more Security engineers.
joveian 9y ago
It is unfortunate that Mozilla does this without telling the user that you need a good password (or better, generating one for you), but you can just use a good password. 21 random base 64 characters is almost the strength of the 128-bit encryption. You can memorize it easily by writing it down (divide into three groups of seven) and entering it from the paper for two or three weeks. The trick is to try never to get it wrong (you will occasionally anyway, but try not to guess - the right answer eventually come to mind effortlessly before you look at the paper, which should be turned to not normally be visible). On linux, you can use `base64 < /dev/urandom` (or `tr -dc "[:graph:]" < /dev/urandom` which picks from a few more characters) to get the password.
- kerkeslager 9y ago
  I prefer to use Diceware[1] as I find these passwords easier to memorize. But for a master password it doesn't matter as much since you only have to memorize it once. 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 A few things about this: 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. [1] http://world.std.com/%7Ereinhold/diceware.html http://world.std.com/%7Ereinhold/diceware.html
kerkeslager 9y ago
At least Firefox is open source and probably doesn't broadcast your passwords back to the server. 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.
- bradknowles 9y ago
  Sorry, you’ve got some things wrong about 1Password. 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?
  - kerkeslager 9y ago
    > 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. 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.

eikenberry 9y ago

I don't understand why firefox doesn't use the underlying OS keyring like Chromium does. I can sort of understand why it currently doesn't (legacy code)... but why the lockbox extension instead of proper OS support? The more places your password is stored the greater the chance of one of them leaking them.

jcranmer 9y ago
As I understand it, using the OS keyring makes it impossible to do synchronization of the passwords (e.g., between mobile device and desktop).
- tacomonstrous 9y ago
  This can't be the explanation, since Chrome manages to sync passwords between devices.
  - staticassertion 9y ago
    Are you sure that Chrome uses keyring?
acdha 9y ago
There’s a long running ticket to do this on OS X which started out as NIH/apathy but gained a good reason not to as Apple restricted iCloud password support to App Store applications. https://bugzilla.mozilla.org/show_bug.cgi?id=152485 https://bugzilla.mozilla.org/show_bug.cgi?id=152485
- eridius 9y ago
  That ticket is marked as resolved and the last update is 16 years ago. 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.

e12e 9y ago

This certainly is a usability issue with security implications. But it's salted, so if can have 60-96 bits of entropy in your master password - that should be maintained - and a reasonable level of security maintained. 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).

kuschku 9y ago

I’m sure my napkin math is off, but: 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.

gweinberg 9y ago
That would be true if the password were 16 random ascii characters. But of course it's not. It's almost certainly only using printable characters, and probably has something a lot like words in it.
- kzrdude 9y ago
  Just to chip another little piece off, ascii is a 7-bit encoding, and the 8th bit is clear, so that makes 16 × 7 = 112 bits if we use any ascii byte (0..=128). I'd count 6 bits per letter (64 different characters) as a rough estimate for realistic passwords.
  - Buge 9y ago
    English text has 1.46 bits of entropy per character. https://www.gwern.net/docs/statistics/1996-teahan.pdf https://www.gwern.net/docs/statistics/1996-teahan.pdf
    - kzrdude 9y ago
      You wouldn't use english text for the password, for this reason.
- kuschku 9y ago
  That’s why I, in the EDIT, then chose to assume 2^5 different characters, which is roughly lowercase ascii plus some special characters. That’d still be 80 bits, and still secure enough.

gcb0 9y ago

i thought everyone knew that every browser saving password was completely insecure and only good for throw away accounts (e.g. hackernews :) 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 https://news.ycombinator.com/item?id=6166886 seems that somebody lost a political battle at some point.

callumjones 9y ago
I don’t think this is true for Safari, where the passwords are backed by OS X Keychain.

takeda 9y ago

Not really what article talks about, but I don't understand why browsers while they copied some nice Opera[1] features (Chrome first then FF out of Chrome) none bothered to copy Wand. 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.

forapurpose 9y ago
I thought FF copied Opera features before Chrome existed?

vortico 9y ago

The author admitted the stronger-than-needed title in the first comment, but I'd like to make it clear when talking about practical personal security: 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.

pzxc 9y ago
The alternative is not to give up on password management completely, but to use a proper password manager like KeePass.
- unsignedint 9y ago
  I agree with you on this one, KeePass is way to go compared to relying on browser's password manager. 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...
  - cdancette 9y ago
    Android 8 provides an autofill API for this purpose! But it's only working in apps, not in the browser
- zitterbewegung 9y ago
  What if you took Firefox or chrome and replaced the password manager with a keepass compatible system by default and kept the usability?
  - fyfy18 9y ago
    If password managers are going to become popular for end users it needs to be something that’s built into the browser and interopable. I’d love to see this turned into a standard that all browser and device manufacturers (when I log into an app on my phone the password manager should be integrated) can implement.

Santosh83 9y ago

Everyone suggesting to use a bigger and/or more random string are missing the point that your average user won't do that. As a sort of computer nerd, my master password is 46 characters from the full set of letters, numbers, symbols and in both cases. It took me a week to memorise it flawlessly. Do we really think a regular user will take this effort? Instead they will continue using their simple, short passwords (if they set a MP at all. Most won't), which is why the article is right that a resistant hashing algo like argon2 can only improve security. The issue is not protecting users whose systems have malware. That's obviously a battle lost before its even begun. The issue is someone gaining access to your password DB and then being able to brute-force within reasonable time, which the current key derivation allows and a stronger algorithm can plug that weakness. Presumably the changes are not complicated or labour intensive, so the fact it is an open bug since almost a decade is unfortunate.

stouset 9y ago
For what it’s worth, assuming an alphabet of 72 characters (52 letters, 10 digits, 10 symbols), this is ridiculously higher entropy than a 128-bit encryption key. There is no absolutely no need for your password to be this long. Even just twenty characters is within spitting distance of 2^128.
- Buge 9y ago
  >For what it’s worth, assuming an alphabet of 72 characters (52 letters, 10 digits, 10 symbols), this is ridiculously higher entropy than a 128-bit encryption key. 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 https://www.gwern.net/docs/statistics/1996-teahan.pdf [2] https://www.reddit.com/r/Bitcoin/comments/1ndsxi/a_test_of_brainwallet_passphrases/ https://www.reddit.com/r/Bitcoin/comments/1ndsxi/a_test_of_b...

citrin_ru 9y ago

I expected that Firefox uses KDF with big iteration count. Unfortunately it isn't true: https://bugzilla.mozilla.org/show_bug.cgi?id=524403 https://bugzilla.mozilla.org/show_bug.cgi?id=524403

Too 9y ago

Related interesting read: Why pidgin doesn't store passwords encrypted https://developer.pidgin.im/wiki/PlainTextPasswords https://developer.pidgin.im/wiki/PlainTextPasswords 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.

fauigerzigerk 9y ago
And never run any programs that you don't trust with all of your passwords? That doesn't seem realistic.
- claudius 9y ago
  Why would you run untrusted programs? And if you do, why are passwords so much more sensitive than your entire browsing history, all your emails and e.g. all your not-passphrase-protected SSH keys?
  - fauigerzigerk 9y ago
    >Why would you run untrusted programs? 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.
- Too 9y ago
  Android and iOS provide sandboxes for applications so you can install less trustworthy apps with smaller risk. Desktop OS's should really catch up here. Maybe not to the extreme level as iOS where there isn't even a concept of file system but at least provide a separate safe storage location for each application. Every application shouldn't have to reinvent encryption of its storage just so other apps can't read the data.

orev 9y ago

The article completely misses the threat model, or the comparison on the threat models. FOR REGULAR USERS, the choice is to either have an easy to remember/guess/same password on every Internet-exposed site, OR to use the password saver with a potentially easy to guess local password while using longer/harder/different passwords on each site. The second model is far stronger than the first, as one now has at least some protection from the enitre Internet and unscrupulous web site operators. A local compromise is bad of course, but that affects both models equally as either the password database is stolen, a keylogger is installed, or any of the number of other issues that arise from gaining local access to a system.

palant 9y ago
No, I didn't miss the threat model. I am all for password managers, in fact I am even developing one myself. The sad truth is however, most password managers aren't exactly a shining example of security best practices. This blog post is simply me being disappointed seeing Mozilla do so poorly. As things are now, the master password on the Firefox password manager (a common recommendation meant to improve security) is little more than security theater. But I'm not saying of course that no password manager whatsoever is a better solution.