If someone gets my phone and saves the values my authenticator generates, will that person be able to find out the shared key (to be used to generate codes themselves)?

If so, how many codes will they need to generate to get my shared key? (Roughly, as it can change according to they solving algorithm)

You might want to note that I mean the TOTP algorithm used with a 16 characters-long key (lower case letters, numbers) here.

  • TOTP is for time-based one time password, but abbreviation of Two Factor Authentication is 2FA
    – Ali
    Commented May 3, 2015 at 18:04
  • @Ali Yes, I know. I stated TOTP as I was actually wondering an answer specifically for TOTP...
    – ave
    Commented May 3, 2015 at 21:38
  • Well if they have access to the current time (normally in Unix time and peper 30 seconds slices) and the generated value then they can use the RFC for TOTP tools.ietf.org/html/rfc6238 to generate values using a key. They would then need to go through all possible combinations of 16 character keys (if they knew that the secret was 16 characters) until they found the matching code.
    – Steve Ford
    Commented Dec 9, 2016 at 16:18
  • It depends on the phone OS and TOTP app you use. Not all of them store the secrets secure enough. So if you lose your phone you should use a new TOTP code and deregister the compromised one.
    – eckes
    Commented May 13, 2019 at 4:16

2 Answers 2


Authentication relies on the following: (source)

  • Something you know
  • Something you have
  • Something you are

A good reason to use TOTP is to increase security by using multiple factors from the list above. For example, if your password becomes known to someone else, they would still need access to your TOTP device to authenticate.

However, that does not mean that TOTP devices are invulnerable to attack.

RFC 6238 states that:

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

This means that TOTP implementations are not required to protect the shared secret to be RFC compliant. However, you might consider looking for a TOTP application that requires a password to decrypt the shared secrets. This provides some additional protection, but if your phone's security is compromised by an exploit or malicious physical access, keylogger attacks become possible.

You also asked how many keys an attacker would need to see to discover your shared secret. From RFC 4226, Appendix A.4.3:

No matter what strategy the adversary uses, and even if it sees, and tries to exploit, the authenticators from authentication attempts of the user, its success probability will not be above that of the brute force attack -- this is true as long as the number of authentications it observes is not incredibly large.

So, in general, a brute force attack is the best that could occur. However, if the adversary can generate the codes at will (and for some reason they do not already have the shared secret), this does not hold. More information about what influences this attack are available in the RFC.


Under your assumptions, essentially never: If they can't pry out the secret key from the device, and this is a long, randomly generated key, then obtaining any practical number of auth codes will not help the attacker in the slightest, as that is an essential desideratum of TOTP itself. Otherwise, it could hardly be considered secure. If, however, your secret key is weak (say, a dictionary word, even if 16 characters long), then finding it is not much work.

You must log in to answer this question.

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