I got into a conversation today with some of the IndieWeb developers in our Homebrew Website Club meeting, talking about recent articles about a major password breach.
This got me to thinking—with some prompting from shadowy web standards advocate and staunch info-sharing supporter Tantek Çelik—that this would be useful to document.
Unique email addresses and passwords for every website
The basic idea is this: every single website signup gets a unique email address and unique password. This way, if a website is breached and the passwords are leaked, no other accounts are compromised, just that website’s.
The trick is to do it in a way that I can remember, or easily derive the usernames and passwords per site, so I don’t have to rely on a pain-in-the-posterior password manager, and can log in from anywhere easily.
Obviously I’m not going to give away details of how I specifically do things, but I can get pretty detailed about the principles I use.
The Catch-All Email Address
First thing you need is a catch-all email address on your domain. Not all hosts allow these—I remember Scott Beale having a cow about mine long ago due to the load that dictionary spam against me was putting on his mail server (that’s when someone spams a long alphabetical list of common last names on a domain email addresses: [email protected], [email protected], [email protected] … [email protected], [email protected].)
But nowadays email security is better, and I’m not concerned about that. Plus my email is the one aspect of my internet presence that’s still hosted by a major corporation, they can take it.
Also suggested: buy a dedicated domain just for account signup emails. I’m not going to tell you what mine is, but I have a domain just for email addresses for signing up to websites, and a catchall address set up on that domain.
So, let’s say the domain I bought for this was kupmail.com
. That would mean you can write me, or I can sign up for an account on a website with, [email protected]
or [email protected]
or [email protected]
or whatever you want. Any email address on that domain arrive in my inbox.
Figuring out a unique email address and password for each website — the simplest version
For email addresses, you can keep it pretty simple as they’re not sensitive information. For passwords, you should be a little more complex.
Email address
For an email, you might just use the domain name as part of a stock email address pattern and your catch-all address’s domain. Say I’m registering for an account on mojavephonebooth.com
. I might use the email address [email protected]
. For altavista.com, I’d then use [email protected]
. I like to add a suffix, like -eml
, even though it’s not strictly necessary. It makes it easy for my email filters to filter all email coming from accounts I signed up for, as opposed to personal email from people I know, by looking for [email protected]
.
Password
For this, I use what’s called stemming—fixed string of characters that every email address and/or password will be built on, with variations added per website.
One frequently suggested opinion I like is to pick a favorite song, and use the first letters of the words of the first lines, with some easily remembered capitalization and substitutions. For instance, if your favorite song is “Somewhere Over The Rainbow”, you might use “S0trbf” as your stem, for “Somewhere over the rainbow, bluebirds fly”. You’ll always be able to remember that.
Then, to make each password unique, you might decide to always use the first three letters of the domain name you’re signing up on. You also want to pad it out to at least 12 characters. So you might double it. And you might want to pick a punctuation character and a digit to stick somewhere in there, as this are a frequent (if misguided, I’ll write about this elsewhere someday) requirement.
So to sign up for a mojavephonebooth.com account, you might pick the suffix “-mojmoj”, from mojavephonebooth.com.
Putting it all together, to sign up for an account on mojavephonebooth.com, I might then use the password S0trbf-mojmoj
.
Again, this gives us a password easy to remember or figure out on the spot, hard to guess.
A pitfall, and a safer version
Now, there’s one possible problem with this. Let’s say I did the above, I signed up for mojavephonebooth.com with email address [email protected]
and password S0trbf-mojmoj
.
The problem with this is that if mojavephonebooth.com gets hacked and the passwords leak, somewhere out there on the dark web there will probably be a text file with something like this in it:
website: mojavephonebooth.com
username: [email protected]
password: S0trbf-mojmoj
Now, an astute hacker—they do exist—may notice the similarity between the domain name, email address, and the suffix on the password, and think to themselves, “Hmmmmm, I wonder if this person also has a Paypal account at [email protected]
and password S0trbf-paypay
.” And they’d have guessed right.
And then they could get into my account and ship $800 worth of digital gift cards to themselves in Europe with my money, which Paypal might insist doesn’t look suspicious at all and refuse to honor their fraud coverage guarantee, leaving me on the hook for it. (And if this sounds oddly specific, there’s a reason for that.)
So, you’ve got to make it more difficult than that to guess your scheme.
My suggestion is to have the passwords include a number you can derive from the domain name with a formula that is easy to remember and use, but hard to figure out.
For instance, you might decide that you include the number of vowels in the domain name, times the number of consonants, followed by twice the length of the domain name. So, in “mojavephonebooth”:
Number of vowels: 7
Number of consonants: 9
Length: 16
So the number you get use be (7 * 9) = 63 followed by 2 * 16 = 32, or, 6332
. So instead of password S0trbf-mojmoj
, the password would be S0trbf-mojmoj6332
.
For “paypal”, it would be:
Number of vowels: 2
Number of consonants: 4
Length: 6
So the password would include (2 * 4) = 8 followed by 2 * 6 = 12, or 812
, and therefore be S0trbf-paypay812
.
(Note: Make sure you pick a scheme that generates numbers of sufficient length. If it’s just one digit, all they have to do is try 10 times at most and they’ll have guessed it. It should give you least 3 digits, preferably 4 or more.)
Now the password format is no longer constant, and it’s not easily possible to guess the password from a single, or likely even several, examples of the domain-email-password combinations that you use.
Further suggestions
If you want to be extra secure, use all the above situations as starting points, but come up with even more complicated schemes. And maybe even come up with a formula for custom numbers to add to the email address, too, not just the password. The trade-off is, more complicated means safer but harder to remember—but none of these are terribly hard to remember once you’re used to them.
Do as I do, not as I say
In any case, never use the exact formulas or suggestions I’ve given here, they’re just examples. Come up with your own, unique to you, based on these examples.
Obviously the scheme I really use is much different from these examples, too. But the basic idea is the same.
And of course never tell your scheme to anybody or write it down, that should go without saying. It should be something you can easily remember forever. Trust me, once you’ve done it about 3 times any of this should be easily memorable.