In practice though you can probably get away with slightly less. For one if the application you use the password with is using PBKDF with iterations, it will stretch the bit strength of the password out. A 19 character random ASCII password has 124.83 bits of entropy giving it a key space of 2^124.83 , if there is a PBKDF with 1,000 iterations the number of hash operations required to exhaust the key space will be 2^124.83 * 1,000 and log2(2^124.83 * 1,000) = 134.79 bit equivalency. An 18 character random ASCII password has a key space of 2^118.26 so with 1,000 PBKDF iterations it is log2(2^118.26 * 1,000) = 128.22 bit equivalency. So if you know the application you are entering your password into has 1,000 or more PBKDF iterations you are actually secure with only an 18 random character ASCII password. Also, totally grammatically correct English prose is estimated to have about 1 bit per byte, but if you type things that you would never read in a book (ie: correct horse battery staple) and use special characters and such (ie: cOrrect h0rse batt3ry s!apl3) then the entropy significantly increases over 1 bit per byte, for the first few characters at least, although it levels off to near 1 bit per byte after many characters. So chances are you don't actually need 128 characters of human readable text, so long as it doesn't look like something you would write in a letter to somebody. Also the PBKDF will come into play for human readable passwords as well, so in the end you wont need quite 128 characters even if it does look like it is out of a letter or book.