Between rounds of cooking turkey and all the sides, I made a bunch of updates to my pseudorandom passphrase generator. It still comes up with some interesting things, but now faster. I also got the 'silly rules' feature (upper-lower-number-special) more to my liking. https://passwordhaus.com
I am not responsible for the content of randomly generated phrases. It is a random selection from about 20k words. If you are offended by the results, perhaps explore why entropy offends you.
@tychotithonus This is all server-side because making a client download the word tables would be a heavy bandwidth request. You can select the minimum length of the characters, since that is how they are usually enforced in identity management systems, and if it is less than the minimum, it picks the next word.
I use this same system every time I have to pick a password for something - especially if it is going to be read to someone over the phone who has to type it in. Thus, TLS by default, and no logging - although I do appreciate people sharing screenshots of the funny ones. Feel free to configure it the way you like and use it like an API with GET requests for a plaintext feed of passphrases.
@forensication
I'd still recommend making word-count configurable - 20k4 is only 1017 possibilities, and if the password is hashed poorly (fast hash like MD5 or SHA1), modern GPUs can traverse the entire keyspace in a pretty reachable amount of time. For example, a single 4090 can do SHA1 at 50BH/s, so can crack any single such password in a little over a month:
https://www.wolframalpha.com/input?i=%2820000%5E4%29+%2F+50%2C000%2C000%2C000+%2F+60%2F60%2F24
... and you can rent a 14x 4090 system on Vast.ai for $8/hour, which means that the password can be cracked for $500 in 2.6 days. Adding one more word turns that 2.6 days into 142 years.
And client-side should be a design goal if anyone's going to use it for real passwords, IMO. There are also ways to mitigate the size of the download - see
https://atoponce.github.io/webpassgen/
https://github.com/atoponce/webpassgen
@tychotithonus The length option goes up to 256, and I debated "words" vs. "characters," ultimately choosing characters as the minimum length. The prevalence of adjacent short words in English phrases was a big problem early on, and I wanted to avoid something like "so to be a" as a passphrase and enforce length above complexity.
I suppose I could increase the maximum length. 🤔
@forensication Ah - so the keyspace impact wouldn't be as significant (but would be non-zero, unless your wordlist is curated to be full of long-ish words?)
(I don't mean to pendant you to death - I just find this stuff fascinating!)
@tychotithonus I'm right there with you. This all started with the need to create passwords that are easy for humans to use and remember but awful for computers to crack, but also easy to get someone on the other end of the phone to type in and decrypt that hard drive I sent them.
I doubt anyone will easily remember "2NYnCFBv4FD!" without a good deal of mental gymnastics, but "biker shouted our authenticity" will hold in your short-term memory long enough to type it in without any issues - and will probably be stuck in your head after a few uses. The funny ones seem to be the most memorable.
Like every other password, this requires that the system storing the password is not doing bad things and the attacker does not know something about how your password is selected.
Even if the attacker knows someone used Passwordhaus with the defaults, they would need to guess the ever-evolving ~20k word list and start assembling phrases from the words to make phrases at least 25 characters long.
Two long words, if the attacker knows that much, is not a great keyspace at 4*10^8, but typically, I see four words at 1.6*10^17 and five words at 3.2*10^21 while still being easy to remember and type.
By comparison, if the attacker knows nothing and is just trying to crack hashes, the 25-character default results in at least 6*10^35 possible combinations for them to attack. It's probably safe enough not to lose sleep worrying about brute-force attacks for now.
@forensication I'm tracking up until the last sentence. :D
Just like in other crypto arenas, we have to apply Kerkhoffs' Principle - that the attacker knows everything about the system except the actual secret. So we have to set the lower bound on the security properties of the system on the actual total number of possibilities, assuming the attacker knows the dictionary and how many words.
And I say this not just theoretically, but as someone who has cracked literally hundreds of millions of real-world passwords, including those using "modest" / "good enough" passphrase parameters.
In other words: we crack passwords like these all the time.
@forensication Well, any uneasiness about disclosing the methodology components is a classic 'tell' that there's an opportunity for improvement relative to alignment with Kerkhoffs'. But I suspect that's where we'll have to agree to disagree, then. :D
(Don't get me wrong, though - a 1017 passphrase is a significant improvement over human-generated passwords!)
J-Michael Roberts 
Royce Williams