# How does Google's “authenticator number generator” work?

I have two-factor authentication enabled on my Google account, and I have this app on my phone which generates a number I have to type when I'm logging in to Google-Mail.

But I don't understand how this number is validated on Google's side. My bank has a similar approach: they gave me this little gadget which also generates numbers.

How do such “authenticator number generators” work?

• Here's a starting place for some research: Time-based One-time Password Algorithm, an extension of HOTP. What level of familiarity do you have with cryptography? That'll largely determine how detailed potential answers need to be. – Reid Dec 3 '13 at 5:26

Google (and other companies) have decided to enable one-time passwords for their 2-factor authentication as a step to improve password security. Here is the webpage that explains what Google is doing in more detail (including source code): https://code.google.com/p/google-authenticator/

In a nutshell, they implement two IETF RFCs, namely RFC 6238 and RFC 4226. Have a look at these two specifications; they contain all the details. I was the shepherd for RFC 6238.

I found the accepted answer above a bit unhelpful -- it basically just says: "read these two RFCs". So, on the theory that the quickest way to get the right answer to a question on the Internet is to provide a wrong one, and wait a few New York Minutes until someone corrects you, here's my attempt at a summary overview answer, based on a laughably cursory examination of the Wikipedia entry and the two RFCs.

basically your phone and the server app start by agreeing on a secret key, which they both know. that happens just once, when you set up the app on authenticator.

From there on in, the number that's generated every 30 seconds is based on SHA-1 hashing the secret key with the current time (in the form of a unix timestamp, rounded down to 30 seconds).

So, tl;dr: it's a hash of a shared secret with the current unix timestamp.

Or is it? Corrections welcomed...

• This answer might be correct (I don't know) but to be so, you should provide references to your claims: Where on wikipedia did you find it; Which RFCs etc – figlesquidge Apr 28 '14 at 15:13
• Corrections welcomed... Huh? Don’t get me wrong, but you might want to check the accepted answer instead of guessing and asking to be corrected in case your guess is incorrect. In case something isn’t clear to you in relation to “two-factor authentication”, please feel invited to ask your own question. – e-sushi Apr 28 '14 at 17:01
• sorry i wasn't very clear. have rephrased. basically i want a nice overview answer, not a "look at these two rfcs". – hwjp Apr 28 '14 at 18:35
• I think 'read these three long documents' is not a very helpful answer, so thanks for the summary, precise or not. – Nate Aug 29 '16 at 17:16

Google Authenticator uses two algorithms: HOTP and TOTP which are described in RFC 4226 and RFC 6238. These algorithms generate one-time passwords (OTPs) based on the secret key. To generate OTPs a secret needs to be shared between the server and the client. The secret key usually displays in the form of QR code. As soon as the secret is shared it is stored both on the server and on the customer device. Based on it the device produces an OTP and the server checks if it’s correct.

HOTP relies on two basic things: a shared secret and a moving factor. The algorithm is event-based so whenever a new OTP is generated, the moving factor will be incremented, hence the subsequently generated passwords should be different each time. TOTP is similar to HOTP, the only difference is that the moving factor constantly changes based on the time passed since an epoch. The TOTP password is short-lived while the HOTP password may be valid for an unknown amount of time.

• What is the granularity of the two factors? – Paul Uszak Apr 5 '18 at 16:26
• Granularity has a broad meaning. What do you mean by granularity? – Christian Apr 6 '18 at 12:58
• Oh, how long are they? The answer below suggests 30s for an unspecified one. Seconds, weeks etc? – Paul Uszak Apr 6 '18 at 13:39