[runbyfruity]

1. If someone intercepts your password you're screwed anyway. How many of your emails are intercepted regularly?

2. If someone has access to your email, you're screwed anyway because they can lock you out and reset every password.

Your email password, effectively, becomes the password for that website. I.e. security-wise, I think they're equivalent.

[ikiris]

No they cant for any entity that properly implements security. This is the entire point of u2f.

[garmaine]

> If someone intercepts your password you're screwed anyway. How many of your emails are intercepted regularly?

Every single one of them. Email is a plain text protocol.

[tialaramex]

In practice, today, this is not very true.

There are three components worth looking at. Each of them is popularly secured with TLS.

Firstly, submission, sending an email you just wrote from your client to a server. This is usually done over a specifically TLS-secured "SMTP submission port" 587 although it can also be done with STARTTLS.

Second, relay, getting email from your server to somebody else's server. A large proportion of today's servers default to STARTTLS over SMTP for MX. So this means when they connect to a peer server to exchange mail they'll enquire about using TLS and do so if possible. A passive adversary can't stop this happening.

Finally, delivery. Almost all modern IMAP clients default to using TLS with IMAP, so this step will be encrypted. Even in clients that don't require TLS a passive adversary can't stop them upgrading by default if possible.

[garmaine]

It’s stored in plain text on every server along the way. That’s where it is vulnerable.

[tialaramex]

> every server along the way.

This is misleading. Remember our context here is that we're getting a sign-in token for some web site, let's say it's the EXA Metal Pole Limited (Europe) site, example.com

The plain text is stored briefly on EXA's outbound mail server mail-blast.example.com, and then it's transmitted to my inbound MX mx1.tlrmx.org, stored very briefly there, and passed to the IMAP server imap.tlrmx.org.

So that's three servers, but, one of them is controlled by the same people as the site we're logging into. If they want a backdoor they can just make one, they don't need to steal their own sign-in tokens, that would be really stupid.

OK, so two servers left. But those are both operated by me, the recipient of the tokens. Why am I stealing my own tokens? To what end? "Oh no I broke into my own account and have impersonated myself" ?

Now, many people use say GMail instead of their own mail servers. But can we reasonably say these people's mail was "intercepted" by GMail, the outfit they've explicitly chosen to receive and store email on their behalf?

And even if we insist upon using the word "intercepted" this way ("The Buccaneers pass was intercepted by Mike Evans" [Evans is a Buccaneers Wide Receiver, the pass was presumably meant for Mike and so we would not ordinarily call this an interception, but if you insist...]) it's unclear what unexpected gain is achieved. GMail could just build their own backdoor and sign in as you to get the tokens instead of "intercepting" them if for some crazy reason that was what they wanted.

[garmaine]

Email is federated, not point to point. It quite often hops between a couple of servers. Cloud hosted stuff typically gets routed through the cloud provider first (and whatever intelligence agencies are tapping that feed), which then pushes it to the top-tier smtp server nearest the destination for obscure hosts.

Still we’re in a perverse situation here. Running your own server is getting harder to do since everything operates on white lists, and I wouldn’t trust the big name providers for something like this.

[wffurr]

95% of inbound email traffic to Gmail is encrypted with TLS.

https://transparencyreport.google.com/safer-email/overview?h...

Password reset emails are already extremely common and a way of implementing the "second factor only" method in the OP.