6 ms·

> For those who want multi-domain email services for a lower (flat) price, look at mxroute I was very interested and very seriously considering signing up, unt

by spinax 5y ago

> For those who want multi-domain email services for a lower (flat) price, look at mxroute I was very interested and very seriously considering signing up, until I read this: https://mxroute.com/docs/do-you-support-2fa-on-email-accounts/ https://mxroute.com/docs/do-you-support-2fa-on-email-account... While I respect Jarland's opinion/stance, I do not agree.

hellcow 5y ago
What do you disagree with specifically? The reasoning in that link is absolutely correct. We can argue that POP, etc. should have 2FA support added to the protocol, but that's not the point the author was making.
- arp242 5y ago
  Loads of folk use just webmail though, and SMTP/IMAP is usually disabled until they generate an app password. If you do enable SMTP/IMAP: sure, it's correct. But that often doesn't apply, so I don't think it's a "trick" or "sleight of hand".
- spinax 5y ago
  Use case: I have an unattended cron task polling my IMAP account to archive the mail every 4 hours. I specifically use an IMAP read-only unique ("per-app") password for that script/connection; under no circumstance should that password have access to write to IMAP, touch POP or SMTP. Fastmail allows me to do this with ease, and I can create as many as I'd like with different ACLs. The mxroute reasoning simply does not consider all the use cases people have and want per-app passwords for to increase their personal security posture.
  - Raineer 5y ago
    The ease of creation of app passwords and protocol-level controls really are fantastic in Fastmail. I hope it never goes away.
  - deleted 5y ago
    [deleted]
- ampdepolymerase 5y ago
  Compromising a user password does not grant access to the web client (where all the important settings are at) if 2fa is enabled. App specific password only allows data exfiltration and most enterprise email servers/authz systems can be configured to automatically block access from VPNs/foreign ips. These days emails are tied into calendar and Oauth and many other things, blocking access to the inbox is just one layer in a very a big picture.
- jasonjayr 5y ago
  Modern IMAP servers support OAuth2/OIDC, (Thunderbird supports this dialog) and IMAP/POP/SMTP has supported kerberos since forever (Though that typically is only within a pre-setup organization).
  - jarland 5y ago
    The problem is that a very significant number of email clients don't because it's not part of the open standards that they're implemented for.
- joshka 5y ago
  This advice is incorrect from a security perspective. > While many offer this, no one tracks them, and they can’t be limited to just the app (because, again, the protocols don’t work this way). So if your account gets compromised and you have 50 passwords, what do you do besides delete all 50 passwords and start over? Delete them one at a time and see how long it takes for spam to stop going out from your account? Reduce server security and log which password is being used (because that’s the only way to gain that insight from the universal protocols)? 1. Give the passwords names that identify the client app 2. Track that name / login / actions - it's not less secure to track browser type on the web, the equivalent is what's happening here (that's iPhone1, thunderbird on my mac, ...) 3. Present this information to the account user. I should have access to the logs of who's accessing my data. 4. If your account has 50 passwords, it has 50 clients that you have to delete and start over on. Same as if you'd used a single password on all 50 clients.
  - jarland 5y ago
    How do you track the name without tracking the password itself? The IMAP standard doesn't provide a function for this. You'd have to log the password used and do it that way. It'd be hard to implement such a thing with the base protocol without adding a security concern. Then again I'm not a software developer, I'm an admin and hope to be hiring a dev this year. MXroute works mostly on open source or licensed software, with a heavy focus on custom in-house configuration being around the outbound relays, as the initial focus of MXroute was based on getting emails to their recipients, no matter the cost. These days, that's increasingly difficult and time consuming for a lot of people (IP reputation, etc).
    - joshka 5y ago
      I'm a dev not an admin. Change your password query from something like (pseudo code) SELECT username, ... FROM applications WHERE username = ? AND password = MD5(?) to SELECT username + ' ' + applicationName FROM ... (as above) Then log the user name for each session, or return an extra field that is the app name when doing a password check (assumes your MX can do this). This is the general idea, and it's more pointing out why the advice is wrong, than talking about how to fix it and make it possible.
jarland 5y ago
And that's totally cool. I think a lot of alternate perspectives around this focus on proprietary implementations, and my focus revolves mostly around open source and licensed software. MXroute isn't a software vendor, and this confuses a lot of people because there are a lot of mail providers out there that are. Google and Microsoft are easy examples.
- spinax 5y ago
  Completely understood by me, hopefully I said this in a way that was productive. :) Per-app passwords have their use cases and I think techs have been banging on it in open source for awhile, example: https://www.happyassassin.net/posts/2014/08/26/adding-application-specific-passwords-to-dovecot-when-using-system-user-accounts/ https://www.happyassassin.net/posts/2014/08/26/adding-applic...

by spinax 5y ago

hellcow 5y ago

What do you disagree with specifically? The reasoning in that link is absolutely correct. We can argue that POP, etc. should have 2FA support added to the protocol, but that's not the point the author was making.

arp242 5y ago
Loads of folk use just webmail though, and SMTP/IMAP is usually disabled until they generate an app password. If you do enable SMTP/IMAP: sure, it's correct. But that often doesn't apply, so I don't think it's a "trick" or "sleight of hand".
spinax 5y ago
Use case: I have an unattended cron task polling my IMAP account to archive the mail every 4 hours. I specifically use an IMAP read-only unique ("per-app") password for that script/connection; under no circumstance should that password have access to write to IMAP, touch POP or SMTP. Fastmail allows me to do this with ease, and I can create as many as I'd like with different ACLs. The mxroute reasoning simply does not consider all the use cases people have and want per-app passwords for to increase their personal security posture.
- Raineer 5y ago
  The ease of creation of app passwords and protocol-level controls really are fantastic in Fastmail. I hope it never goes away.
- deleted 5y ago
  [deleted]
ampdepolymerase 5y ago
Compromising a user password does not grant access to the web client (where all the important settings are at) if 2fa is enabled. App specific password only allows data exfiltration and most enterprise email servers/authz systems can be configured to automatically block access from VPNs/foreign ips. These days emails are tied into calendar and Oauth and many other things, blocking access to the inbox is just one layer in a very a big picture.
jasonjayr 5y ago
Modern IMAP servers support OAuth2/OIDC, (Thunderbird supports this dialog) and IMAP/POP/SMTP has supported kerberos since forever (Though that typically is only within a pre-setup organization).
- jarland 5y ago
  The problem is that a very significant number of email clients don't because it's not part of the open standards that they're implemented for.
joshka 5y ago
This advice is incorrect from a security perspective. > While many offer this, no one tracks them, and they can’t be limited to just the app (because, again, the protocols don’t work this way). So if your account gets compromised and you have 50 passwords, what do you do besides delete all 50 passwords and start over? Delete them one at a time and see how long it takes for spam to stop going out from your account? Reduce server security and log which password is being used (because that’s the only way to gain that insight from the universal protocols)? 1. Give the passwords names that identify the client app 2. Track that name / login / actions - it's not less secure to track browser type on the web, the equivalent is what's happening here (that's iPhone1, thunderbird on my mac, ...) 3. Present this information to the account user. I should have access to the logs of who's accessing my data. 4. If your account has 50 passwords, it has 50 clients that you have to delete and start over on. Same as if you'd used a single password on all 50 clients.
- jarland 5y ago
  How do you track the name without tracking the password itself? The IMAP standard doesn't provide a function for this. You'd have to log the password used and do it that way. It'd be hard to implement such a thing with the base protocol without adding a security concern. Then again I'm not a software developer, I'm an admin and hope to be hiring a dev this year. MXroute works mostly on open source or licensed software, with a heavy focus on custom in-house configuration being around the outbound relays, as the initial focus of MXroute was based on getting emails to their recipients, no matter the cost. These days, that's increasingly difficult and time consuming for a lot of people (IP reputation, etc).
  - joshka 5y ago
    I'm a dev not an admin. Change your password query from something like (pseudo code) SELECT username, ... FROM applications WHERE username = ? AND password = MD5(?) to SELECT username + ' ' + applicationName FROM ... (as above) Then log the user name for each session, or return an extra field that is the app name when doing a password check (assumes your MX can do this). This is the general idea, and it's more pointing out why the advice is wrong, than talking about how to fix it and make it possible.

jarland 5y ago

And that's totally cool. I think a lot of alternate perspectives around this focus on proprietary implementations, and my focus revolves mostly around open source and licensed software. MXroute isn't a software vendor, and this confuses a lot of people because there are a lot of mail providers out there that are. Google and Microsoft are easy examples.

spinax 5y ago
Completely understood by me, hopefully I said this in a way that was productive. :) Per-app passwords have their use cases and I think techs have been banging on it in open source for awhile, example: https://www.happyassassin.net/posts/2014/08/26/adding-application-specific-passwords-to-dovecot-when-using-system-user-accounts/ https://www.happyassassin.net/posts/2014/08/26/adding-applic...