Why Steve Gibson's Password Padding Works for Humans
Eric GerlachI just finished listening to Security Now Episode 303, in which Steve Gibson talks about his concept of password haystacks. The idea is that rather than making strong passwords in a purely theoretical sense, you design them to resist nearly all possible attacks.
I recommend you go and read Steve's page on the topic or listen to the podcast, as it really is a good idea, one which I will implement in a few key places after writing this post. In fact, you should read it right now because I'm assuming knowledge of the concept. There's two reasons that password padding works for us: one psychological, and one computer scientific. As a Computer/Cognitive Scientist, password usability is something I've taken a stab at before, and I'll even show you my implementation, but Steve's is even better, and I'll explain why.
Before I begin, I'd like to point out that Steve's reasoning about password padding is completely correct. Without any knowledge of the pattern you use to create a password, it absolutely forces an attacker to brute-force your password, at which point (alphabet size)^length is your friend. So we're going to take it as a given that the passwords are strong against attacks. What I'd like to focus on is why are they better for us as humans than 8, 10, or 12 characters of random gibberish.
Let's start with a discussion of the psychological. It has been known for 50 years that memory stores things in "chunks." For example, if I gave you the following list of letters: F-R-G-T-H-I-O-F-W-C-A-Q-N-M-F-K-I-P, and then took it away and asked you to repeat it, the research suggests that you'd be able to get about 7 letters in a row right, plus or minus 2. However, if I gave you this list A-B-C-Q-R-S-E-F-G-L-M-N-X-Y-Z-I-J-K you'd probably do much better because your brain is able to break it into six chunks of three consecutive letters each.
It's immediately obvious to see how chunking helps you remember a long, padded password. You only have to remember a word and a few algorithmic steps to remember the password, instead of all 25 characters (for example).
But there's lots of techniques like this. In fact, it was chunking that inspired my old password generation technique1 (no longer in use since I started using LastPass): Take 2 random words between 5 and 8 characters, and 2 random other characters. Arrange them randomly. Randomly capitalise one of the letters. It creates passwords of between 12 and 18 characters, but you only have to remember 5 chunks (2 words, 2 symbols, and where the capital letter is). Much easier, but very strong nonetheless.
I begin the Computer Science side of this post with an anecdote: Let's say I flipped a coin 1000 times, and it came up heads every single time. You'd probably look to see if the coin was rigged, because "What are the chances of that?" Actually, the chances are exactly the same as any other possible outcome, but for some reason we humans regard this outcome as special. Why is that?
In computer science, particularly formal languages theory 2, there's a concept known as Kolmogorov Complexity. Roughly speaking, the Kolmogorov Complexity of a string is the size (number of bits) in the shortest program that will print the string (the language used is provably irrelevant, no input allowed).
So what does this mean? Well, I can write a program that spits out 1000 heads in a row easily:
1000.times { |x| print 'H' }
But a program that printed a more complex string like 'HTTHTHTHHTHHHTHTTHTHHTHHHTHHHTHHHTHTHHHTHHTHTHHHT...' (imagine 1000 characters of that) would be considerably longer, and maybe the shortest possible program is:
print 'HTTHTHTHHTHHHTHTTHTHHTHHHTHHHTHHHTHTHHHTHHTHTHHHT...'
That's why we see 1000 heads in a row as special: its Kolmogorov Complexity is low. As you can imagine, this concept has huge implications in several fields such as the compressibility of strings.
When Steve and Leo were discussing ways to pad your password out on the podcast, they were choosing algorithmic steps that were "Kolmogorov-ically simple", such as adding 20 dots, or surrounding it with parentheses and six dashes. All of those steps are simple enough that our brains can store them into a single chunk.
But that's the cool part: you can express any length string with a "chunk-able" algorithm step, whereas the length you can express by using words as your chunks is limited by your vocabulary. Since we have a limited number of chunks that we can store, algorithmic steps can lead to longer passwords than words.
That's why the system Steve came up with is demonstrably better than the one I came up with. Both of our systems force an attacker into brute-force mode, but in mine the length of the password is limited by the length of words. With Steve's password padding, you can get much longer passwords, and in a brute force attack increasing alphabet size and length are the only things that matter.
1: It's not secure, so don't use it to get real passwords, it's just there as a demo.
2: I'd like to give a shoutout to my Formal Languages and Parsing prof, Jeffrey Shallit. His course was incredibly difficult, but he taught me a lot of stuff that is now part of my intuitive understanding of computer science. I can't remember a single theorem from the course, but I understand computing a lot better.
Reader Comments (24)
Steve bases the amount of time it would take to brute-force an online password on a formula of 1,000 tries a second. Sorry, but sites like Yahoo mail and Facebook give you THREE TRIES IN A ROW and then shut you down for a period of time. This really makes the discussion Moot when using anything but the top 100 most used passwords.
Brainiac is right, of course, for all the cases where the passwords are only available online under the control of a program designed by a competent and security conscious programmer. The case where a complex password is needed is the one where a hacker manages to get the data file which contains the password hash. In that case, the hacker can then use a custom program running in a GPU (for example) to search for a password that corresponds with each hash.
One might say "but that never happens". One would then be wrong. Just recently a database of passwords from a Yahoo site was stolen and revealed to the world. In this case, though, the passwords were not hashed or encrypted. If the passwords had been properly hashed, we would enter the situation we are protecting against: where the password hash is available to a hacker, who can try each possible password with only the power of her computer's CPU or GPU holding her back. No "fail after three tries", or warning messages sent to administrators.
It comes down, in the end, to an analysis of risk. Yahoo's password databases are hacked very infrequently. If you want the risk to go to 0, you need to anticipate that a site might be hacked that way (along with other very small risks); but if you are okay with an extremely small risk greater than 0, maybe the ability to remember a password is more important than the risk that the password hash would be available to a hacker who could try every possible combination of characters.
This would, of course, be moot for a site that used a "one time password" scheme of some sort, instead of a password that is reusable.
"Without any knowledge of the pattern you use to create a password, it absolutely forces an attacker to brute-force your password," This is the huge weakness of password padding. Sure, for a hacker in a remote country trying to steal your credit card information, a padded password is extremely strong. But what if it is a co-worker who is angry with you and trying to sabotoge you? If you use D0G.......................... (the password recommended as strong by Steve, It would not be hard at all for someone who happens to be around when you type it in to figure out that you are using D0g plus a bunch of periods. At that point, they can probably get your password in less than 15 tries. A password needs to be secure from all attacks. Steve and Eric seem to be unaware that "shoulder surfing" is a method of password attack.
Steve was just pointing out that computers using brute force methods have more trouble getting the dog password than the seemingly more difficult one in the example. The second one was only more difficult to remember, not to crack.
Steve and Eric are not recommending that specific method of padding, just that you use one. Steve specifically says to invent your own. The option of using multiple words is still there, you could use symbols and numbers before, after and between them to pad it out, whatever. Just as long as it makes your password longer without making it harder for you to remember. Once you have invented your own padding method and become familiar with it, it's much easier to create secure passwords that are easy to memorise. Making it harder for a human being to remember doesn't make it harder for a computer to crack. Making it longer does. That, I believe, is the whole point they are trying to make here.
If this gets popular, then cracking algorithms will begin checking for padding earlier in their search parameters. First single character padding, then multiple character padding. Also, not all symbols are alike. The exclamation point is a common symbol added to passwords. It's also the first symbol character in ASCII order. If they are brute forcing it, a password with an exclamation point will be found earlier in the rotation.
Sorry, but Steve's password padding scheme is security-through-obscurity at best.
If it becomes common practice to pad with repeated characters or patterns then a password-cracking program will simply be designed to test all passwords of that form before being "forced into" full "brute force mode" where it test *arbitrary* random sequences. Sure there are a lot of possible such paddings, but there are many, many orders of magnitude more arbitrary strings of the same length.
There's no free lunch -- any algorithmic advice you can give to the password-creator can be given to the password-cracker to change the order in which the possible passwords are tried.
For example, suppose we all pad our passwords by appending a single chosen punctuation character between 1 and 20 times at the end. There are about 30 basic such characters, so that choice of which character multiplies the number of possible passwords by 30 (from what ever it was before the padding). The choice of the number of repetitions multiplies it by another 20, for a total of 600. We could have gotten exactly the same improvement by appending *one* of those punctuation characters followed by the *number* between 1 and 20 (e.g. ",17"), which would be much easier to type and just as easy to remember.
In fact we could do even better by using a number between 1 and 99, which multiplies the number of possible passwords by 3000 instead of 600. This wouldn't have been feasible in the "padding" scheme since you'd have to type the same character up to 99 times.
The only reason a password cracker might have more trouble with the padding scheme is that its author *doesn't know* that padded passwords are at all likely -- hence the security-through obscurity.
Many password systems *reject* chosen passwords that have too many repeated characters, because these merely make the password artificially-long without adding a corresponding amount of security.
David B Rosen, you can pad with anything. Doesn't have to be the same character eg. --++01my_|_password10++--. Listen to the podcast again.
@Nevar, I assume that by "pad with anything" you mean pad with any pattern or sequence of mostly-nonalphabetic characters that you find easy to remember. Or if "anything" included *all* characters then the advice would become the same as "use a longer password but have it include some patterns/sequences at beginning/end that you find easy to remember". Either way, why limit it to using meaningless patterns rather than random words, which would be even easier to remember for most of us?
E.g. instead of --++01my_|_password10++-- you would have the same length by using "Lefty rational seeking 9?" (if you want digits/symbols/case) or even just "chair store happy reaches" as in shown to be very strong even though it has only lowercase letters:
http://www.baekdal.com/insights/password-security-usability
and the highly-influential cartoon:
http://xkcd.com/936/
Not only would these be easier to remember, they would be faster and easier to type for most people. You could use the generator at
http://preshing.com/20110811/xkcd-password-generator
Yeah, I took his advice to pad as what you said "use a longer password but have it include some patterns/sequences at beginning/end that you find easy to remember". I suppose any long sequence is good. I'm guessing if the padding is simple, some people might find it easier to remember than random words, eg. (-----username-----service-----), (-----john-----email-----).
Cool @ links. I'm aware of them thx. Here's another : http://world.std.com/~reinhold/diceware.html
Another problem with Steve Gibson's scheme is that its strength can't be calculated reliably, precisely because it's so vague: it doesn't clearly define a set of equally-likely potential passwords as would be needed to do a proper calculation. Instead, the strength of the password depends on the user's brain processes and interpretation of the advice, and how good the bad guy is at predicting the results of those processes and the resulting order in which he should try the potential passwords.
Of course we could try to make a guess or assumptions ourselves to calculate the strength. But we could never be sure that the bad guy doesn't make a better guess than we did about which passwords a Steve Gibson follower is most likely to create, thus trying the correct password earlier than our calculation says.
That's in contrast to the schemes mentioned on the pages I linked above, which are designed so that their exact strength (for the worst case which is when the bad guy knows you used this scheme) is calculated according to principles proven by actual cryptographers and mathematical computer scientists long ago. The strength of such a scheme can only be *greater* than this calculated strength in any other case (i.e. when the bad guy doesn't assume that you used this scheme).
Cheers, @Nevar.
There's no free lunch, meaning that any scheme you use that reduces the number of passwords you're likely to use reduces the time in which it can potentially be cracked accordingly. E.g. they will try [+++doggy+++research+++] way, way, way before resorting to trying something like k2lK?uAW7d&!oiu(*oi2Axs9 or even oixzqkjwhckvbbqwmskjcxzv which are the same length.
So the best we can do is to use a scheme that of course reduces the strength (compared to truly random chars of same length), but by an amount that experts can *calculate*, so they can *prove* that it has at least such-and-such strength.
BTW, I saw an article saying that a mere 20 bits of strength (which you can get from passwords of two random words like "reaches happy") is plenty to prevent *online* attacks on web passwords, because the site will not allow enough tries to crack it. The only reason you really need a password as strong as the ones we've been discussing is to thwart *offline* attacks such as when the site's hashed-password list is stolen. But even in the leaked-hash-list case, it's not so bad so long as the site (or you) change the password and you aren't using the same password on other sites. Anyway there will be plenty of people who have *much* less than 20 bits of strength, so the bad guys might never bother to get to yours :-)
So the only time you *truly* need a really strong password is is for fully-offline encryption, like hard-drive or file encryption or most forms of email encryption, where there's no remote server in the way to stop someone from doing an unlimited number of tries until they get it. In these cases the only way to avoid needing a very strong password is if there's a strong key unavailable to the attacker. E.g. you wouldn't need more than a medium-strength password if a key has to be obtained from a keychain fob device or a remote keyserver that limits the number of tries -- but such methods aren't widely used by the general public.
Like the author, I use Last Pass to generate passwords for websites that require one. In all other cases, I find that, for me, the best way to generate some memorable gibberish is to use the initial letters of words from an obscure poem or song.
An example from a more well-known source - this is obviously NOT one that I use - might be:
itlwiwbtlamwsts (from the opening lines of "Yellow Submarine)
"In The Land Where I Was Born There Lived A Man Who Sailed To Sea"
This gibberish can of course be dressed-up with character substitutions and various types of padding to make it even longer and more tricksy. As long as I use my own, personally memorable formula for any further mangling, the whole thing is very easy for me to remember.
In practice, I do not need very many of these "poetic gibberish" passwords. When I have been required to generate a new password every month, in order to access a computer at work, I have used this method (ie. the same gibberish every month) plus some memorable special character padding plus numbers identifying the specific month. For the month of November 2012, the characters 1112 or 2012-11 (or other variations) can be included. As long as you use the same formula for the date, this is also easy to remember.
As far as "shoulder surfing" is concerned, if you use your own "personal gibberish strings" routinely then it is not long before you can type them very quickly. I can touch-type all mine, including the special characters and shifted keys. This makes it nigh on impossible for a "shoulder surfer" to clock what you are typing, let alone recall it.
I have noticed that IT Staff tend to "shoulder surf" as you type your password and have overheard their subsequent advice when they have spotted people using easily-guessable passwords. They seem to be pretty well practiced at this but none have ever managed to work out my password as I typed it and they have also commented that I type my password faster than anyone they have seen. (Not bragging here, just pointing out that I have had some independent verification that this method works).
I would stand to be corrected by the experts in memory but I imagine that maximum benefit would be obtained here by including any variable characters, eg. those that need to be changed monthly, right at the end of the password.
These would necessarily be typed more slowly, so would be more easily observed.
They might then also be recognised as a pattern, eg. month and year, and so be more easily recalled by the "shoulder surfer".
If they were at the start of the password then at least some of the characters immediately following this chunk might, if they are observed, be recalled as an appendage to the "date chunk". If the "date chunk" is in the middle, the same applies. Also, it interrupts the flow of typing so might make typing errors more likely, as well as providing a second "start point" where characters might be more easily observed and recalled.
Without exception, when I have explained this method to anyone else, they have said it sounds impossibly difficult to use in practice. It might be that I do not explain it very well. Or maybe it really is harder for others. However, I have found it the easiest method to generate very long "gibberish" passwords that are very easy for me to remember and, with regular use, very quick to type.
Something that strikes me as odd from a global perspective is the assumption that the password will always be in a language that uses a Roman alphabet or common language.
Since non-random crackers use dictionaries, stepping away from any digitally available dictionary and using strong padding with phrases in exotic languages is a sort of security by obscurity, but if most hacks are based on a known data set, this strategy is quite viable.
I suspect that as technology advances, we will see visual passwords supplementing typed entry. Using say the lower right hand chunk of snapshot 43 from my high school field trip in conjunction with a strong phrase will prove over time to be a better strategy sometime down the line.
Thanks for the post! It was great fun to read.
So given a roomful of GPUs that might be assembled by a) students, b) The Joker, and c) the NSA, how long and how much storage would it take to build brute force dictionaries up to say 16 or 20 character long passwords?
If I use a 32 character long lastpass generated password, what is the probability there is an MD5 collision hash with a) 8 char long password, b) 16 char long password?
@Gordon Cooper, good point about multiple languages. You might get some benefit from a lesser-known language, especially if nobody can guess that you're familiar with that language. If you use your own (or a closely-related) language then the attacker could target people who are likely to speak/use your language (e.g. people who have posted in that language or joined a language-specific or country-specific site/group), using a dictionary based on that language.
Something I forgot to mention in my comment above on Nov 5th . . .
This method of password generation (initial letters of words taken from an obscure but personally memorable poem, book, lyric, etc.) is the reverse of the common "picture-story" method that can be used to memorise a series of random words as a "party trick".
I find it helpful to invent dramatic and easily visualised stories to memorise the random sequences of letters and numbers in assigned passwords that cannot be changed by the user. The initial letter of every word in the "password story" corresponds to each letter in the password in sequence and I have a personal method of incorporating numbers, upper-case letters and special characters. (If this sounds clever, I should add that my memory is so feeble that I even use these very visual "stories" to remember my car registration!).
For a password example, if I had been assigned this password (just making this up as I go along):
tcwtaahitbiwas
then, relating this to the example cited by David Rosen above, in the cartoon:
http://xkcd.com/936/ "correct + horse + battery + staple"
"tcwtaahitbiwas" might be memorised as (a bit violent but it was first thing that sprang to mind):
"The correct way to annoy a horse is to batter it with a stapler"
The reason I have added this post is that I have just been using a different device to access the internet and, unfortunately, I cannot use Last Pass on it very easily, ie. in order to access the passwords that Last Pass has already generated for me. So I was kicking myself that I had not bothered to construct any "stories" to enable me to remember any of the passwords generated by Last Pass for me.
I dread the thought of having to consign all these to memory. There are so many of them that it is not going to be much easier if I make new ones using whole words - and I will also have to have some way of linking each of them to the relevant site!
However, I do think that using both of the "initial letter" strategies I use might be helpful, ie. that they might reinforce the other in terms of memorising passwords, as they both involve using "stories".
I realise that my particular "story" method of generating a password that uses initial letters of words, whether the "story" is novel or borrowed, does not say anything about the strength of any individual password, apart from the fact that it enables me to remember quite long strings of gibberish.
I also appreciate that the example in the cartoon: http://xkcd.com/936/
"correct + horse + battery + staple"
is a good illustration of using a "story" and/or visual memory to help to recall an assigned or randomly generated password. In that particular case, one that has very helpfully been constructed as a series of real words.
Given a choice between filling my brain with
a) multiple sequences of bizarre imagery in order to remember random sequences of words and
b) recalling lines from songs, poems, etc.
- I think I would prefer the songs and poems, just from a quality of life perspective :-)
ps. @Gordon - good point about non-English languages and character sets. I have only used non-English sources a couple of times for "initial letter passwords" and then I substituted "similar" English characters for the odd language-specific character, in order not to have to swap keyboard layout mid-password.
However, now I think about it, all you would need to do is swap keyboard layout before and after entering the password. The password itself could then be in English "in your head" but serving to generate non-English characters when typed using a different keyboard layout and character set.
The only downside I can think of is that this might fall down very seriously when using a different computer, which might associate different keystrokes with those characters.
(There can be also be a problem with including "special characters" in a computer login password, as the keyboard layout and character set before login might be different to the keyboard layout and character set post login.)
@liz, the thing makes your example really strong:
itlwiwbtlamwsts ("In The Land Where I Was Born There Lived A Man Who Sailed To Sea")
is the fact that you've replaced "Town" with "Land" and inserted the word "There" -- that's adds an extra layer of "security" :-) You have to be sure you'll remember this particular variant, though, since you won't find it by googling if you forget.
Aside from those variations, suppose the bad guy knows or guesses that you might use the initials of the first line of a popular song as your password. Suppose that Yellow Submarine is one of the 10,000 best known songs (I'm being conservative). In this case, your password is one of the first 10,000 passwords he will try!
Thus, the *provable* security of your strategy isn't any better than merely using a password of just three lowercase letters from a random generator (like ywa, eex, sjp, etc), which has 26*26*26 =17,576 possible values which is more than the 10,000.
The three-letter password would be much easier to type (although that makes shoulder surfing easier), and perhaps easier to remember, too. And you'll never "run out" of them or not be able to remember which songs you've already used.
Of course in practice your strategy probably works better today than the three random letters merely because of its obscurity. But you've already started to compromise that obscurity somewhat just by publishing your comment! If yours became a more popular way to generate a password than 3 random letters, then your method would definitely become the weaker of the two.
If you want to get an idea of how strong a given password really is today in practice (assuming someone has not read your post or guessed your strategy per se), one way to gauge the relative strength of two passwords is to google them, or in this case google their underlying "meaningful" or "memorable" phrase -- we might hypothesize (though can't prove) that the less common is stronger.
Again ignoring the one "wrong" word, I googled "in the town where i was born lived a man who sailed to sea" (*with* the doublequotes!) and got 38,500 hits. I didn't generate a bunch of random-letter passwords for comparison, but for example "ejjsq" has only 14,900 hits so perhaps this five-letter password is about as strong as yours (and again you don't have to think up a song that you haven't used before).
BTW, you probably shouldn't really use a password derived from a term that you googled, or certainly at least not one you googled without using secure/encrypted search page.
Hi David,
You spotted my NON-deliberate mistake in the lyrics of "Yellow Submarine" :-)
I do take your point that a deliberate re-wording of a well-known string of words would help to improve password strength using this method. In this particular example, however, were I ever to have used this song to generate a password (I have not done so and do not intend to do so) then I would have incorporated my habitual "misremembering" of these lyrics. I have no problem getting the words of this song wrong in that particular way :-)
You say,
". . . suppose the bad guy knows or guesses that you might use the initials of the first line of a popular song as your password. Suppose that Yellow Submarine is one of the 10,000 best known songs. In this case, your password is one of the first 10,000 passwords he will try!"
I think from this that I did not explain my method very well. I very definitely did not and would not recommend using "the initials of the first line of a popular song" to generate a password.
What I suggested was, "to use the initial letters of words from an obscure poem or song".
That is, I would suggest using an "obscure" source rather than a "popular" source. I also would NOT recommend using the first line of any published work but, again, I rather misled you by quoting the first line of that song as my example. Afraid that I was being very lazy and not bothering to check the actual lyrics of the whole song in order to pick a line to use as an example. However, as "Yellow Submarine" would qualify as a "popular" or "more well known" song, it would therefore ineligible for use at all. To reassure you, I did not want to disclose anything that might give anyone any clues to the sorts of material that I might actually use in "real life", so I picked something that was completely unrepresentative of the sources that I might use . . . or DID I? :-)
I am having a struggle "getting" your explanation about gauging the relative strength of two passwords by doing an internet search for the underlying "meaningful" or "memorable" phrase. The point of this method is that the mnemonic is not disclosed - so if you were trying to guess my passwords or use some automated method to crack them, where would you start? They are in my head - I do not need to Google them. If you discovered my "favourite" songs, poems, books, etc. that would not help you either.
I don't think that lines from lyrics would suit everyone as "memorable password generators" and I also understand that anything that is not random is going to be more vulnerable. This is just a suggestion for a general method (not specific to songs) of finding a middle ground between choosing something that is too obvious and, at the other extreme, having a load of gibberish that you don't trust yourself to remember, so you have to write it down. It is also an easy way to explain the method, although I could just as easily have chosen the wording of a famous advertising slogan, for example, as a starting point for the explanation.
To test the alternative, for your example of "ejjsq" I have come up with: "Eel Jelly Jam Sets Quickly" but I don't REALLY trust myself to remember that, particularly if it was one of many "nonsense phrases" that I had to remember - and I can't think of anything that actually makes sense for "ejjsq".
When I have talked to anyone about this, it is because I am aware that they are using very obvious passwords and/or are writing them down. What I have suggested is that they use whatever personal mnemonics work best for them. (Not commonly-used mnemonics obviously). The example that I actually demonstrate to start off with is: tcsotm (and then I explain never to use that one because it is too obvious) and the next one I show them is: waliays (you should get that where that comes from - I also say never to use that one either). At this point, if they have not run screaming from the room, I ask if they can think of a sentence that they are not going to forget and then to think of the first letter of each word.
The first time I tried this must have been about twenty years ago and I forgot to add, " . . . and don't tell me what it is!!!" and I can still remember the bizarre, completely unguessable phrase that was blurted out. And that was from my own mother . . . I think I might start using that one, it is too good to waste :-)
So, for the sake of argument, if we imagine someone who someone else seriously wanted to hack, the bad guy would have to know that there was some sort of mnemonic system or systems and would also have to know the basis for that system or systems. Maybe have worked out whether or not there were any word order, capitalisation and special character conventions too?
Given that scenario, I agree that once the bad guy also discovers that the target has abiding interests in, say, Scottish Football, Architecture, ballroom dancing and cats that this might help him to crack a password like . . . PT!aHA!asaYM!am (Partick Thistle and Hamilton Academicals and samba and York Minster and manx. The conventions for that including: keyword order; Football Clubs and Historical Buildings always capitalised and always followed by an exclamation mark; all other words always lower case; key words or phrases always separated by "and").
Again, to reassure you, I am making this up as I go along - these are not things I use . . . or ARE they? . . can't you just see those kilted cats jiving in the cloisters! :-)
All good points, Liz. All I'm really trying to say is that there's no free lunch -- a padded password or initials of a known phrase may be plenty strong enough, but still very, very much weaker than a truly random password of the same length. Steve Gibson clams that "all" that matters is length because you "force" the attacker to resort to true brute force, but in fact you can never be sure exactly how obscure your mnemonic phrase (what if it turns out to be one of the 10,000 most popular) and transformation algorithm (what if it is one of 100 popular "clever" strategies) are for passwords. Some people still think nobody will guess "p@ssw0rd" because they think it is cleverly obscure. If we rely entirely on people's judgment of obscurity, this isn't always very reliable. On the other hand, if they use a generator of some sort, then we aren't relying on subjective judgments of obscurity at all!
This doesn't have to be random letters -- even a truly random choice of two words from your favorite dictionary can't be "guessed" in less than, say, hundreds of millions of tries, even by someone who uses the same dictionary to generate all the possible combinations and tries them. Even if you cherry pick the most "memorable" of the first 10 combinations you generate, and even if the attacker knows what kinds of pairs people consider memorable, it will still take him millions of tries.
I wouldn't have any trouble remembering such a password, and "millions" is enough for a web password as I mentioned in an earlier post above (20 bits ~ a million). If you need a password that can't easily be cracked, even offline with unlimited tries, then four words should do the trick.
Another approach is to combine a memorable non-random password with a suffix of just a few randomly-generated characters, and keep a list in your wallet of the suffix for each of your accounts/sites.
Liz, about googling, I just meant that it's a way to "quantify" the "obscurity" of the phrase or word that you are starting with. That way, even if a transformation algorithm (e.g. first letter of each word) turns out to be obvious to an attacker (so that he might very well apply that and hundreds of other known transformations to each entry in his list of millions of well-known phrases and try them all), you've started with something so obscure that it won't be on the list in any form.
But, in the end, even if you have a password that applies one of 10 common transformations to one of the 10,000 most commonly-chosen phrases/words, you might be quite safe because it's more cost-effective for the attacker to conduct a phishing attack (on you or someone else) than to try so many passwords. And if he can crack 98% of all passwords with a list of 10,000 common passwords and no variants (as was found to be the case on a website recently, though granted the site didn't even enforce a minimum pw length), why would he even bother with yours?