Is it just me or does TOTP for two factor auth seem like a step back to the days of digest auth where you have to store the symmetrical secret in a reversible manner. Passwords stored in plaintext were--and still are--rampant and there have been myriad high level exposures of these secrets by even the largest entities.

Aren't we now just delaying the inevitable exposure of the TOTP secrets along with the vulnerable databases of user information being compromised by increasingly skilled attackers?

In a world where we have hardware asymmetric crypto engines in almost every device used for 2fa how has this method of authenticating a device become the most popular?

With systems like Secure Element and Touch ID hardening key access with silicon and biometrics we have access to security that even government actors struggle to compromise, so much so that they are moving towards legislation to weaken it.

Storing derived keys has been best practice to protect passwords at rest for at least a decade, but this strategy can not be used to protect the TOTP shared secrets. This leaves symmetrical encryption, which even when implemented properly is of dubious value in protecting live systems. PKI has been around even longer and yet it still struggles to gain a foothold in implementation space.

It's still the Wild West in most respects and a roiling crap shoot of kiloword RFCs and flawed implementations. Are there any existing simple to use systems that leverage the PKI tech available today to to securely assert device identity for 2fa on internet connected system that may need to be critically secure?

  • Three letters. H...S...M. See my answer to this question : security.stackexchange.com/questions/123834/…. You can use asymmetric encryption to encrypt the TOTP keys which can then only be decrypted by the key residing on the HSM. Since TOTP seeds are short, you can just use asymmetric encryption without the need for symmetric on top. Jun 4 '16 at 19:49
  • 2
    What's your threat model here? The shared secret will be uniquely generated, so won't help them get into other sites. If bad guy can access the db to get your key he can probably get everything else... Jun 5 '16 at 6:45
  • @NeilMcGuigan Isn't security about layers? We're removing a layer here and security is weaker because of it. Since TOTP secrets can not be hashed they would be broadly actionable with a--relatively--simple read-only compromise. With hashing, an information leak like this would be embarrassing but not security critical. While this information could not be leveraged on other sites, passwords compromised from other leaks could be used with this data to gain control of physical security systems. This is untenable IMO. Found FIDO this weekend, may be a good alternative.
    – joshperry
    Jun 6 '16 at 13:52
  • The threat here is the 'vendor-in-the-middle' as shown by the RSA hack. We chose to use asymmetric encryption with keys generated on the device/server. Our mistake was not publishing it with IETF and not being verisign (who IMO did it out of spite for RSA). However, i think the important protocol is radius and the like b/c that's where your switching costs are. @joshperry, you can see the tech details in our reg-free white paper if you like: wikidsystems.com/learn-more/white-papers
    – nowen
    Jun 6 '16 at 14:07
  • "With systems like....even government actors struggle to compromise" - don't believe the hype; governments can buy gummy bears too. Comparing apples and oranges doesn't prove one is better.
    – symcbean
    Apr 6 '18 at 10:18

You need to be aware, that TOTP is derived from HOTP (RFC4226), which was RFCed in 2005. This was the time, when smartphones have not been around, yet!

The algorithm was NOT designed for the Google Authenticator! but for hardware tokens, which would not be connected to a computer or would have no internet connected. So you would have to use the human optical interface, the eye and the typing fingers.

When thinking about it a bit, you will realize, that in this scenario, where you want to be able to type in a one time password, this must be generated from a symmetric key, since in the process of creating the OTP, there is a truncating involved (so that the OTP is short enough that it is fun typing). If you were using assymmetric crypto to create an OTP, the truncation would destroy your crypto.

Yes, PKI, smartcards would be even better, but you will not get happy with the driver hassle in many scnearios.

So of course, if the attacker gets access to the authentication system or the database, you are lost. But if the attacker gets access to your secret documents in the backend, you need not to worry about 2FA. So the question is, which threat models you want to mitigate. And there are still a lot out there, for which a one time password algorithm based on a symmetric key works pretty well.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.