Email addresses and security

[ewx]

One of the things that interested me about Mat Honan’s account of the attack on him was there were three steps where the attacker had to discover an email address:

1. His Twitter account was registered to his Gmail address. If the attacker hadn’t been able to guess what email address his Twitter account used then presumably they wouldn’t have been able to break into it.
2. The recovery account for his Gmail was an Apple address. Gmail revealed enough of it (to anybody) for the attacker to figure out the exact address. Without that they wouldn’t have been able to break into his Gmail.
3. His Amazon account was registered to some address known to the attacker; perhaps one of the two above, though this isn’t stated. Again, they needed to know (or guess) that address in order to break into his Amazon account, which in turn they needed to break into his Apple account.

That suggests to me that it’s worth treating email addresses that are used as login credentials with much the same care as passwords:

1. Keep them secret.
2. Don’t share them between accounts. (Really this follows unavoidably from 1.)
3. Make them hard to guess. (So does this.)

This means they will have to be written down and kept in a safe place, just as with passwords.

Of course it’s not practical to use a completely different email address for every online account. But many mail services give let you add a suffix to your address; for instance <me>+<anything>@gmail.com will reach me just as well as <me>@gmail.com will. So (hypothetically) the address I give to Amazon might be <me>+ealohboh@gmail.com, the address I give to Apple might be <me>+giefeing@gmail.com, and so on.

To be perfectly clear: the point of the exercise here is not to make it hard to guess an email address for me. It is to make it hard to guess the exact email address that controls my login with some other organization.

(If an attacker can persuade some luckless human on the phone that <me>+ealohboh@gmail.com should be treated the same as <me>@gmail.com then it won’t help much. But they’re unlikely to be able to persuade a computer of that equivalence.)

Now, I’ve been using per-site addresses for years, albeit not ones that are particularly difficult to guess once you know the pattern (i.e. and therefore unlikely to be much protection from a determined attacker). There are several advantages:

• It makes filtering and blocking easy.
• It makes phishes more obvious, since even if they guess who I bank with (for instance) their message is sent to the “wrong” address for my bank. (Not that I’ve ever had any trouble spotting phishes.)
• When someone leaks - or sells - their user database, it’s obvious who.

In May, or perhaps even earlier, LinkedIn suffered a data breach, which only became public about a month later. I noticed because I started getting spam; evidently whoever was responsible had been quietly getting on with making money out of the breach for some time before it became public. But LinkedIn could have known about it as soon as their customers did, by the relatively simple expedient of seeding their user database with a collection of fake “canary” users and sounding a klaxon if any spam arrived at their email addresses.

By varying the set of canary users over time or (depending on site architecture) according to how directly you access the database, it might be possible to learn further things about breaches.

Finally, some websites reject email addresses with a + character in. (Presumably they are operated by people too lazy to read specifications, which is not very confidence-inspiring if they also want your credit card number.) Historically I saw this as little more than an inconvenience; but if you agree with the discussion above then these websites are actively impeding a useful security mechanism.

Comments

[purplecat]

That's a good suggestion. My heart sank when I read his piece and realised the obvious corollary was as many email addresses as passwords. But you are correct, a standard set of extensions of the same name would work.

Though working out how to get my web host to conceal my whois data is another thing I clearly need to get on top of.

[cartesiandaemon.livejournal.com]

Good point. I suppose even having one or two dedicated email accounts for registering with websites would be better, although obviously not as good as having a unique email for each.

Finally, some websites reject email addresses with a + character in.

I always imagined the conversation something like this.

Customer: You should allow email addresses with '+' in.
Website: Why? Does your primary email address have a + in?
Customer: Not per se. But I find it very useful to give out a site-specific email address.
Website: Oh, no, no. We want your REAL email address. Because, um, then we know you're a real person.
Customer: OK, it IS my real email address.
Website: But why do you want to use different email addresses at all?
Customer: So if you get hacked or sell my email address to disreputable spammers, I can be sure it was you, and I can delete the email address I gave you so I don't get any more spam.
Website: You're right, that's an excellent idea! We'll get right on that, we'll let you know as soon as we've done it. Scouts honour!

...

[fanf]

It's often the case that all you need to know is the victim's username and where their password reset mail goes, in which case this kind of defence does not work. And using a secret email address can defeat (or be defeated by) social features such as Amazon wish lists. But I guess it is a useful thing to do with web sites that require registration and aren't social.

[ewx.livejournal.com]

Amazon claim not to reveal email addresses through wishlists and AFAICS that’s correct; mine is here (http://www.amazon.co.uk/registry/wishlist/1EL42AS21VLX0/) if you think you can show otherwise. But as general points, yes, there’s something to both those remarks.

[lnr]

I believe the wishlist doesn't reveal the email address, but the email address *may* be usable to find the wishlist!

Although actually I just logged out and searched for my *own* wish list using the address I know I'm registered under and it didn't find it. Heh, though this turns out to be because it still has the site-specific address I *used* to use as my login. That's rather the wrong way round really, but it looks like you can tie your wish list to a well-known address even if you use a different one to log on.

[sbp.livejournal.com]

I do this on an ad-hoc basis with my own domain name. Suppose I should use a +suffix method just to reduce the "new site, update virtual host table" loop, but I don't update it that often, so whatevs.