I am looking to implement 2FA. I know of duo and eg. Eset secure authentication. But both solutions seem to be implemented in a strange way, that is they require some form of communication with either Duo or Eset servers. For Eset, I know that the system provisions users by sending them text message that originates at Eset servers and besides link to the phone app, it contains a unique token that enables either otp or push authentication. I have not been able to find any details on Duo but e.g. the following googled picture suggests, it works in a similar way. Push access requires the phones to access the Duo servers.

enter image description here

This means several things:

  1. the duo or eset have access to the unique token and thus have access to the second factor at their wish.
  2. for push method, they can log very many details on the users.
  3. in the case of eset, the whole world has access to the "secure" token as it is sent by sms.

The point of second factor should be something that only the user has. But, at least in the case of eset, this is not the case (and i assume duo is is analogous). I believe the only secure 2FA can be if the generation of the token and the distribution is available only to the company, that is some fully on-premise solution.

Am I completely mistaken by the insecurity of the paid 2FA authenticators? Can you explain, why it is actually secure if they have all the access? And how about privacy and logging?

Is there a fully on-premise solution? (If I am providing OWA or other application that requires 2FA, i can provide the authentication completely without the need to be snooped on by others).

1 Answer 1


I'm not going to touch on the Duo/Eset thing except to note that a very large number of authentication/authorization systems depend on trustworthy third parties. How much of your personal or corporate infrastructure could be compromised if Google/Microsoft/Amazon/Okta online services were to become compromised/malicious? In my, and even my company's, case: practically all of them. That's the hidden premise behind the entire concept of "the cloud".

Is there a fully on-premise solution? (If I am providing OWA or other application that requires 2FA, i can provide the authentication completely without the need to be snooped on by others).

Sure, lots of them. If anything, 2FA (or "MFA", multi-factor authentication) approaches that require a third party are the weird ones (with the notable but tragic exception of all the sites that only allow SMS). A few of the more common option classes, with examples of each:

  • TOTP (Time-based One Time Passwords). Commonly known as "Google Authenticator" after its most popular client, but the actual algorithm is public, standardized, and simple to implement, so tons of client apps offer it and generally speaking, every TOTP client works with every TOTP-requiring service. You can even roll it yourself (client or server) if you really don't trust any third-party implementation (though honestly, don't bother, most are fine). It's vulnerable to phishing or server compromise, but so are most of these. Some clients will sync the user's TOTP key across devices, which weakens the protection a little and usually means a third party (e.g. Google, Microsoft, etc.) has access to the key used to generate the OTPs (thought that can in turn be mitigated by end-to-end encryption of the sync) but that feature is optional everywhere I've seen it at all (and it's not like the user can't manually share their key by e.g. screenshotting the QR code and putting that file wherever).
  • OTP-generating hardware tokens. There's actually a ton of variation in this space, from things like totally unconnected widgets that are doing baaaaasically TOTP to Yubikeys in OTP mode where they pretend to be a keyboard and spit out a pseudorandom string when tapped (you have the generation seed - the key, really - for that pseudorandom function stored for each user, along with a monotonically increasing counter that is also in the hardware token, and can check if the generated string is one that is in the next N outputs starting from the current counter). You have to trust that the vendor hasn't held on to their secret keys, but it barely matters because the vendor doesn't know what user would hold a specific key anyhow. Still vulnerable to phishing.
  • Public-key-based. This is another somewhat broad category, encompassing everything from FIDO2/U2F devices like Yubikeys (in their non-OTP mode) to smart cards, FIDO2 with platform auth (Windows Hello / TouchID or FaceID / equivalents on other platforms) which can even be used without passwords if you want (that's basically what "passkeys" are), to mutual TLS client certificates, etc. This is both one of the oldest methods - e.g. my dad was using smart cards for 2FA in corporate logins decades ago when I was a kid - and one of the most secure (it can include phishing protection because the device or software that holds the private keys can check what page or app it's generating the signed string for, so a malicious site or app can't trick the private key holder into returning a signed blob that works for the legitimate site/app). It requires more advanced cryptography than the other options, but FIDO2-based systems are growing in popularity and there's lots of options for both client-side key stores (including both hardware and software, as mentioned above) and server-side software.
  • First-party apps. Fundamentally, this is easy. You write an app, publish it on the various stores, and have your users install it. They sign into the app at account creation (or at least at MFA enrollment) and it stores a unique secret in the app. In the future, when the user is logging in and needs MFA, you send a push notification (which need not contain any secrets) waking up the user's app, the user gets a prompt to approve or deny (unlocking the phone and/or the app itself locally first, if needed), and on approval the app sends a confirmation authenticated with that unique stored secret back to the server. You can also do other approaches here, that's just the most common one; the mobile app might display a code that the user has to enter, or the server might display a code (in the browser or whatever) that the user enters into the mobile app, or so on.
  • Separately-stored non-memorable secrets. These are actually really common - they're usually called "recovery keys" or similar, and function as the last-ditch second-factor if you lose your other ones - but they can also be used as a standard component of a system. For example, the password manager app 1Password has a keyfile that it calls the "Emergency Kit" which is (or at least can be, I've only ever used it this way) mandatory on all clients that sign into your account. You only have to add the "emergency kit" to a given client (app, browser extension, whatever) once at enrollment (unless you tell the client to forget it), but "a device with a client where the passkey/emergency kit was added" is just as much "something you have" as a Yubikey. For an offline example, disk encryption for PCs often allows the use of a keyfile that is to be stored on a flashdrive, such that you can't boot the machine (or at least, can't decrypt the encrypted volume) without that flashdrive or another that has the same file on it (or sometimes an alternate credential), which can be combined with a password or similar.

That's five classes of MFA approach - each with a few different options within them - for MFA that doesn't require giving third parties any secrets. Of course, there's a sense in which any communication requires some trust in third parties, but you have to draw the line somewhat. For example, most of these require that the certificate authorities (CAs) who ultimately are trusted to vouch for identity in TLS (including HTTPS) not issue fraudulent certificates for your site, but if they do, the attacker can do a lot more than just sniff credentials. First-party apps can use certificate/public key pinning to avoid the risk from the CAs, but then you're trusting that Google/Apple/etc.'s store is trustworthy and not tampering with your app (and getting the app to the user's device requires trusting a different TLS tunnel). At the end of the day, those all are requiring trust in fewer parties than things like Duo, and it's harder for a malicious actor to compromise arbitrary users that way too.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .