Webmail MFA/2FA

[catbird]

The Member Tools site can have MFA enabled, using TOTP (authenticator app): awesome.

But Webmail lacks any sort of added security. This would seem to be a significant security hole, for anyone who actually uses their Sonic email for other internet services. (Password gets compromised; malicious actor requests password reset email for other site; then can access that pw reset link for other site.)

I wonder if the folks at Sonic have any plans to add MFA (please not merely, insecurely, SMS-based) to the webmail service? Or, even a way for a user to turn off webmail access to their email account…

[virtualmike]

Or just the ability to define a separate password for mail access than for Member Tools.

[kgc]

Applying MFA to webmail itself is of little value since the underlying IMAP services would still be available without MFA (along with SMTP, POP3, FTP, these forums, shell services, etc.) Application specific passwords and exposing the ability for customers to restrict services to them is sadly the only practical solution until the protocols and clients themselves have been extended to support MFA.

[catbird]

Alright, sure. And it's entirely within scope of a malicious actor to attempt to compromise an email account via email protocols.

But what I'm bringing up issue is that a non-email protocol is offered for email accounts, that easily could employ MFA.

[kgc]

Alright, sure. And it's entirely within scope of a malicious actor to attempt to compromise an email account via email protocols.

But what I'm bringing up issue is that a non-email protocol is offered for email accounts, that easily could employ MFA.

There's no appreciable risk difference between what protocol or application is available, all of them are equally used as part of brute force attacks and all of them share much of the same rate limits and other protections against these attacks.

Once we have additional authentication controls in place, including application specific passwords, we'll be able to provide a set of features that will actually improve security. At that point, it may be that we'll be able to make further use of MFA at the web application level. This is in our road map now and I'd expect to see something within the next 12 months. As I mentioned in another thread, there is a lot of legacy weight that is carried around in our authentication systems that dates all of the way back to Dial Up PPP days (which is still in service!) that has to be accounted for and updated to work in new systems.

[ewhac]

Application specific passwords and exposing the ability for customers to restrict services to them is sadly the only practical solution until the protocols and clients themselves have been extended to support MFA.

You could always do client certificate-based connections over IMAPS.

"But not all email readers support client certs for IMAPS connections." Yup. But if your customer is already smart enough to ask about 2FA for email, then they're probably also smart enough to work out whether their mail reader supports client certs.

[kgc]

That's true, although it would take quite a bit of tooling to get that working on our end. It still leaves the other protocols exposed but would reduce the attack edge for access to email.