Passphrase Generation about mobile

[kspearrin]

I'll keep this open since this is how I manage the roadmap.

[timdvail]

I definitely agree that passphrase generator would be a bonus. But I'd like to bring up a caveat.

In theory, a passphrase is only as strong as the method used to obtain it, just like it is for random passwords. In another words -- the true strength of both in the face of someone who knows your method of choosing the password/passphrase is directly proportional to how many random bits the computer has to obtain in order to decide on the given password/passphrase. This means that a passphrase that is based on a dictionary would have however bits of security based on the number of words in the dictionary for each word. A password, on the other hand has a higher number of bits of security for each character in the password. This means that if you are limited by password length -- password is much better. That said, the only reason why passphrase can be better is because in practice there are different word lists out there that makes it harder for a password guesser to really narrow down the dictionary. This can in practice increase the number of bits of security because then they have to try words that might not even be in your dictionary. Keep in mind, though, you lose that benefit the instant your attacker knows exactly what code/methodology is generating your passphrases.

I tend to prefer automatically, randomly generated password if I have no intention of remembering said password. On the other hand, if I intend to remember it -- then definitely I'd prefer a passphrase. Regarding which dictionary to use -- I'm partial to EFF's diceware dictionary list because EFF did some study to figure out what sort of words are easy for people to memorize and type. EFF published a number of word lists with different characteristics:
https://www.eff.org/deeplinks/2016/07/new-wordlists-random-passphrases

[kspearrin]

Thanks. I was looking for the tool used.

[kspearrin]

Hey @zQueal . Thanks for the suggestion! I agree with you and will add this to the backlog of features. I'll have to research the solution to passphrase generation a bit since I am not familiar with how the dictionaries are built.

[zQueal]

One of my favorite examples of passphrase generation done right is OneShallPass by Maxwell Krohn of Keybase. The project is FOSS and his impeccable documentation may help you get some ideas on how to implement. Thanks for being receptive--I look forward to it. 👍

Gonna close because you said you'd add it to the roadmap.

[kspearrin]

@zQueal, Can you explain how you calculated your entropy for that passphrase?

[zQueal]

Calculating password entropy is tricky. There are many different schools of thought that surround it aside from the basic math which is simply log2(A)*B where A is the total pool of possible characters and B is the number of characters used for your password/phrase.

So going strictly on that if you reevaluate the entropy I posted before it would be closer to this (mathematically):

Password:    log2(88)*10 = 64.59
Passphrase: log2(26)*21 = 98.71

I believe that these numbers do not accurately depict the strength of a password/phrase because strict math based entropy calculations do not take into account repetition of characters, common words, phrases or patterns. So to answer your question on how I calculated the entropy values; I used Cygnius password strength tool which leverages zxcvbn and takes all those different things into account during entropy calculation.

[zQueal]

a passphrase is only as strong as the method used to obtain it

This is the same for absolutely everything which deals with random generation. There's no logical way to know with 100% certainty that what you're getting at the end is truly random. Anyone who says differently is lying or is simply steeping in their own ignorance of the subject.

That said, the only reason why passphrase can be better is because in practice there are different word lists out there that makes it harder for a password guesser to really narrow down the dictionary.

This is absolutely poppycock--or at the very least an opinion which has been formulated by experience with passphrase generation done incorrectly.

For specific examples of passphrases done correctly, look to OneShallPass by Maxwell Krohn, PhD--specifically the included passphrase generator.

In the FAQ Max breaks down the configurables based on computing time and the applicable costs it would take to cryptographically compromise the generated passphrases;

If you use the suggested passphrase generation tool, and the default security setting, your password will require in expectation 2^(58+8-1) = 2^65 calls to HMAC-SHA512 to crack. That is, the passphrase generator gives 58 bits of entropy, 1SP's use of PBKDF-2 consumes 2^8 calls to HMAC-SHA512 to turn a passphrase into a derived key, but on average, a cracker only needs to exhaust half of the search space to find your passphrase (hence the 2^(-1) factor). The obvious way to compute HMAC-SHA512 requires two invocations of SHA2, but I have not seen a proof that two are required. So conservatively, assume that one invocation of HMAC- SHA512 is equivalent to one call to SHA2.

The Bitcoin system can help us put a monetary value on the cost of computing a hash. After all, an adversary can either spend cycles mining bitcoins or cracking your passphrase. So cracking your passphrase has a quantifiable opportunity cost.

As of 7 Feb 2013, the Bitcoin difficulty rate is 3,275,465, meaning it takes 2^323275465 hashes on average to get a Bitcoin unit, which is 50 Bitcoins, each of which is worth about $21.75 dollars. So a conservative estimate is that a call to SHA2 costs about 5021.75/(2^32*3275465) dollars, or roughly 2^(-43.6) dollars. So your password will require 2^(65-43.6) or roughly $2.7 million to crack.

If you want better security, you can choose a 5-word passphrase, which conservatively costs about $34 billion to crack.

Keep in mind, this was when the bitcoin difficulty rating was 3.2 million and not its current 422 billion--an increase by a factor of 128889. Meaning the monetary value based on the computing time is in the several hundreds or thousands of trillions (maybe more). Additionally, the mention of bitcoin is only meant to surmise the computational cost vs humanly recognizable computational time. Simple fact of the matter is, is if you had access to that type of computational power you wouldn't be using it to crack passphrases...you'd be using it to make several trillions of dollars by mining bitcoin--so this argument is almost entirely a red herring. Not to advocate for lax password/passphrase standards but in practice this is something you don't particularly have to worry about because we can assume that if someone had the resources for this type of computing power they could already get anything they wanted from you to begin with.

You're free to do whatever you want, but to even so much as imply that passwords are (when generated correctly) in any way superior to passphrases (when generated correctly) is actually insane. Last point of fact, it's far more insecure to reuse a password/passphrase then it is to use a passphrase over a password--which is the entire intent of Bitwarden--and another red herring.

[timdvail]

Wait a minute. You completely misunderstood my point. In no way did I say that a passphrase is weaker than password given same amount of entropy in the generation. All I am saying is for the same length a properly generated password has higher entropy. Meaning if you are limited to 12 characters then random password is better.

[kspearrin]

Being limited by length seems silly but I can't tell you how many times I sign up for websites and am given a password validation rule of 8-15 characters.

[timdvail]

I think I might have misunderstood zQueal altho. 1SP(passphrase) should provided hmac and pbkdf is sound have entropy equal to the lesser of the passphrase and the keyspace entropy times length of password. In another words a 12 character 1SP should be as good as a random 12 character. It is like another password manager in a sense.

[zQueal]

I'm not really here to argue the merits of either. The only important thing is to have the option to employ them vs a password in situations where you feel that they'd be better suited than a password. Which are numerous.

[kspearrin]

We are moving away from tracking Bitwarden feature requests like this one as GitHub issues. We have created a Bitwarden Community Forum which has a section for submitting, voting for, and discussing product feature requests.

Please sign up on our forums, search to see if this request already exists. If so, you can vote for it and contribute to any discussions about it. If not, you can re-create the request there so that it can be properly tracked.

This issue will now be closed. Thanks!