Aug. 15th, 2012

ewx: (geek)

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.

February 2025

S M T W T F S
      1
2345678
9101112131415
16171819202122
232425262728 

Most Popular Tags

Expand Cut Tags

No cut tags