This weekend my father-in-law had his email account hijacked. While I've handled this kind of aftermath at work from time to time, it really focuses the mind when it is family it happens to. It was probably an Evil-AP attack sometime last week, he failed to be sufficiently alarmed when his email client alerted about a bad SSL certificate, not phishing. Happily there wasn't much email in the account (POP3 user) for the Evil People to plunder through. Even so, every time he took a walk this weekend someone (many someones) would ironically ask him about his trip to Cyprus and express ironic gratitude that he made it home safe. Jokers, the lot of 'em.
Happily for my sleep schedule, he learned of it during a time of day that the only reason I should be getting phone calls is for a death in the family or something at work has gone fatally grink. Which means he called his email support people first, and not me.
Even so, one of the things I told him before I learned how empty his mailbox was is that control of an email account, especially a private one, is a great way to bootstrap into ecommerce accounts. General internet consensus seems to have arrived on the idea that your email address should be your username on most sites. Most non-bank password-reset processes generally involve an email sent to that very account. Add in 3+ years worth of payment receipts, and the Evil People have a nice list of ecommerce sites where that email address can likely be used to gain access. Many sites will send you the actual password in that email, others will send you a link that'll force a password change but still let you in. Either way, they're in.
Not in my father-in-law's case, big empty mailbox, but still.
It's for this reason that many of my friends have a specific email account just for paying for things on the Internet. It only gets checked via webmail, and infrequently. Therefore, that account has a smaller attack surface.
Which is to say that email-as-proxy-password is a crappy authentication environment. All three of the big email providers have a way to use their authentication services, not just having an account there, as an actual auth service. For Google and Yahoo! it's OpenID, for Microsoft it's LiveID. Microsoft has had Passport for ages and even actively promoted it, but it still failed to gain much of a foothold. It's these sorts of systems that can break us out of the bad-password-reset process trap!
ahm, no.
In this case the attacker actually had a legitimate login to one of the big three email account providers. Once the attacker had that, they could quite legitimately leverage that to login to any OpenID/LiveID sites without having to go through a password-reset process. I'm pretty sure this is why most sites that handle money aren't leveraging these systems.
Evil-AP and phishing allow attackers to use a legitimate password to log in to accounts. The only real defense is some kind of two-factor security. Two-factor can work find for web-logins, banks do it all the time, but POP and IMAP don't have native hooks that support it. Both protocols have Kerberized versions that can be used, and the Kerberos system can require two-factor; but this is a usability nightmare and will never be widely adopted. Alternately, the SSL-wrapper around the POP/IMAP service can require a Client Certificate before it even establishes the POP/IMAP session, but Client Certificates have never seen wide adoption, and mail-client support is spotty at best. Also, certificate distribution and management is another usability nightmare.
What could be done is if these sorts of per-site login engines also asked for a cell number, which would only be used to notify of password reset/lockout events. It provides an out-of-band notification method. The down side with that method is that a large majority of people will leave that field blank from the very real fear that entering a number would sign them up for SMS-Spam. A more acceptable way would be an alternate email account that would also receive reset notices.
Usability makes this a tricky problem to solve.
Happily for my sleep schedule, he learned of it during a time of day that the only reason I should be getting phone calls is for a death in the family or something at work has gone fatally grink. Which means he called his email support people first, and not me.
Even so, one of the things I told him before I learned how empty his mailbox was is that control of an email account, especially a private one, is a great way to bootstrap into ecommerce accounts. General internet consensus seems to have arrived on the idea that your email address should be your username on most sites. Most non-bank password-reset processes generally involve an email sent to that very account. Add in 3+ years worth of payment receipts, and the Evil People have a nice list of ecommerce sites where that email address can likely be used to gain access. Many sites will send you the actual password in that email, others will send you a link that'll force a password change but still let you in. Either way, they're in.
Not in my father-in-law's case, big empty mailbox, but still.
It's for this reason that many of my friends have a specific email account just for paying for things on the Internet. It only gets checked via webmail, and infrequently. Therefore, that account has a smaller attack surface.
Which is to say that email-as-proxy-password is a crappy authentication environment. All three of the big email providers have a way to use their authentication services, not just having an account there, as an actual auth service. For Google and Yahoo! it's OpenID, for Microsoft it's LiveID. Microsoft has had Passport for ages and even actively promoted it, but it still failed to gain much of a foothold. It's these sorts of systems that can break us out of the bad-password-reset process trap!
ahm, no.
In this case the attacker actually had a legitimate login to one of the big three email account providers. Once the attacker had that, they could quite legitimately leverage that to login to any OpenID/LiveID sites without having to go through a password-reset process. I'm pretty sure this is why most sites that handle money aren't leveraging these systems.
Evil-AP and phishing allow attackers to use a legitimate password to log in to accounts. The only real defense is some kind of two-factor security. Two-factor can work find for web-logins, banks do it all the time, but POP and IMAP don't have native hooks that support it. Both protocols have Kerberized versions that can be used, and the Kerberos system can require two-factor; but this is a usability nightmare and will never be widely adopted. Alternately, the SSL-wrapper around the POP/IMAP service can require a Client Certificate before it even establishes the POP/IMAP session, but Client Certificates have never seen wide adoption, and mail-client support is spotty at best. Also, certificate distribution and management is another usability nightmare.
What could be done is if these sorts of per-site login engines also asked for a cell number, which would only be used to notify of password reset/lockout events. It provides an out-of-band notification method. The down side with that method is that a large majority of people will leave that field blank from the very real fear that entering a number would sign them up for SMS-Spam. A more acceptable way would be an alternate email account that would also receive reset notices.
Usability makes this a tricky problem to solve.
Google's two-factor authentication implementation is actually quite nice. You authenticate once per client, so it's not too intrusive but it prevents someone from using a compromised password to log in from somewhere else. You can authenticate using (a) an app on your mobile device, (b) a list of pre-computed one-time passwords, or (b) by receiving a generated key via a voice call.