This article is actually about mkpasswd (maybe this should be added to the link title)
For the purpose of creating a new password, I use pwgen -s 16 (parameter s for secure = completely random, length 16). It gives you a couple of random passwords and you choose the one you like best (or a random one). The command has plenty of other useful options.
I’ve always used head -c X /dev/urandom | base64, replacing X with the size. Used to use 16, but when I changed all my passwords after Heartbleed I moved up to 24.
head -c X /dev/urandom | base64
By using base64 you limiting your charset quite a lot. base64 only contains 2 special chars while there are a lot more typeable characters on a keyboard, like ()&^%$#@. ascii85 would be much better.
Does it make much of a difference though? If I take a random 16 bytes and convert it to base64, that should be the same amount of entropy as if I took the same string and encoded it in ascii85. The ascii85 string would be shorter but no less random.
Big picture, I don’t think this matters, but also consider that some fraction of ascii85 strings will be valid base64 strings. A cracker going after all 10 letter base64 passwords will also crack a bunch of ascii85 passwords that coexist in that space. The same random bytes rendered as a 12 byte base64 string would be safe.
All bets are off if there are length limits or truncation, but barring that, I think I’d very slightly prefer longer and simpler over shorter and denser. Longer and denser trumps that, but any password I type on my phone has an upper bound on the complexity I’m willing to tolerate.
Yes, that’s true. I just have a better feeling when I know that the attacker needs to use a larger charset to brute force a password. Maybe it also reduces the likelihood of a hash collision with another string when you use a larger initial charset.
But in essence, you are right: if you don’t need to remember the password and therefor can opt for a longer password, it shouldn’t matter if you use base64 or ascii85.