"What is password entropy?" | Privacy Basics by Proton

Sloppy article Proton put out recently: What is password entropy? | Proton

Says just the word Bankruptcies has 68 bits of entropy, which is definitely overstated.

“Generally, a strong or high-entropy password scores at least 75 bits. Anything measuring fewer than 72 bits is reasonably easy for a machine to crack.”

There’s not much difference between 76 bits of entropy and 71 bits of entropy, yet they claim the former is strong while the latter is reasonably easy to crack.

"To recap, a truly secure password contains, for example:

A passphrase of roughly 20 characters"

A passphrase of 20 characters would be very weak.

Then they state:

“The example from above, HelpFidoSaveTony33!, meets all these requirements and creates a password with roughly 117 bits of entropy, which is currently impossible to crack by brute force.”

That definitely does not have 117 bits of entropy and isn’t impossible to crack by brute force.

KeePassXC has one of the best generators and entropy calculators. It says it has under 52 bits of entropy. To achieve an excellent entropy store in KPXC, you need at least 100 bits of entropy. Importantly, KPXC calculates entropy differently depending on whether you select password or passphrase. If the generator knows a passphrase is used, entropy is much lower for a given length, as it should be. Many times people believe their passphrases are stronger than they are because they run them through entropy calculators assuming they are passwords.

In general, you would think Proton would have had someone more informed and more senior review this important blog post from October of 2023?

By the way, KPXC says Bankruptcies has only 16 bits of entropy.

Bits of entropy only applies if the password/phrase is randomly generated. It is a measure of the size of the “search space”.

Human generated dramatically reduces the search space by using known patterns, such as capitalizing initial letters, using vowels every few characters and using well-known 1337 transforms.

Also on quickly reviewing another article by the same author, I read (Is Google Drive secure? | Proton):

“Google Drive also encrypts your files while they’re stored on its servers using AES-128 symmetric encryption.”

However, Google says (Get started with encrypted files in Drive, Docs, Sheets & Slides - Android - Google Docs Editors Help):

“All files uploaded to Drive or created in Docs, Sheets, and Slides are encrypted in transit and at rest with AES256 bit encryption.”

One thing interesting there is this:

“Proton Sentinel can recognize and stop malicious login attempts, meaning that even if an attacker gets a hold of your password, there’s still a good chance they won’t be able to access your account.”

In my view, Bitwarden should implement the same kind of protection.

“Human generated dramatically reduces the search space by using known patterns, such as capitalizing initial letters, using vowels every few characters and using well-known 1337 transforms.”

Yes, but the consensus seems that instead of trying to add more entropy for a given # of characters, simply add more characters or words. For example, instead of changing the word Docking to DockinG in your passphrase, it’s suggested you simply add another word.

That’s just what I’ve come across although I personally think some mixing of case can be useful and beneficial without making the passphrase significantly more difficult to memorize or type.

On the other hand, it can be very easy to type out an all-lowercase passphrase, and it may be more useful just to add more words.

For example, I can quickly type out a long passphrase if it is all lowercase without any tricks, but if I have to remember to add certain capitals and numbers and other gimmicks, I get slowed down significantly, and it is likely I will make typos if I am not very careful. If you make typos in a public setting and have to view the password/passphrase to correct it, you are at high risk of having it stolen. In fact, with hidden cameras so small and discreet these days, you could even have it stolen when inputting it in a private hotel, motel, or Airbnb. Even a basic security camera could be used to steal it.

So, why not simply use a 9-10-word passphrase in all lowercase, which can be quickly typed out, and will soon enough get remembered?

That would be for a master pass. For online accounts where you don’t have to memorize them or type them out, may as well use ugly, fully random, 22+ character passwords.

I say 22+ characters even though I could say 15+ because there’s no real negative adding those extra characters if using a password manager like Bitwarden.

Another point is that I continue to like KeePass’s key file option. I use it to strengthen my password since in addition to my KP master password, I use a passphrase-based key file, ensuring entropy hits 256 bits.

To get entropy at 256 bits with Bitwarden you have to use a more cumbersome master password, since there is no key file adding entropy.

The KeePass solution is more elegant and advanced. Since my key file just is a passphrase in a text file, I can easily store it along with other important passwords and regenerate it any time I need to.

By the way, consider a master password like this, without the quotes:

“There are very few things to consider when choosing a master password.”

Do you really think something like that could be brute forced? Most unlikely. I would guess it is very strong. And I just came up with it most quickly right now. It is easy type, easy to remember, and very difficult to crack.

Therefore, there may be something to be said for having as a master password a simple sentence, albeit it with some more complexity and sparkle than the one above.

Let me hack away at a sampling of the nonsense here.

The word bankruptcies is among the 30,000 or so most common English words, so it would have an entropy of around 15 bits (and much lower if the password is for an account belonging to a banker, lawyer, or serial entrepreneur). If the choice to capitalize the first letter or not was random, then we could allow for an extra bit of entropy, for a total of 16 bits. If anybody tells you otherwise, then you can safely disregard any other claims or advice from that source.

These numbers are pulled out of thin air. No definitive claim can be made about password crackability, unless assumptions about hashing algorithm and computing hardware are disclosed (which the above source has neglected to do). For a Bitwarden password hashed using 600,000 iterations of PBKDF2-SHA256, a 50-bit password is uncrackable using a single RTX 4090 GPU.


To be continued…

1 Like

Richie Koch is trying to introduce neophytes to password entropy, so his lack of precision in some areas is perhaps understandable.

If you understand entropy already, then you will know that it is a function of the search space. Thus, if we assume Bankruptcies emerged from a search space of about 65000 dictionary words (non-random strings) then the entropy of that generator would be 16 bits per word. If we assume it came from all upper and lower case alpha and is a random string then it is 68. If it emerged as a random string from the character set aBceiknprstu then entropy of the generator is 43 bits for a 12 character string.

KeePassXC’s entropy calculator is like every other one: pretty pointless. Without knowledge of the search space, the only thing with which attackers are concerned, you cannot make a reliable estimate.

The major sins of passwords are reuse, obviousness, and brevity. Counter those in that order then move security concerns on to the rest of your behaviours, for example confidence tricks (the basis of most investment and romance scams), or leakage of private information, or to network protection.

1 Like

In this case, you are drawing (without replacement) from the 12 characters Bankruptcies, which would produce an entropy of only 38 bits.

I would add non-randomness and disclosure to the cardinal sins.

Yes, I calculated with replacement despite the ‘result’. No matter, our point remains that examining the content of a string is a very unreliable indicator of strength of the generator.

Adding a comment about an earlier post, shifting from 71 to 76 bits in the generator is not trivial. It multiplies cost to crack by 32 times. Against ordinary people attackers are in it for the money so this uplift in cost matters. It is a reason security practices, as mentioned by @grb and me, rapidly overtake pasword strength as the greatest threat to people sensible enough to use Bitwarden or one of its brethren.

This is the benefit of passphrases: easy to type, reasonably easy to commit to memory, while completely secure — if random.

Now you’re making the same mistakes as the author of the Proton blog article. The words are extremely common and could be generated using dictionary of only 200 popular words (except for three words, which would need a somewhat larger dictionary, containing around 5000 common words). So we could estimate an entropy of around 34 bits if it was a randomly generated passphrase. However, the rules of English grammar severely constrain this sentence, and it is known that this reduces the entropy by about a half. So we’re left with about 17 bits of entropy, which can easily be brute-forced using a single GPU.

Some say length is more important than entropy. I don’t think we really know. How is the GPU supposed to know the password is so many characters and is in the form of a sentence? Is it going to try endless many sentences after not making progress brute forcing a password? Remember, the GPU doesn’t get told it’s 80% correct or 20% correct. It has no clue.

How about the following sentence?

It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness, it was the epoch of belief, it was the epoch of incredulity, it was the season of Light, it was the season of Darkness, it was the spring of hope, it was the winter of despair.

Can’t complain about its length, right?

When the above sentence was used as a passphrase for a Bitcoin wallet, it was cracked in less than a day.

Length offers no protection without randomness.

1 Like

Well, that was a credential stuffing attack. The sentence I used isn’t going to be in any such database. Also is possible the user was phished or compromised in some other way. We can’t know, but it is reasonable to believe a cracker could have a database of popular sentences from classic books.

Yes. In fact they have whole books from which to extract well-known paragraphs. The question is not “your sentence”, which may happen to be quite secure on reasonable attacks. The question is advisable security practices. Inventing one’s own pass phrase is not among them.

2 Likes

I too prefer typing more and using the shift key less. Turns out, the “break-even” point is about 25% longer – a single-case letter has 4.7 bits of entropy, whereas full-complexity characters (upper, lower, digits, special) have 6.13 bits (per Password Bits).

The problem with a natural language sentence is that there is no good way to objectively measure strength. For example, consider these sentences:

  • “There are very few things to consider when choosing a master password.”
  • “Hi, my name is Werner Brandes. My voice is my passport. Verify Me.”

One may consider the first to be “strong”, but the second definitely is not because it is a movie quote. But, there is no way to distinguish the two cases.

Diceware, on the other other hand has objectively measurable strength because the words are randomly selected from a dictionary of known size. For example, 4 dicewords has 51.7 bits of entropy when using a 7776 word dictionary – 12.9 bits per word.

Your vault is encrypted with a 265 bit master key so the encryption itself is equivalent to KeePass. Additionally, neither the master password nor the master key ever leave your PC, so they are secured about as well as Keypass’s key file.

The whole key file (or “secret key”) trick has been litigated ad nauseam in this forum, but the argument is about the master password hash — which is stored on the servers. With a key file or secret key, the client essentially hashes their plaintext master password using the secret key/file as a salt, then applies the KDF, and then stores the result on a cloud server (possibly with additional server-side hashing). This makes it impossible to brute-force the master password from the stored hash, unless the secret key/file is also known; the drawback is that the user cannot set up any new client app installations unless they complete a provisioning process to copy the secret key/file (which increases the risk of account lockout in case of device loss, etc.).

What Bitwarden does instead is IMO more clever and user-friendly. The master password hash (produced by applying the KDF to the plaintext master password in the client app) is transmitted to the cloud servers, where it not only undergoes additional hashing, but is also AES-encrypted using a 256-bit random key before being stored on the cloud servers. The beauty of the approach is that the 256-bit encryption key is safeguarded by storing it in a hardware security module within a tightly controlled Key Management Service (which is completely independent of the database servers). The end result is that the strength of the master password hash while at rest in Bitwarden’s cloud servers is equivalent to what is achieved using a secret key/file, while being completely transparent to the user (i.e., avoiding the inconveniences and risks of needing to maintain a locally stored secret key/file).

3 Likes

I wrote:

This is why I decided on a passphrase-based text file as my key file. This long passphrase is easily written down and regenerated as needed. I am not at any more risk of losing it than I am any important master password I have written down in multiple locations. The result is that my KeePass password is strengthened by this long passphrase in the text file that is used as the key file, and there is negligible added risk in losing it.

Also adds more security when storing the KeePass file on a cloud account since the database is not stored with the key file.

My BW vault were stolen from Bitwarden’s servers the attackers would try to brute force my BW master pass, which is weaker than is the combination of my KeePass master pass + passphrase-based text file.

Some have decided on using an extremely strong BW master pass and then for daily use using a much lower entropy pin number. This can accomplish something similar and probably is the best approach for most users with good local security, as long as they leave the other settings on defaults to avoid writing to disk the pin-protected vault.

However, I deleted the post because I am still learning and don’t actually know the logistics of how an attacker would go after a stolen vault to brute force the password. It sounds like BW is designed to make this extraordinarily difficult even if the BW master pass is not the best.

They might try (if they don’t know enough about Bitwarden’s multifactor encryption architecture to realize that the effort is futile), but they would not succeed.

my BW master pass, which is weaker than is the combination of my KeePass master pass + passphrase-based text file.

You should have a strong Bitwarden master password regardless, to protect the locally cached copies of your vault data. And if you do, the added entropy from the secret key/file is overkill (i.e., unnecessary).

However, I deleted the post because I am still learning and don’t actually know the logistics of how an attacker would go after a stolen vault to brute force the password.

Here is some reading:

1 Like

Thanks for the insight. Never would have suspected that to be the concern and also a bit surprised it is. Even the hash is 256 bits, and salted with the email address (via the master key), so I continue to scratch my head as to why the whole key-file debate.

The idea is that by hashing a password guess, an attacker can verify whether their guess was correct by comparing the hashed guess to the stolen password hash.

If the master password is strong (as it should be, to protect against local attacks), then this is a non-issue. Secret keys/files are for users who wish to use a weak vault password, and who believe that they are invulnerable to local attacks.