5

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?

Improve this question
6
  • 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.
    – Little Code
    Commented Jun 4, 2016 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...
    – Neil McGuigan
    Commented Jun 5, 2016 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
    Commented Jun 6, 2016 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
    Commented Jun 6, 2016 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
    Commented Apr 6, 2018 at 10:18

1 Answer 1

Reset to default
4

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.

Improve this answer

You must log in to answer this question.

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