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 May 10 at 16:14

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 May 9 at 8:50
  • @kjack: The comment would have been too long, so I just edited it to my answer. – Esa Jokinen May 9 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 May 9 at 9:12
  • 14
    At least, indeed; 7 tokens don't necessarily contain nearly enough information, <7 never. – Esa Jokinen May 9 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 May 9 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. – AndrolGenhald May 9 at 14:48
  • 4
    This is based on personal conception, but it's not backed up by the facts. – Esa Jokinen May 9 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 May 10 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! – securityOrange May 11 at 19:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.