2FA in SOGo

[Braintelligence]

Hello everyone,

is it possible to provide 2FA (especially FIDO U2F) in SOGo and registering of 2FA for that purpose in the mailcow UI for each address by easy means?

It would be awesome if you could create a mailcow-configuration where accessing your stuff is only possible with usage of 2FA. This would create secure groupware environments for data-sensitive applications.

[mkuron]

You‘d need to do that on the Nginx level. I don‘t think SOGo provides hooks for that. Also, you‘d need to disable IMAP access as that protocol doesn‘t support any kind of 2FA but gives full access to your mailbox.

[Braintelligence]

Yeah I wanted to disable remote IMAP access when using such a configuration.

I don't see the connection to NGINX, though, yet. Is U2F handled by NGINX?

[mkuron]

Nginx is a proxy in front of SOGo. You could handle the 2FA on the proxy. You probably can‘t do it in SOGo because it doesn‘t support it. Of course, you could file a feature request with SOGo. You‘d lose many other features though (calendar and contacts syncing with smartphones for example), so this is something you’d likely only want to do in a high-security environment.

[Braintelligence]

Yes, I would need this for a high-security environment.

But as a sidenote: There are NFC-capable FIDO U2F-keys, so theoretically you also could be able to use it via NFC-capable-Smartphone as long as you access SOGo via U2F-capable browser or specifically prepared app.

[Braintelligence]

It's funny how SOGo says requesting features is a form of contribution but doesn't specify a way of how to request features... https://github.com/inverse-inc/sogo

Should I hit up the mailing list for this or is there a better spot for requests?

[mkuron]

THere already are feature requests for that: https://sogo.nu/bugs/view.php?id=2722, https://lists.inverse.ca/sogo/arc/users/2016-10/msg00095.html . The only thing you can do to speed things up is to implement it yourself and submit the patch to the developers.

[Braintelligence]

I'm content knowing that the request was already made, thank you so much for looking it up. 👍

I think incorporating FIDO U2F into webmail clients and mail apps (especially also via NFC) is the next big thing in mail-security.

I have a dream that someday I will stick my Yubikey into my PC for fetching my mails in Thunderbird 😸.

[mkuron]

I don’t think that will happen any time soon. There are so many email clients out there and IMAP, SMTP, CardDAV/CalDAV don‘t currently define any way of providing a second factor. An alternative that already works is app-specific passwords: your email client authenticates to the server not with the user‘s password, but with a very long token that was generated when the client was first configured. The user doesn‘t have this token memorized and ideally his client device is full-disk encrypted, so an attacker will have a hard time of getting the token. Alternatively, TLS client certificates could be used (these can even be stored on a Yubikey and are supported by Thunderbird and others).

[Braintelligence]

The specification for WebSockets was theoretically available since the HTML5-specification on such TCP-connections after its naming in 2008. It took almost till 2012 till RFC 6455 hit most of the relevant browsers and allowed widespread usage of it and then some years for popular frameworks to adapt it.

So if 2FA finds its way to E-Mail in the next 10 years I'm alright with it ;).

[Braintelligence]

@andryyy Did you get my mail on info@servercow ?

[andryyy]

Can you mail me again, @Braintelligence?

[Braintelligence]

@andryyy Just did. Maybe you're blocking my domain for some reason? :P

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[phatina]

Any news about this feature?

[Adorfer]

Having 2FA would be really nice.

[andryyy]

How would you implement this with IMAP?

This is also not mailcow related but SOGo. :-)

[Braintelligence]

How would you implement this with IMAP?

I thought SOGo was also using SQL with mailcow? Is it not viable to store 2FA in there and link it to SOGo? I mean is SOGo even capable of using 2FA natively, and if yes, where does it get the seed/whatever from?

[andryyy]

What do you want to secure with TFA here? Calenders, contacts, mails cannot be protected by TFA for obvious reasons. So ... you could protect the settings, I guess. Even filters are available via sieve.

It's something different when you decide to ONLY use SOGo and hide all services from public access. Then again, you need to ask SOGo to implement it.

[mkuron]

If you disable IMAP, POP and SMTP access and only leave SOGo webmail open, you could do it relatively easy. SOGo can delegate authentication to external services, like a SAML IdP or OAuth (which Mailcow could conceivably provide), so you don‘t need the feature integrated into SOGo. You would also lose CalDAV, CardDAV and EAS access.

Since nobody wants to give up mobile devices and native email clients to use exclusively webmail, I see no value in 2FA for mail — and as far as I can see, no email provider is doing it. Using 2FA for webmail and application-specific passwords (which I mentioned above) would be a more reasonable solution.

There is a specification for OAuth for IMAp with OAuth (I think Google uses that), but I‘m not sure if Dovecot supports it and which email clients can use it.

[Braintelligence]

D'accord. Thus my comment https://github.com/mailcow/mailcow-dockerized/issues/740#issuecomment-343769265 . Yeah, my earlier comment was about the idea of using SOGo exclusively as only client for everything (if you absolutely demand 2FA for your mail stuff). Next step could have been some kind of abstraction to SOGo instead of IMAP/SMTP in form of a native SOGo app that would support 2FA on mobile as well. (Does SOGo Connector support 2FA?) But that's not anywhere close to the scope of mailcow, it's SOGo stuff that SOGo could look at 😎.

[Adorfer]

this request ist about 2FA in Sogo, not about 2FA in imap/webcal etc. (this is why i do not ask about 2FA for mailcow webconsole in this issue either.)

[andryyy]

Create a feature request in SOGo then? ;-)

[Braintelligence]

@andryyy Is it actually possible to link a mailcow user account with SAML-authentication for SSO-purposes?

[andryyy]

Yes, with simplesaml for example. Needs to be implemented in SOGo and Dovecot then. The Dovecot part would be tricky.

If you like to live dangerously, you can store the credentials in the session. :O

[Braintelligence]

Those meme-nostalgia-feels!

Well, I'm just eyeballing using mailcow-dockerized with a lot of other stuff together with the open-source SSO-solution https://gluu.org/

It looks and sounds fantastic and also provides a free smartphone 2FA-tool. It supports

• OAuth 2.0
• OpenID Connect
• User Managed Access 2.0 (UMA)
• SAML 2.0
• System for Cross-domain Identity Management (SCIM)
• FIDO U2F & UAF
• Lightweight Directory Access Protocol (LDAP)

Gluu would make a nice addition to mailcow-dockerized as part of a modern groupware-solution, as well, don't you think? Maybe we could even leverage the LDAP-functionality of SOGo in the long run then, too :joy_cat: .

Well, that's just my wishful thinking :sunglasses:

EDIT: Here's an example docker-compose.yml btw: https://github.com/GluuFederation/gluu-docker/blob/3.1.4/examples/single-host/docker-compose.yml

[andryyy]

We offer LDAP authentication in managed mailcows.

[Braintelligence]

But that doesn't provide an exposition for SSO on other web services, right?

Could we leverage the OAuth2 interface of Gluu for Dovecot with this: https://wiki.dovecot.org/PasswordDatabase/OAuth2 ?

[andryyy]

We can also integrate SSO in managed mailcows.

[Braintelligence]

I see where this is going. Any objections to pull requests integrating Gluu (or similar) with mailcow-dockerized, just for the case that anyone feels up for it?

[andryyy]

This will not work. Gluu is a full IAM plattform, we can use it with mailcow, but we cannot integrate it in mailcow: dockerized.

[Braintelligence]

I meant integrating it within the ecosystem by adding it to the docker-compose.yml and altering configuration files accordingly if a specific ENV variable is set, for example, so it would be accessible on a given domain and already intertwined with mailcow UI, SOGo and Dovecot (EDIT: and Nextcloud) at the necessary points.

[andryyy]

It is possible, but it is very complicated, I guess. SSO over all services is not easy, I also don't see a reason to add Gluu or another IAM, I just ... don't need it. A PR is fine with me, sure, as long as the guy to push it also supports it in the future.

You could also install a stack of Rspamd, Dovecot, Postfix etc. without mailcow and only use Gluu/LDAP in general as identitiy provider with all information like groups/aliases/quota stored in the IAM. That's what most business customers ask for (via LDAP then). These are custom setups that heavily depend on the given infrastructure.

For those interested, just write a mail. \o/

[Braintelligence]

Thanks for leaving open the possibility for a feature pr :).

[andryyy]

Sure. Why not?

[andryyy]

Another idea: Unlocking the account when logging in to mailcow. As long as your session with mailcow UI is valid, your mail account is unlocked. Or unlocking it for a user-defined time.

[Braintelligence]

Maybe combine both for safety reasons? But yeah, why not? 😼

[SomeGeek]

Sorry for being late to the party. I thought about this as well.

What about the following?

First of all, we disable logging in with user credentials to smtp, imap, eas, etc. Basically every non-webbased service.

For every web based service (like roundcube, SoGo), we require 2FA. Or at least, it isn't hard to support 2FA when the respective maintainers add it. I read that SoGo already supports 2FA using SAML2 by, eg., using keycloak. However I reckon integrating something like this might not be a trivial task.

So, for the other services, we switch to a token-based model. If you want to use native clients, you first generate a token in the webinterface for the specific services you need (or all of them to start with). I haven't read into this, but it might be possible to tailor it down even more. Like: computer X uses token Y for mailbox foo@bar.com to access SMTP and IMAP.

I think something like this is already much better then the username/password used right now.

[chriscroome]

This is a bit of a tangent but the only thing I have thought of that would help here (I have been pondering about this matter for some months) is if the Mailcow server is set not to allow unencrypted HTTP, POP, IMAP or HTTP traffic (apart from Let's Encrypt verifications) and then Mailcow was set not to expose mailbox usernames in email headers (and I guess some things would need configuring with SOGo for this, or perhaps Postfix could simply clean the headers up) then you could use random strings for usernames, for example your login could be:

hD6YvCbxeEfDe2NtjJz3gijSOmLwvPXv@example.org

And your email address could be:

foobar@example.org

And if the string hD6YvCbxeEfDe2NtjJz3gijSOmLwvPXv cannot be found in any outgoing email headers then for someone to brute force your email account they need to brute force the username before they can then brute force the password and if long random local usernames are used then it would basically become impossible to brute force and once again the weak point would be the MUAs.

The advantage with this approach is that all existing MUAs would still work — adding 2FA to all existing SMTP and IMAP MUAs in an agreed manner might take a while…

[andryyy]

Just don't expose imap, smtp etc. and use Roundcube with a plugin for TFA. :o That's the easy way right now.

We could integrate SSO into SOGo (not easy) and only allow logins from within mailcow UI, after TFA has been verified. Yes, this also means not to expose imap, smtp etc. to the public.

[SomeGeek]

Just don't expose imap, smtp etc. and use Roundcube with a plugin for TFA. :o That's the easy way right now.

@andryyy

I think it will be quite easy to do a small part of what I mentioned, actually. But it's a good start.

Provide the ability to generate tokens on the users' web interface. Save this to a token table in the database. Change the query where postfix/dovecot/etc looks for the passwords, direct them to that table instead. Or am I missing something here?

[andryyy]

So you need to generate a token (which ttl?) every time you login with a mail client?!

Much better to just unblock the mailbox when TFA was verified via UI.

AND splitting the behavior of web based clients (native TFA) and external clients?! No way.

I think the best method is to just unblock the services with mailcow UI for a given time. It still sucks... how long is a session valid? You cannot login once and trash the token. The password/login needs to be valid as long as you use mail. Your client will not login once and keep the connection open for imap, smtp etc. as long as you are logged in. That's not how it works. Your client will login several times for each action. And for as long as you are using mail, the password/account needs to be unlocked.

[chriscroome]

One additional security feature that would work for me would be to have optional whitelists of IP addresses that are allowed for each mailbox for authenticated SMTP and IMAP, potentially the whitelist could be linked to 2FA?

[SomeGeek]

@andryyy

You sound so negative. Google uses exactly the same method for their Gmail accounts.

This token has a infinite lifetime, until the user deletes it. Also, in the future, we can display activity logs for a given token.

Much better to just unblock the mailbox when TFA was verified via UI.

So you need to login on a web interface to use a native client... which is there because someone prefers it over a web interface in the first place? Hmmm.

AND splitting the behavior of web based clients (native TFA) and external clients?! No way.

This is already the case. Mailcow UI has 2FA, everything else doesn't. My proposal allows to add 2FA to the online clients when they support it (or we implemented something to make it work). In the meantime, we solve the problem existing MUA's do not support 2FA given their permanent nature by tokens. If a machine gets compromised, you just retract that token... in a environment you can only access using 2FA.

I should clarify that these tokens are a addition to the passwords / 2FA, not replacements. The tokens are for long term usage, like desktop MUA's.

I think this might be a very solid solution which is not that hard to implement.

[andryyy]

I don't think you understand what I mean.

"Google uses exactly the same method for their Gmail accounts." No. I think you miss many, many points here.

Just create a PR, please.

[Brightside56]

@andryyy , will you merge it if I create PR or will say "no, it doesn't fit"?

It can be implemented as written here

https://github.com/mailcow/mailcow-dockerized/issues/740#issuecomment-459328861

All IPs blocklisted by default for IMAP when 2FA is enabled as strict. Whitelisting of IP happens when user is passing 2FA in webui. IMAP server needs to return some message which will point user that 2FA needed

[andryyy]

It would be very cool to know how you plan to implement it. :)

Re-use existing mechanisms and no dirty hacks to implement it "some how" (that's what I'm afraid of as most things can be implemented fairly easy if they are hacky).

I think @mkuron agrees, that it would be great to see a plan before working on it. :)

[mkuron]

One could build upon ALLOW_ADMIN_EMAIL_LOGIN (#2388) to easily put 2FA in front of SOGo‘s web interface.

As for IMAP/SMTP, I don‘t think IP or time-based whitelisting is a good option. It‘s annoying when you change networks (e.g. on your smartphone) and it‘s insecure when you share IP addresses (e.g. on cellular networks). People will activate 2FA, find it super annoying, and deactivate it again.

Also, CardDAV/CalDAV/EAS would need it too, but there it‘s difficult because SOGo doesn‘t have an IP whitelist and Nginx doesn‘t know the authenticated user. Switching off IMAP/SMTP/DAV/EAS to get "full" 2FA is also not a good suggestion as it makes Mailcow significantly less useful.

I think the only proper solution would be to introduce application-specific passwords for IMAP/SMTP/DAV/EAS first. Long, randomly generated passwords that you can use when you set up your client, but don‘t need to memorize or write down. That‘s what Gmail does too. Only then does it make sense to implement 2FA for SOGo. Since all password validation is done in SQL queries, I guess it wouldn’t be that difficult to implement app-specific passwords.

[SomeGeek]

I think the only proper solution would be to introduce application-specific passwords for IMAP/SMTP/DAV/EAS first. Long, randomly generated passwords that you can use when you set up your client, but don‘t need to memorize or write down. That‘s what Gmail does too. Only then does it make sense to implement 2FA for SOGo. Since all password validation is done in SQL queries, I guess it wouldn’t be that difficult to implement app-specific passwords.

This is exactly what I proposed earlier:

So, for the other services, we switch to a token-based model. If you want to use native clients, you first generate a token in the webinterface for the specific services you need (or all of them to start with). I haven't read into this, but it might be possible to tailor it down even more. Like: computer X uses token Y for mailbox foo@bar.com to access SMTP and IMAP.

If something goes wrong or a 'token' comes, for any reason, in the 'wrong' hands, you can just delete / reset that token. Would be great if it keeps track of those, so you know when and at what IP it was last used.

Indeed, more services use this too (like Gmail) and it seems to me like a very solid system. Especially because it doesn't break the clients, the token is still your 'password'. Only you have one for each devices, with more tools to manage it on the server side.

[immanuelfodor]

Huge +1 for making this change in an incremental fashion, first introducing app specific passwords/tokens. I always feel weird/insecure when I need to use the one and only account password everywhere (Android, scripts, etc).

[andryyy]

App specific passwords are fine.

I will probably implement it.