
Master password in Firefox or Thunderbird? Do not bother - twapi
https://palant.de/2018/03/10/master-password-in-firefox-or-thunderbird-do-not-bother
======
vortico
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
The alternative is not to give up on password management completely, but to
use a proper password manager like KeePass.

~~~
zitterbewegung
What if you took Firefox or chrome and replaced the password manager with a
keepass compatible system by default and kept the usability?

~~~
fyfy18
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.

------
eikenberry
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.

~~~
acdha
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
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.

~~~
acdha
Ack, sorry: that link should have been
[https://bugzilla.mozilla.org/show_bug.cgi?id=106400](https://bugzilla.mozilla.org/show_bug.cgi?id=106400)
– I was hastily searching bugzilla on a phone.

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](https://bugs.chromium.org/p/chromium/issues/detail?id=466638)

~~~
eridius
Thanks.

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.

~~~
acdha
It mostly annoys me that we had at least 17 years where this relatively modest
amount of code would have made a big security & usability benefit. Even if
Apple eventually deprecated it, that’s a longer useful lifespan than an awful
lot of code has.

------
Santosh83
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
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
>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_b...](https://www.reddit.com/r/Bitcoin/comments/1ndsxi/a_test_of_brainwallet_passphrases/)

~~~
Dylan16807
If we take the post at face value, it's strong overkill. Face value means that
"46 characters from the full set" is even vaguely descriptive of the password.

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.

~~~
Buge
I never said any part of the post was a lie. Most people's passwords are not
random. The word "password" doesn't mean random. So there isn't a reason to
assume that the password is random. xkcd's recommended password is 25
characters, and 44 bits of entropy. Extrapolating that out would mean a 46
character password would be 81 bits of entropy.

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.

~~~
stouset
At the point where someone has a 46-character password consisting of
uppercase, lowercase, digits, and symbols that takes a week to memorize, I
think it’s a fair guess that it’s random.

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.

------
takeda
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
I thought FF copied Opera features before Chrome existed?

------
Too
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
And never run any programs that you don't trust with all of your passwords?
That doesn't seem realistic.

~~~
claudius
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
_> 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.

------
kuschku
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
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
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
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
You wouldn't use english text for the password, for this reason.

------
citrin_ru
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)

------
yborg
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
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.

~~~
yborg
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.

~~~
staticassertion
> 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.

------
e12e
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).

------
orev
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
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.

------
gcb0
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
I don’t think this is true for Safari, where the passwords are backed by OS X
Keychain.

