Google Authenticator uses the TOTP algorithm to generate your One-Time Password (OTP). TOTP works like this : The server generates a secret key and shares with the client (you) when the client registers with the server. Using the shared key and the current timestamp, a new password is generated every 30 seconds.

If anyone has the shared key, then they can generate the OTP themselves using the TOTP algorithm. Isn't this similar to a password? Doesn't it get reduced to having two passwords - One is the password that you use to login and the other is the shared key between you and the server?

  • The main risk is that the providers database of secrets is breached. Given the frequency of this kind of event, it's a pretty significant risk, in my estimation. If you want something that isn't subject to that kind of thing, you should look at something like FIDO2.
    – JimmyJames
    Commented May 10, 2019 at 16:14

2 Answers 2


Passwords are revealed every time you use them: if you have two passwords and you type them into a fraudulent web form, they are both stolen.

The shared secret can't be calculated from a single OTP (or even from a set of them**), so a stolen OTP is only valid for limited time. The shared secret is never transferred during the authentication, so stealing it requires a different attack vector: access to the device where it is kept or copying it (e.g. its QR code) during the initialization.

** Calculating shared secrets backwards would be very impractical, as it's a one-way algorithm. Also, the minimum key length is 128 bits and the algorithm produces only 6 numbers i.e. ~20 bit OTP. This means for every OTP there would be oceans of potential shared secrets, and finding even a single match would only be possible with brute force i.e. calculating 2^128 hashes for every 30 seconds and ruling out every OTP that didn't match.

  • 2
    Your answer prompts me to ask if we know how many OTPs (and their times of generation) would be needed in order to have a chance of calculating the secret. Hopefully it's a number so high that it's not something to be concerned about.
    – kjack
    Commented May 9, 2019 at 8:50
  • @kjack: The comment would have been too long, so I just edited it to my answer. Commented May 9, 2019 at 9:05
  • 7
    @kjack 6 digits contains 19.93 bits of entropy. So, you would need at least 7 OTP tokens to get the needed 128 bits of information (128/19.93=6.42). Then you could try to brute-force the key, which needs in average 2^127 computations, which is infeasible in the foreseeable future.
    – A. Hersean
    Commented May 9, 2019 at 9:12
  • 14
    At least, indeed; 7 tokens don't necessarily contain nearly enough information, <7 never. Commented May 9, 2019 at 9:15
  • 4
    @kjack They're looking at two different kinds of attacks. The 7 tokens thing deals with the raw amount of information in the keys. If an attacker sees 6 tokens, they have 120 bits of information total. As the key is 128 bits long, they literally cannot have gathered enough information to crack the key with 6 tokens. It's like trying to guess the next number that will come up from 3 dice rolls in a row. The second part is, assuming the attacker has at least 128 bits worth of information (by seeing at least 7 keys), they still actually have to break the HOTP algorithm itself.
    – Cort Ammon
    Commented May 9, 2019 at 16:07

OTPs are a way of not needing trusting someone with your password when you require them to know something of it (like that you have knowledge of it). In most implementations this is way things work anyway. Passwords are not passed around the net. Salted hashed passwords are. The problem is you don't necessarily trust that that's how everyone is doing things. Services such as google's just take that step away from the place your logging into and do it themselves.

So you're correct. The same things happen, nothing really changes. The only difference is who you trust, but that can be important.

  • 24
    "Passwords are not passed around the net. Salted hashed passwords are." - If you mean passwords are usually salted and hashed client-side, that's incorrect. Commented May 9, 2019 at 14:48
  • 4
    This is based on personal conception, but it's not backed up by the facts. Commented May 9, 2019 at 19:50
  • 9
    This answer is totally incorrect. OTP's are a second step after a user has been verified by password. While salted and hashed passwords are stored on a company's servers, they should never leave the servers. The user's password is encrypted with SSL when they log in, and the hashing process happens server side. The client should never be able to know what the resulting hash or salt is.
    – Kevin
    Commented May 10, 2019 at 3:09
  • This is false. OTPs like this are an entirely separate form of authentication, requiring access to something rather than knowledge of something. Mixing that up is an easy mistake to make! Commented May 11, 2019 at 19:48

You must log in to answer this question.

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