4 ms·

If you know of the database compromise, sure. If your database contents are exposed (or a dump or backup is exposed) unbeknownst to you, those TOTP secrets won

If you know of the database compromise, sure. If your database contents are exposed (or a dump or backup is exposed) unbeknownst to you, those TOTP secrets won't be invalidated, and attackers which get their hands on that have more than they'd have if some other second factor method was in use which didn't rely solely on a long-term shared secret. And since database exposures can go back a long way (like this one), and TOTP secrets aren't normally rotated over time, then this difference in second factor methods seems interesting.

tptacek 8y ago
If you don't know of the database compromise, the technical term for the steady state you are operating in is "owned". 2FA isn't doing anything for you.
- jjnoakes 8y ago
  If you don't know of the database compromise (which could have been a backup or old dump, and not necessarily a live system breach), you may be "owned", but unless the TOTP seeds (or equivalent 2FA master keys) are in that db dump, 2FA most certainly is still doing something for you...
  - akerl_ 8y ago
    This is bit tautological: yes, if part of your stack is specifically compromised at a point-in-time, other parts of your stack were not necessarily compromised. But since your user auth flow needs access to the unencrypted TOTP seeds, and user info generally lives in a database, for the majority share of infrastructures a compromise of the DB will compromise all TOTP seeds.
    - jjnoakes 8y ago
      Since TOTP seeds are long-term shared-secrets which are all that is needed to complete 2FA, and rarely/never rotated unless someone knows they were compromised, even years-old database compromises (old backups, etc) means current TOTP 2FA is also probably compromised. Which is not true of some other 2FA mechanisms (which is my point - I never thought about it before, but TOTP has a specific failure mechanism that not all 2FA mechanisms have). I still prefer TOTP to auth codes over SMS, but I wish there was something better (TOTP with seed rotation, auth codes over more secure channels, etc).
      - tptacek 8y ago
        This is pretty silly. If a TOTP secret had value outside of a single application/database, this would be worth thinking about. But they do not; they are a binding between a device and a particular application. If either the app or the device are compromised, so is the relationship, as is (most likely) all the data you were trying to protect anyways.
        jjnoakes 8y ago
        Let's say a service you still use loses a database backup from 2 years ago, and they don't realize it was lost. Scenario 1: The service stored passwords in some way and TOTP seeds in the database and uses TOTP to authenticate users. Scenario 2: The service stored passwords in some way and uses some other 2FA mechanism (like unique codes over some secure channel) You seem to be claiming there is no different between the two, where as I think I'd prefer scenario 2, because in scenario 1, if my password is obtained somehow (the password was not stored securely, I used a weak password, credential stuffing matched my password from other site leaks against the email in this database leak, or any other way) then the attacker can log in to my account on the service right now and bypass TOTP 2FA. In scenario 2, 2FA is still protecting my account.
        tptacek 8y ago
        I'm saying there is no practical difference between the two, because there isn't. You can keep layering feature after feature on any part of your security model, but time and energy is finite, and complexity adds risk, and burning time, energy, and complexity on this is bad engineering.
        jjnoakes 8y ago
        I disagree with "no practical difference" (since I demonstrated one), and layered approaches to security are usually encouraged, not dismissed as "bad engineering". Regardless, I will keep this 2FA difference in mind going forward, since it is interesting to me; of course, you (and others) are free to ignore my thoughts if you so choose.

tptacek 8y ago

If you don't know of the database compromise, the technical term for the steady state you are operating in is "owned". 2FA isn't doing anything for you.

jjnoakes 8y ago
If you don't know of the database compromise (which could have been a backup or old dump, and not necessarily a live system breach), you may be "owned", but unless the TOTP seeds (or equivalent 2FA master keys) are in that db dump, 2FA most certainly is still doing something for you...
- akerl_ 8y ago
  This is bit tautological: yes, if part of your stack is specifically compromised at a point-in-time, other parts of your stack were not necessarily compromised. But since your user auth flow needs access to the unencrypted TOTP seeds, and user info generally lives in a database, for the majority share of infrastructures a compromise of the DB will compromise all TOTP seeds.
  - jjnoakes 8y ago
    Since TOTP seeds are long-term shared-secrets which are all that is needed to complete 2FA, and rarely/never rotated unless someone knows they were compromised, even years-old database compromises (old backups, etc) means current TOTP 2FA is also probably compromised. Which is not true of some other 2FA mechanisms (which is my point - I never thought about it before, but TOTP has a specific failure mechanism that not all 2FA mechanisms have). I still prefer TOTP to auth codes over SMS, but I wish there was something better (TOTP with seed rotation, auth codes over more secure channels, etc).
    - tptacek 8y ago
      This is pretty silly. If a TOTP secret had value outside of a single application/database, this would be worth thinking about. But they do not; they are a binding between a device and a particular application. If either the app or the device are compromised, so is the relationship, as is (most likely) all the data you were trying to protect anyways.
      - jjnoakes 8y ago
        Let's say a service you still use loses a database backup from 2 years ago, and they don't realize it was lost. Scenario 1: The service stored passwords in some way and TOTP seeds in the database and uses TOTP to authenticate users. Scenario 2: The service stored passwords in some way and uses some other 2FA mechanism (like unique codes over some secure channel) You seem to be claiming there is no different between the two, where as I think I'd prefer scenario 2, because in scenario 1, if my password is obtained somehow (the password was not stored securely, I used a weak password, credential stuffing matched my password from other site leaks against the email in this database leak, or any other way) then the attacker can log in to my account on the service right now and bypass TOTP 2FA. In scenario 2, 2FA is still protecting my account.
        tptacek 8y ago
        I'm saying there is no practical difference between the two, because there isn't. You can keep layering feature after feature on any part of your security model, but time and energy is finite, and complexity adds risk, and burning time, energy, and complexity on this is bad engineering.
        jjnoakes 8y ago
        I disagree with "no practical difference" (since I demonstrated one), and layered approaches to security are usually encouraged, not dismissed as "bad engineering". Regardless, I will keep this 2FA difference in mind going forward, since it is interesting to me; of course, you (and others) are free to ignore my thoughts if you so choose.