The specification for OTP systems in general doesn't give any particular recommendations for storage of shared secrets.

The HOTP specification provides a little more guidance in Management of Shared Secrets.

The TOTP specification provides the following as requirement 7 (R7) of Algorithm Requirements.

The specification for OTP systems in general doesn't give any particular recommendations for storage of shared secrets.

The HOTP specification provides a little more guidance in Management of Shared Secrets.

The TOTP specification provides the following as requirement 7 (R7) of Algorithm Requirements.

For the most part, the answer is yes. With conditions.

The specification for OTP systems in general doesn't give any particular recommendations for storage of shared secrets.

The HOTP specification provides a little more guidance in Management of Shared Secrets.

We also RECOMMEND storing the shared secrets securely, and more specifically encrypting the shared secrets when stored using tamper- resistant hardware encryption and exposing them only when required: for example, the shared secret is decrypted when needed to verify an HOTP value, and re-encrypted immediately to limit exposure in the RAM for a short period of time. The data store holding the shared secrets MUST be in a secure area, to avoid as much as possible direct attack on the validation system and secrets database.

Particularly, access to the shared secrets should be limited to programs and processes required by the validation system only. We will not elaborate on the different security mechanisms to put in place, but obviously, the protection of shared secrets is of the uttermost importance.

The TOTP specification provides the following as requirement 7 (R7) of Algorithm Requirements.

The keys MAY be stored in a tamper-resistant device and SHOULD be protected against unauthorized access and usage.

The same document then expands on this (regarding both serverside and clientside storage) in its Security Considerations section.

We also RECOMMEND storing the keys securely in the validation system, and, more specifically, encrypting them using tamper-resistant hardware encryption and exposing them only when required: for example, the key is decrypted when needed to verify an OTP value, and re-encrypted immediately to limit exposure in the RAM to a short period of time.

The key store MUST be in a secure area, to avoid, as much as possible, direct attack on the validation system and secrets database. Particularly, access to the key material should be limited to programs and processes required by the validation system only.

There is no mention of the shared secret being separated from other credentials, either in the aforementioned specifications or in the OATH OTP MFA recommendations.

The reason for this is that, if your password manager meets the standards described above, then (as you intuit in your question) it's very unlikely than a successful attempt to steal your credentials would target the password manager itself. It's much more likely that your credentials might be stolen during transmission, such as by fooling you into typing your password into a bogus login page, or by somehow reading your authentication traffic.

OTP will protect you here. Even if an attacker were able to see everything you send with a login form, they would only get a single, transient code. The key does not get exposed when sending the password, and therefore your account is protected.

NB: It is not necessarily unreasonable to decide for yourself that you shouldn't keep shared secrets in the same vaults as their associated passwords.

The most rudimentary purpose of two-factor or multi-factor authentication form is that a single breach would not be enough to compromise an account. For example, one of the earlier forms of 2FA is the PIN associated with ATM cards. If the only card gets stolen, your money is safe. If only the PIN gets stolen, your money is safe.

In this sense, storing your secret keys in the same vault as your password creates a single point of failure, militating the most rudimentary benefit of MFA. It is a very theoretical risk, given the extreme security requirements for the vault itself, but theoretically, the risk might become significant in certain threat models.

For the most part, the answer is yes. With conditions.

The specification for OTP systems in general doesn't give any particular recommendations for storage of shared secrets.

The HOTP specification provides a little more guidance in Management of Shared Secrets.

We also RECOMMEND storing the shared secrets securely, and more specifically encrypting the shared secrets when stored using tamper- resistant hardware encryption and exposing them only when required: for example, the shared secret is decrypted when needed to verify an HOTP value, and re-encrypted immediately to limit exposure in the RAM for a short period of time. The data store holding the shared secrets MUST be in a secure area, to avoid as much as possible direct attack on the validation system and secrets database.

Particularly, access to the shared secrets should be limited to programs and processes required by the validation system only. We will not elaborate on the different security mechanisms to put in place, but obviously, the protection of shared secrets is of the uttermost importance.

The TOTP specification provides the following as requirement 7 (R7) of Algorithm Requirements.

The keys MAY be stored in a tamper-resistant device and SHOULD be protected against unauthorized access and usage.

The same document then expands on this (regarding both serverside and clientside storage) in its Security Considerations section.

We also RECOMMEND storing the keys securely in the validation system, and, more specifically, encrypting them using tamper-resistant hardware encryption and exposing them only when required: for example, the key is decrypted when needed to verify an OTP value, and re-encrypted immediately to limit exposure in the RAM to a short period of time.

The key store MUST be in a secure area, to avoid, as much as possible, direct attack on the validation system and secrets database. Particularly, access to the key material should be limited to programs and processes required by the validation system only.

There is no mention of the shared secret being separated from other credentials, either in the aforementioned specifications or in the OATH OTP MFA recommendations.

The reason for this is that, if your password manager meets the standards described above, then (as you intuit in your question) it's very unlikely than a successful attempt to steal your credentials would target the password manager itself. It's much more likely that your credentials might be stolen during transmission, such as by fooling you into typing your password into a bogus login page, or by somehow reading your authentication traffic.

OTP will protect you here. Even if an attacker were able to see everything you send with a login form, they would only get a single, transient code. The key does not get exposed when sending the password, and therefore your account is protected.

NB: It is not necessarily unreasonable to decide for yourself that you shouldn't keep shared secrets in the same vaults as their associated passwords.

The most rudimentary purpose of two-factor or multi-factor authentication is that a single breach would not be enough to compromise an account. For example, one of the earlier forms of 2FA is the PIN associated with ATM cards. If only the card gets stolen, your money is safe. If only the PIN gets stolen, your money is safe.

In this sense, storing your secret keys in the same vault as your password creates a single point of failure, militating the most rudimentary benefit of MFA. It is a very theoretical risk, given the extreme security requirements for the vault itself, but theoretically, the risk might become significant in certain threat models.