5 ms·

They're removing plain text auth because: a) password doesn't support 2nd factor. b) Most configurations keep password is on disk somewhere, often in plaintex

They're removing plain text auth because: a) password doesn't support 2nd factor. b) Most configurations keep password is on disk somewhere, often in plaintext. c) User configurations break on password rotation. Your tracking theory doesn't really hold up a) they know exactly who you are on your email client anyway as you log in and b) most users are logged in to their google/microsoft account anyway because of o375/workspace/youtube.

jeroenhd 4y ago
a) is only relevant once, during setup; b) isn't fixed by Oauth; c) is by design, I'd argue. I support adding 2FA to email in some way, but I heavily dislike using browsers to do so. What's wrong with adding a simple challenge-response protocol for FIDO2/U2F USB drives? Or a TOTP popup if you don't have a physical security key? This can all be standardised without a browser ever touching the email client. We already have IMAP authentication methods that use signatures (like most 2FA hardware keys use) or challenge/response methods. You can even do client certificate authentication through STARTTLS when lacking a TPM.
- 0x457 4y ago
  > What's wrong with adding a simple challenge-response protocol for FIDO2/U2F USB drives? Or a TOTP popup if you don't have a physical security key? Infrastructure to handle authentication on the web already exists. This is a massive benefit for providers and client developers. Whatever you propose does not. Good luck convincing big email providers to agree on a new standard like that. GitHub alone has like 5 different ways to handle 2FA. Google has, I think, 3? Using a browser to handle this simplifies things a lot. b) While it's not fixed by Oauth it greatly limits what can happen: — First, you only need to store a refresh token that can expire and that expiration can be controlled by administrator — Second, that token has limited scope: password provides access to entire account — Third, it's clear where it came from — if token gets compromised, you will know where it happened. With password, it's unclear.
  - jsnell 4y ago
    > Google has, I think, 3? There's at least: 1. SMS 2. TOTP 3. Google Prompt (on Android / iOS) 4. Offline security codes (distinct thing from TOTP, generated from Android settings) 5. Backup codes 6. Security Key
    - magicalhippo 4y ago
      Do you have some documentation for this? All I could find[1] pointed to them only supporting OAuth, similar to Microsoft. [1]: https://developers.google.com/gmail/imap/imap-smtp https://developers.google.com/gmail/imap/imap-smtp
      - jsnell 4y ago
        I didn't mean that they had native IMAP support for those, but that these are the 2FA methods they support in general. With browser-based OAuth, it's viable to build support for a new 2FA method in just one place. Needing to build each of these into a protocol + get all popular IMAP clients to implement that support? It'd take an eternity; we'd probably still be stuck on just TOTP.
        magicalhippo 4y ago
        Ah yes, my misunderstanding. Indeed, OAuth makes it easy to swap out the actual authentication step. Which is nice, because the service shouldn't really care about that, only that the user is authenticated and authorized.
    - 0x457 4y ago
      The security Key could also be a Bluetooth-enabled security key or pixel phone.
  - Karellen 4y ago
    > Infrastructure to handle authentication on the web already exists. Email does not run over the web, it runs over the internet. It uses a completely different set of protocols from the web, which were all invented at least 5 years before the first web protocol. Why should email clients be required to add HTTP support in order to make email work? Maybe we should take heed of Zawinski's Law, and make all web browsers implement native email clients instead. Yeah, that's probably it. The Netscape Communicator/Mozilla Suite model should never have been dropped, and it was a mistake to separate Firefox and Thunderbird as separate projects! /s
- magicalhippo 4y ago
  > What's wrong with adding a simple challenge-response protocol for FIDO2/U2F USB drives? Or a TOTP popup if you don't have a physical security key? Our application send mails on behalf of our customers. This is done in an on-prem background service running on one of their servers wherever that might be. So, anything interactive is a no-go. And installing a physical USB key is probably a no-go for most customers, especially those who have their servers hosted by a provider.
- GoblinSlayer 4y ago
  Client certificate authentication can be done with any TLS, at least it already was in TLS 1.0 published in January 1999, even before SNI.
timbit42 4y ago
Yeah, but they use SMS 2FA which is not secure.
- advisedwang 4y ago
  Google offers FIDO, and even has an "advance protection" program to enforce only FIDO as 2nd factor.
Semaphor 4y ago
> a) password doesn't support 2nd factor. FWIW, there’s the hacky way reddit clients authenticate: "password:OTP" instead of just your normal password. Not that MS could do that, but I wanted to mention the option ;)
nottorp 4y ago
Whatever their reasoning, it means i have to have an email client and a browser to log in. Can't say I like that.

jeroenhd 4y ago

a) is only relevant once, during setup; b) isn't fixed by Oauth; c) is by design, I'd argue. I support adding 2FA to email in some way, but I heavily dislike using browsers to do so. What's wrong with adding a simple challenge-response protocol for FIDO2/U2F USB drives? Or a TOTP popup if you don't have a physical security key? This can all be standardised without a browser ever touching the email client. We already have IMAP authentication methods that use signatures (like most 2FA hardware keys use) or challenge/response methods. You can even do client certificate authentication through STARTTLS when lacking a TPM.

0x457 4y ago
> What's wrong with adding a simple challenge-response protocol for FIDO2/U2F USB drives? Or a TOTP popup if you don't have a physical security key? Infrastructure to handle authentication on the web already exists. This is a massive benefit for providers and client developers. Whatever you propose does not. Good luck convincing big email providers to agree on a new standard like that. GitHub alone has like 5 different ways to handle 2FA. Google has, I think, 3? Using a browser to handle this simplifies things a lot. b) While it's not fixed by Oauth it greatly limits what can happen: — First, you only need to store a refresh token that can expire and that expiration can be controlled by administrator — Second, that token has limited scope: password provides access to entire account — Third, it's clear where it came from — if token gets compromised, you will know where it happened. With password, it's unclear.
- jsnell 4y ago
  > Google has, I think, 3? There's at least: 1. SMS 2. TOTP 3. Google Prompt (on Android / iOS) 4. Offline security codes (distinct thing from TOTP, generated from Android settings) 5. Backup codes 6. Security Key
  - magicalhippo 4y ago
    Do you have some documentation for this? All I could find[1] pointed to them only supporting OAuth, similar to Microsoft. [1]: https://developers.google.com/gmail/imap/imap-smtp https://developers.google.com/gmail/imap/imap-smtp
    - jsnell 4y ago
      I didn't mean that they had native IMAP support for those, but that these are the 2FA methods they support in general. With browser-based OAuth, it's viable to build support for a new 2FA method in just one place. Needing to build each of these into a protocol + get all popular IMAP clients to implement that support? It'd take an eternity; we'd probably still be stuck on just TOTP.
      - magicalhippo 4y ago
        Ah yes, my misunderstanding. Indeed, OAuth makes it easy to swap out the actual authentication step. Which is nice, because the service shouldn't really care about that, only that the user is authenticated and authorized.
  - 0x457 4y ago
    The security Key could also be a Bluetooth-enabled security key or pixel phone.
- Karellen 4y ago
  > Infrastructure to handle authentication on the web already exists. Email does not run over the web, it runs over the internet. It uses a completely different set of protocols from the web, which were all invented at least 5 years before the first web protocol. Why should email clients be required to add HTTP support in order to make email work? Maybe we should take heed of Zawinski's Law, and make all web browsers implement native email clients instead. Yeah, that's probably it. The Netscape Communicator/Mozilla Suite model should never have been dropped, and it was a mistake to separate Firefox and Thunderbird as separate projects! /s
magicalhippo 4y ago
> What's wrong with adding a simple challenge-response protocol for FIDO2/U2F USB drives? Or a TOTP popup if you don't have a physical security key? Our application send mails on behalf of our customers. This is done in an on-prem background service running on one of their servers wherever that might be. So, anything interactive is a no-go. And installing a physical USB key is probably a no-go for most customers, especially those who have their servers hosted by a provider.
GoblinSlayer 4y ago
Client certificate authentication can be done with any TLS, at least it already was in TLS 1.0 published in January 1999, even before SNI.

timbit42 4y ago

Yeah, but they use SMS 2FA which is not secure.

advisedwang 4y ago
Google offers FIDO, and even has an "advance protection" program to enforce only FIDO as 2nd factor.

Semaphor 4y ago

> a) password doesn't support 2nd factor. FWIW, there’s the hacky way reddit clients authenticate: "password:OTP" instead of just your normal password. Not that MS could do that, but I wanted to mention the option ;)

nottorp 4y ago

Whatever their reasoning, it means i have to have an email client and a browser to log in. Can't say I like that.