danstiner / password-generator Goto Github PK

I often find myself refreshing a couple times to find a password I like. In the worst case this means losing one bit of entropy per refresh.

Instead showing a few suggestions at once would lose less entropy. An odd number would be best as it gives an obvious choice if you are in a hurry, the middlemost one. So three or five suggestions seems like a good number.

To give exact numbers, assuming I look at five suggestions before picking one:

• Refreshing five times would lose 5 bits of entropy worst case
• Showing all five to begin with would lose about 2.3 bits of entropy, much more reasonable.

Currently symbols are chosen from an alphabet by just modding a uin32 down to the length of the alphabet, this can introduce bias for non-power-of-two alphabet sizes of about 2^-32 - 2^-log2(|alphabet|) or about 1/2^21 for a wordlist with about two thousand words. This is small but not entirely negligible and should be fixed.

Relevant reference: https://stackoverflow.com/questions/137783/expand-a-random-range-from-1-5-to-1-7

Removing bootstrap and replacing it with a small amount of custom CSS will be easier to audit.

This has always been the goal of the project: to generate passwords that are short, secure, and easy to remember. This is assisted by generating a corresponding passphrase that helps with remembering the password (by being a mnemonic device) (and is just as secure by being one-to-one with the password).

This is largely inspired by the Schneier scheme, but focused on having enough entropy to resist attacks over having a form of password that would not be tested by a brute force algorithm. So the threat model and entropy estimate assume a worst case of the attacker knowing the generation algorithm used and thus the form of the password.

I spent a long time thinking about this before coming to the realization that it can be done (while maintaining the one-to-one mapping) by simply applying lossless compression to the passphrase to derive a much shorter password. One decent method using prefix codes. Build a trie from all word alternatives and then use the prefix for the randomly chosen word. This forms a uniquely decodable code which ensures password to passphrase is one-to-one. And since they are prefixes, they make decent mnemonics. This can be further enhanced by first applying a mapping that reduces prefix collisions (say mapping "seven" to "7"), leading to shorter passwords.

Diceware and other wordlists already have generation methods, better to aim for a single "best" word generation algorithm than to support multiple.

Currently wordlists are loaded as a javascript file, this is simple but requires trusting some bad javascript is not hiding in the middle of a massive file. It would be easier to audit if they were stored as a JSON file and loaded via XMLHttpRequest