When using 2-factor-authentication using plain TOTP, the secret is stored on both the client and the server. This in turn means, that anyone with access to the database (and a key for it) knows the 2fa-secret of all the users. Why is this acceptable? Storing plaintext passwords has been deemed unacceptable a long time ago.

Public key cryptography is a perfect solution for this; one could combine it with TOTP. The client generates a private/public-key pair and the TOTP-secret and sends the public key and the secret to the server. The client then generates a TOTP-token, encrypts it with the private key and sends it to the server which can then verify it. Note that this encryption could also be implemented inside an app like "Google Authenticator" in a way that the user would just have to type it out as well.

This solution seems a lot better to me as nobody on the server-side can know the private key. Why is it, or any other such alternative, not used in practice?

  • If I am not getting you wrong, the secret is sent to the server in plain, right? And the only thing stopping others from creating one is the "encryption with private key"? Commented Jun 22, 2021 at 12:20
  • Another problem you have is that you never encrypt anything with private key? You may sign it, but encrypting with private key does not happen. In most schemes I know of, encryption with private key cannot even be defined Commented Jun 22, 2021 at 12:21
  • Or it is sent over TLS/SSL?Anyway, it is redundant because use of server issued certificates for clients, (server creates a trusted CA for application usage) used with mutual authentication does the job just fine or should I say much better Commented Jun 22, 2021 at 12:32
  • @ManishAdhikari This is intended to be used in addition to TLS. It should be used for the server to authenticate the client. TLS is used for the client to authenticate the server, therefore it is not redundant if I am not mistaken. I think you are missing the point a little though. The only reason for this is that the server should not be able to generate a 2fa-token, only to verify it. This should also prevent attackers from being able to get into the system by generating tokens themselves in case of a data leak, which is the same reason for why we don't store passwords in plain text.
    – Gamer2015
    Commented Jun 22, 2021 at 12:55
  • You cannot completely prevent that in case both your private key and your TOTP secret key leaks. Second is for server to not be able to generate 2fa-token it should be simple token plus a signature on it, not something "encrypted with private key". It is a dangerous but worryingly common misconception that something can be authenticated by encrypting it with private key and verified by decrypting with public key. Also you need to be careful about replay attacks but I guess limiting time window works Commented Jun 22, 2021 at 16:00

3 Answers 3


There are a few issues with your scheme that I can think of:

  • the server would have to store several keys per user, where the current scheme needs just one secret to be stored for multiple client authenticators
  • the authentication scheme shifts the responsibility of generating and maintaining the secret to the client, not the server, even though the server is the authenticating party
  • the client (the now-responsible-party) has no way of notifying the authenticating party that a key is invalid
  • it's over-engineered since a client-side PKI scheme could replace the entire authentication process
  • client-side key management is more difficult than it appears

Your scheme is perfectly acceptable and is a well-known authentication design pattern that has been in use in mutual authentication SSH for decades. It is not fit-for-purpose for the goals of MFA, however.

"Why is this acceptable?" "Why is it, or any other such alternative, not used?"

Because TOTP supports a password and is not considered to have the same level of sensitivity.

  • 1
    This answer omits the main reason for not using PKI authentication: the desired truncated length of the OTP and the desired out-of-band communication channel, see security.stackexchange.com/questions/160273/…. In fact, PKI for 2FA/MFA is used plenty, but then using an in-band challenge message containing a secret message which is decrypted by the user's private key, then possibly verified with the server out-of-band (e.g. Google's two digit code that you need to enter upon receiving it (via push mechanism) on your phone).
    – Ralph
    Commented Jan 5 at 13:12

2FA is not one thing. It's a general concept, where you have two factors. The factors may be a shared secret you have, or it may be a PKI certificate the user has. It may be U2F.

If you have concerns over the database of secrets, don't use TOTP; use U2F or some other 2FA which doesn't require you to have this database.

The shared secret is a weakness in TOTP. But TOTP is also easy and cheap to add, and well supported by many different devices. This makes it easy to implement.

Security is nearly always a tradeoff between usability, cost and security. TOTP is cheap to implement, well supported, and mitigates many of the problems with password reuse and phishing. It's not perfect; the secret can be leaked or copied.

More secure standards such as U2F or PKI is more expensive, as the user is likely to require a hardware device - but U2F will provide a higher level of security.

  • Thank you for your answer as well as mentioning alternatives to TOTP. I don't quite understand how U2F removes the necessity to store a secret on the server but I'm sure that is something I can read up on somewhere on the internet.
    – Gamer2015
    Commented Jun 22, 2021 at 10:49
  • 2
    It's public key cryptography. The U2F device creates a private and public key, and gives the remote server the public key. The private key never leaves the U2F device. An attacker that has the public key can't reconstruct the corresponding private key, and won't be able to authenticate.
    – vidarlo
    Commented Jun 22, 2021 at 11:23
  • This is exactly what i was expecting, thanks for providing a source for further information!
    – Gamer2015
    Commented Jun 22, 2021 at 12:58
  • @Gamer2015 Have you considered PIV smart card instead of TOTP?
    – NetServOps
    Commented Jun 22, 2021 at 13:00
  • @vidarlo To nitpick: the per-site private key is then wrapped by symmetric encryption with a secret key inside the U2F token then sent to the site and stored there. The only thing stored by the token is the wrapping key. An attacker that stole the server's database can't reconstruct the private key because they can't unwrap it. It's a nifty trick also used by TPM.
    – user71659
    Commented Jun 22, 2021 at 21:23

the secret is stored on both the client and the server. This in turn means, that anyone with access to the database (and a key for it) knows the 2fa-secret of all the users. Why is this acceptable? Storing plaintext passwords has been deemed unacceptable a long time ago.

There is a conceptual mistake in the question. When a site gets cracked/pwned/leaked, it's considered gone. Sites get cracked every day, including any sort of valuable personal information. The very reason why we protect passwords is that because they are reused and chosen by user. TOTPs are not. If my own secure password is C0rr€ct B4ttery $tapl€ Hors€, it's likely that I use it both on http://buy.cheap.pizza and chase.com, the former obviously using a lot less security measures. Once it's stolen, it can be used to try to attack my chase.com account with direct financial consequences

Passwords are an asset. A valuable asset.

2FA is used to protect the account from an attacker doing malicious things after compromising the first factor, which happens to be the password and passwords often happen to leak.

The key is that the TOTP secret is chosen by the server, not by the client. So if the server gets cracked and TOTP leaks, it can be used only on the very same site. But it can't be reused to log in to github.com, gmail.com etc. as it is unique.

Indeed, certificate authentication is stronger. Indeed, FIDO U2F is going to that direction. But the question starts from a mistaken assumption.

You must log in to answer this question.

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