Hi,> Unfortunately the best way to do multifactor authentication today is to use OAUTH2, which isn't currently supported for own installations. Or you can use client certs. > > If you want to use some kind of MFA with tokens, you end up having to feed your token all the time. So the best option, for now, is device passwords.Client certs appears to be a good solution. What's the process for managing them with more than a hundred client accounts? I believe the problem they are trying to solve is hacked accounts from compromised passwords. Does client certs solve that problem? Perhaps there are dovecot (and postfix submission) options to at least restrict access by IP?
> Client certs appears to be a good solution. > > What's the process for managing them with more than a hundred client accounts?If you've got the budget ... MDM. If you don't, you can probably hack together some sort of self-service system.> > I believe the problem they are trying to solve is hacked accounts from > > compromised passwords. Does client certs solve that problem? >Well yes. If you make client certs mandatory, unless the client can present a valid cert, the server will kill the connection before the client has a chance to try out a compromised password.
Quoting Alex <mysqlstudent at gmail.com>:> Hi, > >> Unfortunately the best way to do multifactor authentication today >> is to use OAUTH2, which isn't currently supported for own >> installations. Or you can use client certs. >> >> If you want to use some kind of MFA with tokens, you end up having >> to feed your token all the time. So the best option, for now, is >> device passwords. > > Client certs appears to be a good solution. > > What's the process for managing them with more than a hundred client > accounts? > > I believe the problem they are trying to solve is hacked accounts from > compromised passwords. Does client certs solve that problem?Client certs would solve that - but you'll need some management around it (creation/deployment/renewal/device changes/etc). The easiest method is to run MDM and PKI infrastructure, but with 100 clients I kinda doubt that's in place and I wonder if they have the budget for it. Another option, not open source, but if you engage Recorded Future, you can get a report and notifications of password compromises, and then take action on that info (ie, force affected user to change password). Alternatively, and free, don't use the email address as the username for authenticaiton, use some other generic ID. Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20210715/232800cb/attachment-0001.html>
> Perhaps there are dovecot (and postfix submission) options to at least restrict access by IP?Restricting by IP is soon going to become very tedious, especially if you are dealing with more than a small number of users, and especially once post-COVID travel comes back and people start connecting from random hotels and airport lounges. If you don't fancy the idea of client certs, the alternative I would suggest instead of IP limiting would be a Wireguard VPN instead of IP limiting. Wireguard VPN servers run very quiet and won't respond to anything unless a client sends the right parameters. Of course the downside of a VPN compared to certificates is that the user will have to be aware and know how to manage a VPN, whilst with certificates it can all be quietly done in the background.
On 2021 Jul 15, at 08:52, Alex <mysqlstudent at gmail.com> wrote:> Client certs appears to be a good solution.A solution, certainly. A GOOD solution? Not really.> What's the process for managing them with more than a hundred client accounts?And that's the first issue. The second issue is "my primary device is not available, I need to login from this other computer or use my phone which is unsuitable for this task. Too bad I have no choice but to use the phone because this computer doesn?t have the cert." And then you have the "now that I've installed this cert, theis computer is considered trusted" which is another issue. 2FA is a lot more flexible and robust. OATH works well. SQRL looks promising though it requires a web UI I to do the authentication (and SQRL does away with passwords as well).> I believe the problem they are trying to solve is hacked accounts from > compromised passwords. Does client certs solve that problem?Maybe. Depends on if the hacker can get access to the user's machine or not.> Perhaps there are dovecot (and postfix submission) options to at least > restrict access by IP?It is certainly possible in Postfix, but that opens up its own issues. It may be acceptable in some corporate environs, but in most situations being able to access your email wherever you are is a requirement. -- The wages of sin is death, but so is the salary of virtue, and at least the evil get to go home early on Fridays. --Witches Abroad