Are TOTP secrets stored in plaintext?

smtchahal
smtchahal
Community Member

Hi, I was just skimming through 1Password's security white paper, and it says on page 51 that "TOTP secrets" is one of the things that's subject to disclosure in the event of a breach as it's stored in cleartext. Does "TOTP secrets" refer to the shared secret used in TOTP, or something else?

I thought it referred to the "information for performing TOTP functions which are as-yet unimplemented" (which I don't really understand) as it says in the paragraphs before it, where it describes all the tables that store plaintext information, but then why does it list "TOTP secrets" later on? How is this information intended to be used, exactly?


1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Referrer: forum-search:Are TOTP secrets stored in plaintext?

Comments

  • Hi @smtchahal,

    Does "TOTP secrets" refer to the shared secret used in TOTP, or something else?

    Exactly, when you enable TOTP on your 1Password account the secret which allows you generate the one-time codes also needs to be known by our server so it can verify the code matches when you sign-in.

    I thought it referred to the "information for performing TOTP functions which are as-yet unimplemented" (which I don't really understand) as it says in the paragraphs before it, where it describes all the tables that store plaintext information, but then why does it list "TOTP secrets" later on?

    I think this information is a bit outdated, as TOTP is now fully implemented. Since TOTP is only required on the first sign-in on each device, the devices table contains some data about each device's 2FA status which allows subsequent authentications without prompting for your TOTP code.

  • Ben
    Ben
    edited February 2019

    And just to be clear: this is about the TOTP secret for your 1Password.com account: https://support.1password.com/two-factor-authentication/, if you have TOTP enabled there. It is not about TOTP secrets for other services which you have TOTP enabled for and are using 1Password to generate those TOTP codes: https://support.1password.com/one-time-passwords/ Those are encrypted in 1Password.

    I hope that helps avoid any confusion for anyone else who might be reading. :)

    Ben

  • smtchahal
    smtchahal
    Community Member

    Thanks a lot, Ben and Jasper, that actually cleared it up for me. I was thinking it meant TOTP secrets for other apps/services the whole time.

    But just out of curiosity, why does the TOTP secret for my 1Password account need to be stored in plaintext? I'm guessing it's because if it was encrypted in the same way as all my logins and other secrets, it would then need to be decrypted as soon as I entered my master password (along with the access key), defeating the purpose of 2FA? Something like that?

  • jpgoldberg
    jpgoldberg
    1Password Alumni

    why does the TOTP secret for my 1Password account need to be stored in plaintext?

    With TOTP, you prove to the server that you have access to a long term secret which is shared by the client and the server. That is, the long term secret is a shared secret. You (well, your client or authenticator tool) proves that it has access to that secret by performing a computation based on the secret and the current time. That computation results in the six digit code. The server, however, needs to verify the code and to do that it performs the same computation. So the server needs to know that long term secret.

    Alternatives to shared secrets

    It is possible to have authentication protocols that do not require a shared secret. If you think about how traditional logins work, the client has a secret (the password), and the servers verifier is a hash of that password. So there the server is not storing the password. Instead it is storing something mathematically related to the secret. One of the many big problems with this is that the secret (the password) gets transmitted to the server during each authentication.

    Our primary authentication mechanism, SRP, does not involve a shared secret. You have a long term secret, x, and the server has a long term verifier, v. These are mathematically related, but one can't simply compute x from v. (You can compute v from x, though). There is a conversation back and forth that allows each side to prove to the other that they have their respective secrets, but no secret is transmitted during that exchange.

    The disadvantage of something like TOTP is the shared secret. The disadvantage of traditional passwords is that the secret is transmitted, the disadvantage of SRP is that it requires a whole conversation instead of the client just sending a single message. But by allowing a dialogue during the authentication process we get the best of traditional passwords (server doesn't know user secret) and never transmit a secret (like the one-time-ness of TOTP).

    Kinda-sorta encrypted

    There is a technical sense in which everything we store is encrypted with basic low level database encryption. (Think of it as like having full disk encryption set on your computer.) That data encryption layer against someone who steals the disks that the data is stored on, but it isn't part of the end-to-end encryption that offers the real security of 1Password; so we leave that out of the description as it just muddies the water. We do all the standard security stuff that one does when running a service and storing data, but we've designed 1Password to keep you and your data safe even if all of that "standard" stuff fails.

    But ignoring that (and the narrow, but important threat it defends against), an attacker who breaches a server that uses TOTP for authentication will get the TOTP shared secrets. This is true of pretty much any service using TOTP. TOTP was never designed to defend people against the consequences of server breaches. Our use of SRP along with client side incorporation of your 1Password Secret Key is designed to keep you safe from server breaches, and SRP also keeps you safe from the weaknesses of traditional password authentication.

This discussion has been closed.