I’ve been thinking lately over the saga of Naoki Hiroshima and his battle to control @n. Which he apparently regained control over, by the way. The fundamental issue here is that your email address is the gateway to all the rest of your accounts. If someone compromises your email, they can then issue password reset requests to all of the rest of your accounts, and probably seize control of everything.
Complicating this is that you want to log in to your email for everything. You probably don’t want a terribly onerous password to log in, and you probably do want to leave yourself logged in on your computer throughout the day. And the result is a security risk.
Suppose that there was an email header, like X-Sensitive-Data or something, where you could specify that this email should be put into a secure area by email clients.
An email client, then, would just tell you when you log in normally that you have 3 sensitive messages (or whatever). In order to access them, the client would require you to put in an additional security measure, whether that be just an additional password or something stricter like two-factor authentication.
Compare and contrast this approach with something like, “suggest a best practice to everyone of allowing their users to include two different email addresses, one for routine communications and one for password resets.” This would result in every service out there needing to create a new UI, and for users to use the new UI — frankly, it would never happen. The header approach allows people who want to conform to the standard to drop in probably a single line of code, and for the user not to do anything.
Users who are not security-aware could be nudged by conforming clients. The first time you get a message with X-Sensitive-Data, your client could explain that if you like, you can set up a more-secure area of your email, and use another password for that. Users who did not care about security could set their clients to ignore the header. There would not need to be any additional code paths to handle users who have non-conforming clients. Organizations that valued security more highly could choose clients that force two-factor-auth or something for their sensitive messages.
Does some standard like this already exist, and it’s just not used? It seems like a pretty obvious and low-cost approach.
Sandor at the Zoo 