Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Increase example-seed-data.json list to 4096 words #14
This helps the user in two ways:
Using this word list, this is the amount of entropy you get in the passphrase as a result:
This word list is a sorted list of the most common 4,096 English words that are either 4, 5, or 6 characters in length. This will help minimize the number of characters in the passphrase, without compromising entropy.
Example 4-word passphrases:
Example 5-word passphrases:
Example 6-word passphrases:
This helps the user in two ways: 1. It provides exactly 12-bits of entropy per word (2^12 = 4096) if they want to use this as their word list. 2. It helps encourage users to deploy large word lists for increasing security. Using this word list, this is the amount of entropy you get in the passphrase as a result: * 4 words: 48-bits (weak) * 5 words: 60-bits (medium) * 6 words: 72-bits (strong) This word list is a sorted list of the most common 4,096 English words that are either 4, 5, or 6 characters in length. This will help minimize the number of characters in the passphrase, without compromising entropy. Example 4-word passphrases: * trade-what-senior-used (22 characters) * shack-drugs-curse-tables (23 characters) * write-faint-winner-alvin (23 characters) Example 5-word passphrases: * memory-ichi-iove-olive-arms (27 characters) * fate-angus-enemy-parent-writes (30 characters) * nigel-serial-site-bomb-bait (27 characters) Example 6-word passphrases: * rays-buys-brings-marc-tribe-trust (33 characters) * foot-snakes-bags-this-eighty-sylvia (35 characters) * marco-arms-dusty-route-stayed-vest (34 characters)
With example-seed-data.json now 4096 words in length, if that is used for the word list, then 12-bits of entropy are provided for each word. This increases the entropy of the system to 72-bits, which is considered secure. To motivate this, considered the following scenarios: 1. The Bitcoin mining network, using specially designed ASICs is brute-forcing SHA-256 hashes. The current pace is [7,430,760.76 TH/s](https://blockchain.info/stats). That's about 7.5x10^18 SHA-256 hashes, or every combination in 62-bits calculated every second. It takes the Bitcoin mining network just under an hour to calculate every combination of 74-bits. 2. The distributed.net distributed computing project is working on cracking a [72-bit RC5 key](https://stats.distributed.net/projects.php?project_id=8). The sustained rate is around 800 million keys per second, or calculating all of 29-bits each second. At that pace, they can only reach 54-bits per year, which means it would take them around 130 thousand years at that pace to reach 50% of the key space, thus having the probability of at least 50% of finding the right key. 3. Recently, Troy Hunt released 320 million password hashes to the Internet. A group of password crackers armed with MDXfind and Hashcat set to work. At peak, they were [calculating 180 billion hashes per second](https://cynosureprime.blogspot.com/2017/08/320-million-hashes-exposed.html). That's 27-bits per second, 52-bits per year, and around 500 thousand years to reach 71% (half the size of 72-bits). I think it's fair to say that the Bitcoin mining power is at the very cusp of what several well-funded state adversaries could afford in a targeted attack. The rate of distributed.net looking for the 72-bit RC5 key or a cluster of 25 Nvidia GPUs is much more realistic for password cracking. As such, 48-bits is well within reach of full compromise, 60-bits offers a small margin of security, while 72-bits is clearly out of range for the time being. As such, it's considered best practice for password generators to be generating passwords with at least 70-bits of entropy.
First, thanks for taking the time to check out my project. I like the two suggestions and would like to incorporate them in different ways. I need to write more about the motivation for this project and what it is trying to provide (maybe this comment is the first step). What exists today is a basic web service that leans entirely on Dropbox's zxcvbn and a hash store to generate strong, unique passphrases based on a provided set of words at start time. Going forward, I want to provide more customization points so people can easily run their own instances.
The set of words included as an example are just CSS color names which is a short, familiar, easily-exhaustible list making it easy to develop with and peering over. I'd like to create a directory of example word lists and encourage people to provide more. Maybe one day people could select a few lists to mash together and launch a custom instance.
Passphrase length is high on my list to allow for customization. People who want more secure instances could set it on startup or even allow customization per request. At passplum.com, I'm still trying to convince people that
So a couple things come to mind. First is that zxcvbn is a blind entropy guess. It doesn't know what set you're pulling from when creating the password, so it uses a lot of mathematics and heuristics to try and figure it out as best as it can. However, when you know what site your set is, and what elements are part of it, then you can calculate the entropy yourself. You don't need zxcvbn to do that. The goal of zxcvbn is to provide a sort of strength meter for sites support account creation, and giving feedback to the user about the quality of their password.
So, when you know your set size is 4,096 elements, and you know you're grabbing from the set randomly, then you know you are getting 13-bits of entropy per word. You don't want to rely on zxcvbn when generating the passphrases. As some examples, each of these have exactly 78-bits of entropy, but zxcvbn thinks they each have (without spaces):
Further, making the word list public doesn't compromise security, when the default passphrase length is providing enough entropy. In this case, the attacker would need to generate 40966 = 4,722,366,482,869,645,213,696 passphrases, which is outside of the practical realm (as already initially posted).
Second, you don't need to mention anything about entropy to the front-end. Just give them the password. Users should only have to copy-paste it into the password manager, form field, text editor, etc.
I like relying on zxcvbn's "very unguessable" score and leveraging all that's gone into that project. Again, my goal is to get more people from
I'm open to adding additional strength measurement options as long as zxcvbn is left as the default.