4 ms·

Msmtp: About Authentication Methods

36 points by JetSpiegel 6y ago

dane-pgp 6y ago
> In other words: the user must be educated, you cannot solve this problem with technical means. Educating users not to do insecure things doesn't really scale well, and hasn't exactly had a great track record. Defence in depth, however, is a well-established and successful security strategy.
networkimprov 6y ago
If anyone's interested in a modern rethink of SMTP, here's TMTP: Why TMTP? https://mnmnotmail.org/rationale.html https://mnmnotmail.org/rationale.html Protocol draft: https://github.com/networkimprov/mnm/blob/master/Protocol.md https://github.com/networkimprov/mnm/blob/master/Protocol.md Twitter: https://twitter.com/mnmnotmail https://twitter.com/mnmnotmail
- dane-pgp 6y ago
  > Every organization, whether tiny or enormous, needs a members-only messaging service that cannot receive traffic from external or unapproved senders. > Organizations that need to let certain members hear from the general public, or communicate with untrusted (perhaps anonymous) customers, may establish a separate service instance for that purpose. Rather than throwing away all existing email clients and servers, couldn't this be achieved by configuring an inbound mail rule to drop all email from addresses that aren't in your address book (and from servers that don't support DKIM)? It doesn't seem very meaningful to say "Users should only receive messages from approved senders, unless they need to receive messages from unapproved senders". Email is useful precisely because it doesn't have the extra step of requiring users to manually add an address to their address book before receiving a message from a new contact, such as a receipt from an online purchase.
  - networkimprov 6y ago
    Thanks for your question. There's a lot more to TMTP than limiting who can send you arbitrary content. One of its features is that your correspondence does not transit a TMTP server operated by a third party. As with HTTP, its client connects directly to the ultimate host. Re "users should only receive..." TMTP allows arbitrary content only from approved senders, and limited content from others (see Ping & GroupInvite). There's no manual addition to your address book on the receiver's part.
    - dane-pgp 6y ago
      Thanks for your response. I sort of like the idea of restricting the content that can be sent by unapproved senders, and wonder if this could be adopted by email systems. Suppose that the major email service providers and client developers agreed that from a certain date, all emails received from addresses that a user had not seen before would be truncated to 256 plaintext Unicode characters. The client UI would offer the option to whitelist that sender for future messages, which would also cause the existing message to be displayed in full.
      - networkimprov 6y ago
        Goodness; and here I thought mnm was ambitious! :-) I think we'll see better results by defining and implementing a simple new protocol that addresses all of the significant security and productivity problems with email. Note, the current draft isn't a 1.0 candidate; there's more to come, for instance meta-messages.
        dane-pgp 6y ago
        Unfortunately, it's easier to get half a dozen entities to agree on something which is aligned with their incentives (a small UI change to make email more usable) than to get literally billions of users and systems to switch to a completely new technology which offers at best an incremental improvement over email.
        networkimprov 6y ago
JohnCClarke 6y ago
Good questions @JetSpiegel! Prompted me to search for & read the SCRAM wiki page. Found the answers there. SCRAM helps by adding independent checks on server identity and channel security. So: if you 100% trust the TLS CA, cert, and implementation then indeed, nothing gained. But 100% trust is risky in cyber security...
- hoppla 6y ago
  That’s my conclusion too. It seems like SCRAM prevents complete security failure if TLS fails (rouge certificate)
jimis 6y ago
I would personally want to see the opposite: disable PLAIN or LOGIN or HTTP basic auth methods or plaintext HTML password-entry forms, and never ever send a password without a digest challenge-response method, even over TLS. Of course first the browsers would have to implement safer alternatives: https://bugzilla.mozilla.org/show_bug.cgi?id=472823 https://bugzilla.mozilla.org/show_bug.cgi?id=472823 https://bugs.chromium.org/p/chromium/issues/detail?id=1160478 https://bugs.chromium.org/p/chromium/issues/detail?id=116047... Why? Because I can't trust all the 100s of companies and I login to, and their 1000s of employees. I don't want them to choose storing my password securely or not. I want them to be forced to do that. Like I choose "HTTPS everywhere", I want to choose "SCRAM-SHA-512 everywhere" or similar. It's technology that has to provide me guarantees, and user education must only complement that. Unfortunately we are far from that. Passwords are flying plaintext-inside-HTTPS, with various risks: * database storing passwords insecurely * passwords being stolen on the authenticating server (either because of server being pwned or from internal eyes). * passwords flying fully in plaintext (no TLS) in the internal network behind the authenticating server. * self-signed HTTPS MITM attacks on already self-signed-cert websites (especially dangerous on intranet websites inside companies; you'd be surprised how difficult it is to setup proper PKI and internal CAs).
- jcranmer 6y ago
  There is value in using PLAIN inside of TLS instead of SCRAM-* methods. If you use SCRAM-, you're committing your password storage to only* use that method for storing the plaintext. So if you were state-of-the-art 20 years ago and used CRAM-MD5, and then you wanted to upgrade to SCRAM-SHA-1 when that came out... you don't have a good migration story, since the password storage has the information needed to validate CRAM-MD5 but not SCRAM-SHA-1, and there's no way to regenerate the information for SCRAM-SHA-1 without the plaintext password. But if the authentication server gets the plaintext password, it can validate it against the old CRAM-MD5 storage, see that it matches, and then update the storage to SCRAM-SHA-1 on the fly. The entire process is invisible to the user, who gets a security upgrade in the process. There's another class of use-cases, where a service needs to authenticate a user based on a token from another service. But for this, it's better to dispense with passwords entirely and instead go to something like Kerberos, where the authentication service gives you tokens in lieu of any password information.

36 points by JetSpiegel 6y ago

> In other words: the user must be educated, you cannot solve this problem with technical means. Educating users not to do insecure things doesn't really scale well, and hasn't exactly had a great track record. Defence in depth, however, is a well-established and successful security strategy.

networkimprov 6y ago

If anyone's interested in a modern rethink of SMTP, here's TMTP: Why TMTP? https://mnmnotmail.org/rationale.html https://mnmnotmail.org/rationale.html Protocol draft: https://github.com/networkimprov/mnm/blob/master/Protocol.md https://github.com/networkimprov/mnm/blob/master/Protocol.md Twitter: https://twitter.com/mnmnotmail https://twitter.com/mnmnotmail

dane-pgp 6y ago
> Every organization, whether tiny or enormous, needs a members-only messaging service that cannot receive traffic from external or unapproved senders. > Organizations that need to let certain members hear from the general public, or communicate with untrusted (perhaps anonymous) customers, may establish a separate service instance for that purpose. Rather than throwing away all existing email clients and servers, couldn't this be achieved by configuring an inbound mail rule to drop all email from addresses that aren't in your address book (and from servers that don't support DKIM)? It doesn't seem very meaningful to say "Users should only receive messages from approved senders, unless they need to receive messages from unapproved senders". Email is useful precisely because it doesn't have the extra step of requiring users to manually add an address to their address book before receiving a message from a new contact, such as a receipt from an online purchase.
- networkimprov 6y ago
  Thanks for your question. There's a lot more to TMTP than limiting who can send you arbitrary content. One of its features is that your correspondence does not transit a TMTP server operated by a third party. As with HTTP, its client connects directly to the ultimate host. Re "users should only receive..." TMTP allows arbitrary content only from approved senders, and limited content from others (see Ping & GroupInvite). There's no manual addition to your address book on the receiver's part.
  - dane-pgp 6y ago
    Thanks for your response. I sort of like the idea of restricting the content that can be sent by unapproved senders, and wonder if this could be adopted by email systems. Suppose that the major email service providers and client developers agreed that from a certain date, all emails received from addresses that a user had not seen before would be truncated to 256 plaintext Unicode characters. The client UI would offer the option to whitelist that sender for future messages, which would also cause the existing message to be displayed in full.
    - networkimprov 6y ago
      Goodness; and here I thought mnm was ambitious! :-) I think we'll see better results by defining and implementing a simple new protocol that addresses all of the significant security and productivity problems with email. Note, the current draft isn't a 1.0 candidate; there's more to come, for instance meta-messages.
      - dane-pgp 6y ago
        Unfortunately, it's easier to get half a dozen entities to agree on something which is aligned with their incentives (a small UI change to make email more usable) than to get literally billions of users and systems to switch to a completely new technology which offers at best an incremental improvement over email.
        networkimprov 6y ago

JohnCClarke 6y ago

Good questions @JetSpiegel! Prompted me to search for & read the SCRAM wiki page. Found the answers there. SCRAM helps by adding independent checks on server identity and channel security. So: if you 100% trust the TLS CA, cert, and implementation then indeed, nothing gained. But 100% trust is risky in cyber security...

hoppla 6y ago
That’s my conclusion too. It seems like SCRAM prevents complete security failure if TLS fails (rouge certificate)

jimis 6y ago

I would personally want to see the opposite: disable PLAIN or LOGIN or HTTP basic auth methods or plaintext HTML password-entry forms, and never ever send a password without a digest challenge-response method, even over TLS. Of course first the browsers would have to implement safer alternatives: https://bugzilla.mozilla.org/show_bug.cgi?id=472823 https://bugzilla.mozilla.org/show_bug.cgi?id=472823 https://bugs.chromium.org/p/chromium/issues/detail?id=1160478 https://bugs.chromium.org/p/chromium/issues/detail?id=116047... Why? Because I can't trust all the 100s of companies and I login to, and their 1000s of employees. I don't want them to choose storing my password securely or not. I want them to be forced to do that. Like I choose "HTTPS everywhere", I want to choose "SCRAM-SHA-512 everywhere" or similar. It's technology that has to provide me guarantees, and user education must only complement that. Unfortunately we are far from that. Passwords are flying plaintext-inside-HTTPS, with various risks: * database storing passwords insecurely * passwords being stolen on the authenticating server (either because of server being pwned or from internal eyes). * passwords flying fully in plaintext (no TLS) in the internal network behind the authenticating server. * self-signed HTTPS MITM attacks on already self-signed-cert websites (especially dangerous on intranet websites inside companies; you'd be surprised how difficult it is to setup proper PKI and internal CAs).

jcranmer 6y ago
There is value in using PLAIN inside of TLS instead of SCRAM-* methods. If you use SCRAM-, you're committing your password storage to only* use that method for storing the plaintext. So if you were state-of-the-art 20 years ago and used CRAM-MD5, and then you wanted to upgrade to SCRAM-SHA-1 when that came out... you don't have a good migration story, since the password storage has the information needed to validate CRAM-MD5 but not SCRAM-SHA-1, and there's no way to regenerate the information for SCRAM-SHA-1 without the plaintext password. But if the authentication server gets the plaintext password, it can validate it against the old CRAM-MD5 storage, see that it matches, and then update the storage to SCRAM-SHA-1 on the fly. The entire process is invisible to the user, who gets a security upgrade in the process. There's another class of use-cases, where a service needs to authenticate a user based on a token from another service. But for this, it's better to dispense with passwords entirely and instead go to something like Kerberos, where the authentication service gives you tokens in lieu of any password information.