Now for the frequent objections I get to the method I suggest. They all some some truth to them, but none of them are convincing enough not to use this system.
1. Someone can figure out your password generating rule if they get to look at one of them.
An example: okdufgo3fa. Can you tell that this is a password for Facebook? Could you tell that erdufgo3ga would be the corresponding Gawker password? You probably can, at least if you have two, and if you took a few moments to go through the most obvious ways to do that. There are two issues with this: One: This is a problem where you have to find a pattern. Humans brains are ridiculously good at anything pattern-related. Computer chips on the other hand are incredibly bad at it, especially if you start to use rules which are obvious to humans, but arbitrary to computers, such as "put all vowels in front of the consonants (facebook becomes aeoofcbk). Computers don't even know about vowels.
This directly leads us into our second point: We have CPU power in abundance, but not human eyes. No hacker would bother looking at thousands of leaked passwords personally, trying to figure out the rule for every one of them. And since everyone else has a password like '12345', why should he even bother?
Conclusion: Nobody will take the time to break it, and even if, it's not actually as easy as it sounds.
2. What do you do when you have multiple accounts for the same service?
Completely different, yet the same underlying issues. What does it mean to have two accounts at the same service? Well, two user names use the same password. But how is a hacker going to know which two user names match? He cannot even do this via brute-force, because all the people that chose '12345' will crowd the list of duplicates. Again, this comes down to the fact that a hacker won't even bother.
And secondly, how is someone going to use that knowledge, if they do not have your other account name? They cannot infer the rule to generate more passwords (since they only have one example), they cannot break into your e-mail or your bank, and most importantly: When a service gets hacked, you lose both your passwords there to begin with and usually not just one. In the end, this does not make any difference at all.
3. Some services require you to change your password from time to time.
In that case, there is no useful way out of it. Your chosen rule will probably not adhere to anything like this. But compare it to any other system of choosing passwords: You would also have to change your password every few months. In the end, no system can cope with this to begin with, so the best way to handle such an egregious exception is to make it one: You will have to remember a specialized (frequently changing) password for just that service. I would recommend not using the service, because that's just a huge bother.
4. Restrictions on character range or length.
This only really applies if you chose a bad function that does not include one or two digits, and is very short. The easiest way to avoid the issues is by selecting a function which will always result in 9-12 characters, and have exactly two letters in it. I know of no web-service where such a password would not work. Except for my bank account, where only letters work, so I have to write that password down on paper. It figures that my most important password is the one I have to treat the most risky, by writing it down.
Overall conclusion: There are some small issues with the system, but they are less impractical than any other system would have, facing the same problems.
Addendum: Nobody has yet pointed that out except for Randall, but the real issue of passwords is mostly length. 20 lowercase letters are way harder to solve than a combination of letters, capitalisation, punctuation and numbers if they only last for 8 characters. You can just use a very long static string in this system, and you're fine.
In that case, there is no useful way out of it. Your chosen rule will probably not adhere to anything like this. But compare it to any other system of choosing passwords: You would also have to change your password every few months. In the end, no system can cope with this to begin with, so the best way to handle such an egregious exception is to make it one: You will have to remember a specialized (frequently changing) password for just that service. I would recommend not using the service, because that's just a huge bother.
4. Restrictions on character range or length.
This only really applies if you chose a bad function that does not include one or two digits, and is very short. The easiest way to avoid the issues is by selecting a function which will always result in 9-12 characters, and have exactly two letters in it. I know of no web-service where such a password would not work. Except for my bank account, where only letters work, so I have to write that password down on paper. It figures that my most important password is the one I have to treat the most risky, by writing it down.
Overall conclusion: There are some small issues with the system, but they are less impractical than any other system would have, facing the same problems.
Addendum: Nobody has yet pointed that out except for Randall, but the real issue of passwords is mostly length. 20 lowercase letters are way harder to solve than a combination of letters, capitalisation, punctuation and numbers if they only last for 8 characters. You can just use a very long static string in this system, and you're fine.
