A password generator inspired by the Xkcd password spec | Hacker News Reader

A password generator inspired by the Xkcd password spec

github.com

31 pointskeepamovin61 comments

The code is overcomplicated and somewhat rough for what it does. Python docs has 4 line snippet that you just copypaste if you need:

    import secrets
    # On standard Linux systems, use a convenient dictionary file.
    # Other platforms may need to provide their own word-list.
    with open('/usr/share/dict/words') as f:
        words = [word.strip() for word in f]
        password = ' '.join(secrets.choice(words) for i in range(4))

https://docs.python.org/3/library/secrets.html#recipes-and-b...

Also EFF had prepared convenient wordlists specifically for password generation: https://www.eff.org/deeplinks/2016/07/new-wordlists-random-p...

For truly paranoid, 1password has an 18328-word password list:

https://raw.githubusercontent.com/agilebits/crackme/refs/hea...

which is what their own generator uses, I think.

If you're using four words, it gives you (18328⁴ / 7776⁴ ≈ 30.86) times larger space over EFF's list.

I love how several comments have turned this into code golf :D. There's another comment that shows a shell oneliner using the word dictionary.

Yeah, the code looks like it was written by a Java programmer writing Python code.

I love diceware passwords, they’re the perfect way to keep things secure while allowing you to type them on a TV app, for example. Nice to use for the master password of your password manager too, since you can remember a very long one.

I wrote a Go package[1] that generates them (and random ones too) a while ago and also compiled a word list with about 23 thousand words[2]. I had it reviewed by a third-party, and, it seems, bias wasn’t introduced in the generation. There is a CLI app[3] using the package, if anyone is interested in something written in Go instead of Python for whatever reason.

[1]: https://git.sr.ht/~jamesponddotco/acopw-go

[2]: https://git.sr.ht/~jamesponddotco/acopw-go/blob/trunk/words/...

[3]: https://git.sr.ht/~jamesponddotco/acopw-cli

Sadly most websites will scream at you if you don't follow their weird and sometimes arbitrary recipe (exactly one special character). This is great for when it's actually allowed

I usually just add a standard set of numbers and special characters at the end of an otherwise secure password to appease the complexity gods.

P@55w0rd --- excellent

wriggler-airborne-genealogy-wainscotings --- awful

I hate how they connect those words, i much prefer the random choices that i can get from 1Password: WRIGGLER$airborne2GENEALOGY!wainscotings

Now, i have had several sites that i cant accept passwords longer then 16 or 20 characters so i have to return to P@55w0rd like passwords (random, not work based).

I stumbled upon a few sites which have slightly different rules on registration page comparing to login. On registration page the password is length limited and they cut off the excess without saying. But on login page they don't do that so the password you pasted no longer works

You're falling for the same errors that xkcd pointed out in the first place.

Adding different connectors and different cases adds a lot more to remember and hardly any extra entropy

I used to do that too, capitalizing the first letter and appending 1.

Anecdote time!

Some years ago I had a password on an account that contained a space character. One day, out of the blue, couldn’t log in. Went through the reset flow, picked another password that also happened to contain a space, still couldn’t log in.

I started poking at it and realized that I had to enter the space as `+` at the login form. It worked that way. I never quite figured out what they would’ve had to do to get the form encoding so specifically wrong.

Since then, I’ve tried to carefully consider just how “special” I want my special characters to be.

I assume the browser encoded the space to + with x-www-form-urlencoded, then the server never decoded it.

https://en.wikipedia.org/wiki/Percent-encoding#The_applicati...

I've had long form passwords cut short without informing me at all until I failed the account creation, login and password reset multiple times. I counted every character that was displayed during password creation and matched it exactly with what I've entered only to find out the login portal cut my password by one character.

It did give me inspiration for another infuriating username ^

Yup, add my version to the fifty others in the comments! Think mine is the first Perl version in the comments though :-)

https://github.com/david-loffredo/makepw

For some reason, John Siracusa comes to mind when I hear someone mention writing in Perl.

14 years ago? Time flies.

(I should update my own similarly inspired but different generator, given it is no longer compatible with current default python: https://github.com/BenWheatley/HighEntropyPassword/blob/mast...)

I've been using a similar diceware generator for years. I think I learned about it from Cryptonomicon?

Consider adding the following options:

    -include-captital (default yes)
    -include-lower (default yes)
    -include-symbol (default yes)
    -include-number (default yes)
    -min-length (default 8? not sure the common limit)

How you implement these would be up to you. For my part, I generate a password and then transform it according to the options, trying to keep the spirit of diceware (as needed -- your generated pw may satisfy the options by chance, depending on the dictionary). E.g, capitalize the first letter, lower-case the last letter, (or prepend A or append z, if there aren't enough letters), put - between first and second word, transform certain vowels to numbers, that sort of thing. There are some subtleties to min-length.

While this is fine advice for a generalised password generator, this isn't the point of the linked XKCD comic nor the objective of the post.

That is, the complexity of a password increases exponentially based on length, not so much character set. That is, the number of possibilities is squared if in your list of parameters the min-length goes from 8 to 9, changing the character set does not have as dramatic an effect.

> nor the objective of the post

I wouldn't know, I just assumed of the objective is to create a useful password generator.

These options aren't for increased entropy, but to satisfy restrictions real-world sites have on passwords.

(In fact, you want to be a little careful about how these are implemented to avoid/minimize the loss of entropy. It's a minor irony that these restrictions, intended to lead to stronger passwords, can result in weaker ones.)

Yeah, but websites still have asinine requirements. So at least enforcing uppercase, numbers, and symbols, is useful. It doesn’t make your password significantly better, but it allows you to sign up in the first place.

I agree that min length is probably not relevant here though.

In Linux (with the necessary packages) this shell oneliner can more or less do the same.

    shuf -n 5 /usr/share/dict/words

That dictionary normally has a lot of rather obscure/long/hard to remember stuff. If you 'reroll' until you get a password you like better you're taking an unknown hit to the entropy of the results.

It's better to use a dictionary where every word is acceptable and commit yourself to taking the first result or best of two (confining the human-selection entropy loss).

Though I don't have any suggestion for a suitable one that is just a wget away.

> Though I don't have any suggestion for a suitable one that is just a wget away.

EFF wordlists: https://www.eff.org/deeplinks/2016/07/new-wordlists-random-p...

This can be improved by using a better entropy source.

  shuf -n 5 --random-source /dev/urandom /usr/share/dict/words | paste -sd ' '

Nice! But on Darwin I need to do:

  shuf -n 5 --random-source /dev/urandom /usr/share/dict/words | tr '\n' ' '

As paste complains about working with a pipe

Shameless plug: I've written a webpage that does something similar: https://correcthorse.org

Uniquely, it uses no tracking, tries to use as few JS as possible and works completely offline. :)

Years ago I wrote one in ~50 lines of C using a wordlist of short, simple english, words:

https://gitlab.com/trobador/sdice

30 lines of C :)

https://github.com/zokier/pw/blob/master/pw.c

It's one of those things that are easier to write yourself than going through gazillion alternatives to find a good one.

I made one of these a while ago

https://github.com/scottmsul/Password-Generator

1password, at least, has had this for almost a decade.

So does Bitwarden, and most other password managers. It's a convenient format, nor just for remembering but also for typing it in when autofill and copy-paste aren't available (like on a different device)

Bitwarden also has this

last commit: 8 years ago.

First commit: 14 years ago

Sometimes the 'old' ways are the best

This never made sense to me, assuming that using common words is more secure than random characters. To a computer it doesn’t matter if you’re using random characters or a group of words, it’s all a matter of guessing from a pool of characters. So “energic bicycle stamp” is less safe than “3nerg1c bicycll3 st4mp!” because the latter uses a larger pool of characters than the former.

The figure of merit is security vs memorability.

You could imagine two different passwords machine generated with the same entropy under plausible selection schemes: some w$#J8fe keysplat or the selection of 5 words from a dictionary of common words. Both would be equally secure against a password guessing attacker, but the common word one would be easier for most people to remember.

If you held memorability constant, the character-splat password would be less secure.

You could imagine a hybrid, but the one you demonstrate is the kind that humans construct on their own where some characters are replaced with lookalike symbols-- these sorts of adhoc schemes are well modeled by replacement rulesets and markov-model password guessing algorithms and don't tend to add a ton of entropy. They do hurt memorability a fair bit and the better done (from a security perspective) the worse the hit on memorability.

The comic's author would probably argue just adding an extra word is better from a security and memorability perspective, or at least I argue that. :)

But more safe than "ebs" or "Q!5", or longer strings up to a point. The words are standing in for characters, and the pool of words is very large.

The dictionaries used by dictionary attacks usually have leetspeek words in them, so it doesn't matter much.

> So “energic bicycle stamp” is less safe than “3nerg1c bicycll3 st4mp!” because the latter uses a larger pool of characters than the former.

The whole point of xkcd/diceware style passphrases is to expand the pool. The traditional random password uses something like 96 symbol pool (printable ascii), while passphrases use a pool of thousands of symbols (length of wordlist). That is where their strength comes from.

log2(7776^5) ~= log2(96^10) ~= 64 bits

The XKCD comic assumes the attacker has 1000 guesses per second, but a single GPU box on a stolen hash can easily hit a couple billion guesses per second. So the security model of the comic is extremely optimistic compared to some completely reasonable and common threat models.

Fortunately the readme on the target page appears to show the tool defaulting to passwords of considerably higher security than demonstrated in the comic which ought to provide reasonable security under a broader set of attack models.

You've got to remember that this comic came out at a time when password managers were not extremely common, and the general consensus for a "good" password looked something like this: X8woi$SD

The big thing (in my opinion) that the comic gets wrong, and that all implementations of the password spec follow, is that if an attacker has reason to assume you might be using this style of password, then each word sort of becomes a single "character," albeit from a much larger list of possible characters. But if you introduce some random numbers or special characters into the words, it's still easy to remember and type, but becomes much more difficult to crack.

> it's still easy to remember and type

I think the "ah-ha" moment for me was realising that I needed neither to be able to remember nor to type my passwords.

Once that happens, passwords like 5Ze2vz7AdDjWbXXq start to look great rather than awful :)

That is a much better password, but there are occasions where you need to type a password. For instance, bootstrapping a new device that doesn't have your password manager installed already.

> there are occasions where you need to type a password. For instance, bootstrapping a new device that doesn't have your password manager installed already

Right, but the whole point is that the (hopefully) one-time pain of doing this is worth it in the long run.

> introduce some random numbers or special characters into the words, it's still easy to remember and type

If you ask users to do so themselves they tend to do so in extremely predictable ways that add l1ttle entropy!

If you do it automatically and in a way that has high entropy the result is a lot less memorable.

Probably just adding an additional word adds more entropy at less memorability cost.

>If you do it automatically and in a way that has high entropy the result is a lot less memorable.

I find it just as easy to remember correcthor_sebatTerystaple, and it effectively changes the attack from guessing which four words were used from a well known dictionary.

Attackers have made extremely good models of mangling that humans perform on passwords, so this kind of change just adds whatever bits of entropy there are in your selection of mangling approaches. It's almost certainly less than you think.

It might help to understand what people have done here: There have been absolutely gigantic plaintext password leaks. Armed with plaintext passwords and collections of very good 'dictionaries' (might not actually be dictionaries) attackers design rules to turn the dictionary into as many passwords as possible without duplication.

> The big thing (in my opinion) that the comic gets wrong, and that all implementations of the password spec follow, is that if an attacker has reason to assume you might be using this style of password, then each word sort of becomes a single "character," albeit from a much larger list of possible characters.

Why you think that is "wrong"? It's the whole idea behind passphrases to consider each word as a symbol, and it's also what the xkcd entropy calculation is based on.

From the comic:

> (Plausible attack on a weak remote web service. Yes, cracking a stolen hash is faster, but it's not what the average user should worry about.)

And he's right (if you don't trust the website to hash the password securely, then you should assume your password is stored in plain text anyway)

I do credit the comic with being consistent with its own security model-- but attackers having stolen a password database is extremely common (was then too)... and the stakes that users face has also involved in the time since the comic was written.

E.g. I've seen people get burned using the comics advice for "brainwallets", which is equivalent to having a published unsalted hash.

It's okay to have a confined security model, so long as you understand that's what you're doing. But users usually lack any real ability to gauge how likely password hashes are to leak just due to lack of information on how the sites operate. I think a better justification of the comic's original security level is that it's sufficient for protecting things where a compromise is only a nuisance, as is usually the case for 'random website'. But that isn't true for all password choices people make.

The only places I use 6 phrase diceware passwords ((6^5)^6 combinations) is FDE. I control the KDF and configure it to take at least a second on the host I am using FDE on. Even if you take these modern KDFs and find a way to do them 1000000 times faster, thats still an average of 3.5 billion years to crack (assuming you know i used diceware, know my word list, and know how I have formatted the password).

I think I'll be fine.

Also, I use real dice.

Let me know if I calculated that wrong. The calculation was: (6^5)^6 / 1000000 / 2 / 60 / 60 / 24 / 365

The constants:

6 - sides on a D6

5 - dice per phrase

6 - phrases

1000000 - checked passwords per second (super optimistic, unrealistic hardware, outside even government reach)

2 - half way through a hypothetical dictionary attack

60 - seconds per minute

60 - minutes per hour

24 - hours per day

365 - days per year

The comic was published on August 10, 2011 ;-)

By your numbers, Tr0ub4dor&3 will be decoded instantly but the xkcd one will still take hours

macOS Keychain used to have a password generator similar when you chose the "memorable" option. Back when it was OS X instead of macOS.

It only did two words and would sometimes include a number or symbol.

I like this because it’s like having 1Password at home.

A note that if you have "uv" installed you can execute arbitrary python packages with the "uvx" command without needing to clone a repo:

    uvx --from git+https://github.com/beala/xkcd-password xkpa -h

Security risk?

Its nice that they have a spec.

Since my xkcd email address has been one of my main sources of spam over the years, it's clear the site has been cracked repeatedly...

Reply on news.ycombinator.com