> + I understand that the pseudo-randomness of a computer is often accidentally way less random than the programmer thinks. So, the by-hand nature of these pass

> + I understand that the pseudo-randomness of a computer is often accidentally way less random than the programmer thinks. So, the by-hand nature of these passwords seems like an advantage, all else being equal. Right? If /dev/urandom is seededed/used properly, then it will be good enough for passwords. The by-hand method is also good if your dice are fair. > + I thought real words were really bad in a password. Is the idea here that, with six words from these lists, the possible combinations are so great that the trade off is worth it because the password is memorable? That seems suspicious to me because you're essentially giving the cracker the list of possible passwords. Though that list may be quite long, it's still a list. Right? Well, by using only characters (and under a certain length, say 100 chars), you already have a list, so whatever you do, there is a finite number of valid passwords. The 6-word strategy is actually quite good. (I use this method for some passwords). The Arch Linux /usr/share/dict/british has 123398 words. 123398 ^ 6 = 3530601691883345409045950707264 possible passwords log(3530601691883345409045950707264) / log(2) is about 101.5 bits of randomness. Given 86 possible characters and a 14 character password (which you may not be able to remember), there are 1210537694726365245693116416 possibilities, which gives about 90 bits of randomness. > + These can't be better than the 30 character passwords I generate with 1Password, right? Unless there's a bug in 1Password... Maybe that's part of the point. Randomly generated passwords using all characters have a fatal flaw: one cannot easily remember them. If they're just being saved in a password manager, they are good, but you probably want a master password that you can remember, which is a good use case for these.