github-starred/android
2
0
Fork 0
mirror of https://github.com/bitwarden/android.git synced 2026-03-09 11:44:41 -05:00
Code Issues 144 Packages Projects Releases 116 Wiki Activity

Passphrase Generation #14

New Issue
Closed
opened 2025-11-07 08:22:52 -06:00 by GiteaMirror · 13 comments
GiteaMirror commented 2025-11-07 08:22:52 -06:00
Owner
Copy Link

Originally created by @zQueal on GitHub (Nov 22, 2016).

Password creation is all well and good, however, there are many of us who wholly believe that passphrases are cryptographically stronger than a "randomly" generated password. Are there any plans for passphrase to be implemented? If not, I'd like to ask that it be thrown into the roadmap.

A simple comparison shows the passphrase strength vs a traditional password.

Type Test Entropy
Password oI8&Yd8H4A 46.264
Passphrase murals coddle baiting 59.277

Despite being far easier to remember, the passphrase has a higher base entropy than a default password generated by bitwarden.

Originally created by @zQueal on GitHub (Nov 22, 2016). Password creation is all well and good, however, there are many of us who wholly believe that passphrases are cryptographically stronger than a "randomly" generated password. Are there any plans for passphrase to be implemented? If not, I'd like to ask that it be thrown into the roadmap. A simple comparison shows the passphrase strength vs a traditional password. | Type | Test | Entropy | | ---------- | --------------------- | ------- | | Password | oI8&Yd8H4A | 46.264 | | Passphrase | murals coddle baiting | 59.277 | Despite being far easier to remember, the passphrase has a higher base entropy than a default password generated by bitwarden.
GiteaMirror added the enhancement label 2025-11-07 08:22:52 -06:00
GiteaMirror commented 2025-11-07 08:22:52 -06:00
Author
Owner
Copy Link

@kspearrin commented on GitHub (Nov 22, 2016):

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.

@kspearrin commented on GitHub (Nov 22, 2016): 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.
GiteaMirror commented 2025-11-07 08:22:53 -06:00
Author
Owner
Copy Link

@zQueal commented on GitHub (Nov 22, 2016):

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.

@zQueal commented on GitHub (Nov 22, 2016): One of my favorite examples of passphrase generation done right is [OneShallPass](https://github.com/maxtaco/oneshallpass) by [Maxwell Krohn](https://github.com/maxtaco) of [Keybase](https://keybase.io/). 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. :+1: ~~Gonna close because you said you'd add it to the roadmap.~~
GiteaMirror commented 2025-11-07 08:22:53 -06:00
Author
Owner
Copy Link

@kspearrin commented on GitHub (Nov 22, 2016):

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

@kspearrin commented on GitHub (Nov 22, 2016): I'll keep this open since this is how I manage the roadmap.
GiteaMirror commented 2025-11-07 08:22:53 -06:00
Author
Owner
Copy Link

@kspearrin commented on GitHub (Nov 23, 2016):

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

@kspearrin commented on GitHub (Nov 23, 2016): @zQueal, Can you explain how you calculated your entropy for that passphrase?
GiteaMirror commented 2025-11-07 08:22:53 -06:00
Author
Owner
Copy Link

@zQueal commented on GitHub (Nov 23, 2016):

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 commented on GitHub (Nov 23, 2016): 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](https://apps.cygnius.net/passtest/) which leverages [zxcvbn](https://blogs.dropbox.com/tech/2012/04/zxcvbn-realistic-password-strength-estimation/) and takes all those different things into account during entropy calculation.
GiteaMirror commented 2025-11-07 08:22:53 -06:00
Author
Owner
Copy Link

@kspearrin commented on GitHub (Nov 23, 2016):

Thanks. I was looking for the tool used.

@kspearrin commented on GitHub (Nov 23, 2016): Thanks. I was looking for the tool used.
GiteaMirror commented 2025-11-07 08:22:53 -06:00
Author
Owner
Copy Link

@timdvail commented on GitHub (Feb 10, 2017):

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

@timdvail commented on GitHub (Feb 10, 2017): 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
GiteaMirror commented 2025-11-07 08:22:54 -06:00
Author
Owner
Copy Link

@zQueal commented on GitHub (Feb 10, 2017):

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.

@zQueal commented on GitHub (Feb 10, 2017): > 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](https://github.com/maxtaco/oneshallpass) by Maxwell Krohn, PhD--specifically the included [passphrase generator](https://oneshallpass.com/pp.html). 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.
GiteaMirror commented 2025-11-07 08:22:54 -06:00
Author
Owner
Copy Link

@timdvail commented on GitHub (Feb 10, 2017):

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.

@timdvail commented on GitHub (Feb 10, 2017): 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.
GiteaMirror commented 2025-11-07 08:22:54 -06:00
Author
Owner
Copy Link

@kspearrin commented on GitHub (Feb 10, 2017):

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.

@kspearrin commented on GitHub (Feb 10, 2017): 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.
GiteaMirror commented 2025-11-07 08:22:55 -06:00
Author
Owner
Copy Link

@timdvail commented on GitHub (Feb 10, 2017):

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.

@timdvail commented on GitHub (Feb 10, 2017): 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.
GiteaMirror commented 2025-11-07 08:22:55 -06:00
Author
Owner
Copy Link

@zQueal commented on GitHub (Feb 11, 2017):

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.

@zQueal commented on GitHub (Feb 11, 2017): 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.
GiteaMirror commented 2025-11-07 08:22:55 -06:00
Author
Owner
Copy Link

@kspearrin commented on GitHub (Mar 9, 2018):

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!

@kspearrin commented on GitHub (Mar 9, 2018): We are moving away from tracking Bitwarden feature requests like this one as GitHub issues. We have created a [Bitwarden Community Forum](https://community.bitwarden.com) which has a section for submitting, voting for, and discussing product [feature requests](https://community.bitwarden.com/c/feature-requests). Please [sign up on our forums](https://community.bitwarden.com/signup), 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!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
app:authenticator
app:password-manager
bug
bug-passkey
customer-support
duplicate
enhancement
good first issue
help wanted
needs-reply
needs-response
pull-request
Mirrored from GitHub Pull Request
 question
No Label enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/android#14
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?