Webmail MFA/2FA

Internet access discussion, including Fusion, IP Broadband, and Gigabit Fiber!
7 posts Page 1 of 1
by catbird » Mon Aug 31, 2020 2:42 pm
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…
by virtualmike » Mon Aug 31, 2020 9:45 pm
Or just the ability to define a separate password for mail access than for Member Tools.
by kgc » Wed Sep 02, 2020 5:28 pm
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.
Kelsey Cummings
System Architect, Sonic.net, Inc.
by catbird » Thu Sep 03, 2020 6:18 pm
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.
by kgc » Fri Sep 04, 2020 11:31 am
catbird wrote:
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.
Kelsey Cummings
System Architect, Sonic.net, Inc.
by ewhac » Fri Sep 04, 2020 12:17 pm
kgc wrote:
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.
by kgc » Tue Sep 08, 2020 11:49 am
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.
Kelsey Cummings
System Architect, Sonic.net, Inc.
7 posts Page 1 of 1

Who is online

In total there are 12 users online :: 1 registered, 1 hidden and 10 guests (based on users active over the past 5 minutes)
Most users ever online was 999 on Mon May 10, 2021 1:02 am

Users browsing this forum: joeyyung911 and 10 guests