4

From what I understand, mobile phone-based two-factor authenticators like Google Authenticator implement TOTP which uses a shared secret key between the phone and the authenticating server.

Why did they decide to use a single shared secret key when they could have used a public/private key pair? The phone would store the private key and can sign an increment counter/timestamp and the authenticating server could verify the signature with the public key. It seems more secure since a breach in the authenticating server wouldn't be able to compromise the user's secret key. Are there any advantages that a shared secret key provides?

1
  • 1
    How do you get the public key to the server?
    – schroeder
    Commented Apr 16 at 8:12

3 Answers 3

0

Path of least resistance.

Shared secrets are easier to use, which means easier to write implementations against. Public key systems are significantly more difficult to write implementations against, therefore fewer people will do it.

There are asymmetric key-based protocols out there that do offer more/different protections and change the security requirements significantly, but they are fundamentally more difficult to implement.

It's the same basic reason people still ask why static passwords still exist and why they weren't done away with 20 years ago with certificates and PKI -- because its a PITA and a significant investment to do correctly.

1

The currently known methods of using "a public/private key pair" require too much communication; i.e., both ends would need Bluetooth or the token would need a computer-screen-reader or the process could get tedious. A shared secret key minimizes the amount of communication that is required.

1

The phone would store the private key and can sign an increment counter/timestamp

So far so good

the authenticating server could verify the signature with the public key

"The signature", you say. How exactly does the signature get to the server? Depending on the algorithm and key strength, it's going to be somewhere between 32 and 512 bytes just for the signature itself, never mind associated data such as "what was signed" (the plaintext) or "what key/algorithm was used". Are you planning to sit there and type in 64-1024 hexadecimal values every time you need to do MFA? And maybe some extra for the time the signature was generated, because it sure won't be that time any more when you finish?

TOTP uses truncated hashes. This works fine because both sides can independently generate the hash and truncate it. However, that does not work with asymmetric signatures at all. If you truncate a signature, it becomes completely worthless, impossible to ever verify or even conclusively reject. As such, TOTP but not digital signatures are usable in systems where a human has to enter the second factor manually. There are ways you could get around this, e.g. Bluetooth or NFC or scanning a generated QR code or so on, but nothing as simple and low-cost as "type these six numbers".

You must log in to answer this question.

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