Google Authenticator is an alternative to SMS for 2Step verification, installing an app on Android where the codes will be sent.

It works without any connectivity; it even works on plane mode. This is what I don't get. How is it possible that it works without connectivity? How do the mobile phone and the server sync to know which code is valid at that very moment?

  • 12
    The codes are not "sent". They are made via a seed and counter.
    – JZeolla
    Commented May 1, 2013 at 19:28

4 Answers 4


Google Authenticator supports both the HOTP and TOTP algorithms for generating one-time passwords.

With HOTP, the server and client share a secret value and a counter, which are used to compute a one time password independently on both sides. Whenever a password is generated and used, the counter is incremented on both sides, allowing the server and client to remain in sync.

TOTP essentially uses the same algorithm as HOTP with one major difference. The counter used in TOTP is replaced by the current time. The client and server remain in sync as long as the system times remain the same. This can be done by using the Network Time protocol.

The secret key (as well as the counter in the case of HOTP) has to be communicated to both the server and the client at some point in time. In the case of Google Authenticator, this is done in the form of a QRCode encoded URI. See: KeyUriFormat for more information.

  • 11
    In the case of HOTP, how does Google Authenticator know that I have "used" the password without syncing with the server? What Google Authenticator does is that it continues to flash different keys and I can just use any one them without giving feedback to my mobile.
    – Mario Awad
    Commented May 7, 2013 at 8:21
  • 6
    @MarioAwad The answer to that can be found on the HOTP RFC, section 7.4. ietf.org/rfc/rfc4226.txt
    – user10211
    Commented May 7, 2013 at 8:24
  • 9
    Thank you for the well defined answer and followup. Quick summary of section 7.4: Resynchronization of the Counter every now and then and a look-ahead window for the counter is what makes things work without requiring instant-sync.
    – Mario Awad
    Commented May 7, 2013 at 11:03
  • As @TerryChia pointed out, the secret key is in the QR code. Be aware of the sensitivity of the QRCode/Information. I wrote a blog post a while ago netknights.it/en/the-problem-with-the-google-authenticator
    – cornelinux
    Commented Apr 20, 2017 at 14:46
  • @cornelinux You're right about TOTP, but surely with HOTP a second device would need to know how many times the other device has connected to work.
    – Auspex
    Commented Mar 29, 2021 at 10:40


Authenticator implements the Time-Based One-Time Password (TOTP) algorithm. It has the following ingredients:

• A shared secret (a sequence of bytes)

• An input derived from the current time

• A signing function

Shared Secret : The shared secret is what you need to obtain to set up the account on your phone. Either you take a photo of a QR code using your phone or you can enter the secret manually.

Input (Current Time) : The input time value you'll simply get from your phone, no further interaction with the server is required once you have obtained the secret. However it is important that your phone's time is accurate as the server will essentially repeat what happens on your phone using the current time as known by the server.

Signing Function : The signing function used is HMAC-SHA1. HMAC stands for Hash-based message authentication code and it is an algorithm that uses a secure one-way hash function (SHA1 in this case) to sign a value. Using an HMAC allows us to verify authenticity - only people knowing the secret can generate the same output for the same input (the current time).

OTP Algorithm:

Pseudo Code:

original_secret = xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx

secret = BASE32_DECODE(TO_UPPERCASE(REMOVE_SPACES(original_secret)))

input = CURRENT_UNIX_TIME() / 30  // sets a constant value for 30 seconds

hmac = SHA1(secret + SHA1(secret + input)) //apply hashing

offset = hmac[len(hmac)-1] & 0x0F //Last nibble

four_bytes = hmac[offset : offset+4] //takes a subset of 4 bytes from 20 bytes

large_integer = INT(four_bytes) //Covert four bytes to integer

small_integer = large_integer % 1,000,00 //gives 6 digit code

enter image description here

Reference: https://garbagecollected.org/2014/09/14/how-google-authenticator-works/

Also check out this github project for GO implementation: https://github.com/robbiev/two-factor-auth/blob/master/main.go

  • Doesn't the google authenticator also supports HOTP? Commented Feb 9, 2019 at 13:45
  • Yes, Google Authenticator also supports HOTP but I believe TOTP is a secure way, there are many apps like this, for example, Authy. in case anyone wants to install and use google-authenticator, you can check developingdaily.com/article/technology/… Commented Apr 27, 2022 at 11:00

It'll work on a seed based on time so it's similar to the way the RSA key fobs work. i.e. they also don't require any connectivity.

I've just had a look around and this is answered here: https://stackoverflow.com/questions/8340495/how-rsa-tokens-works


If one straces the sshd daemon, one can see how the server 'knows' about the secret key, as it read the users config file:

#strace -f -v -e open /usr/sbin/sshd -p 2222 -dddd -f /etc/ssh/sshd_config 2>&1 | grep -i goog

> > [pid  2105] open("/home/myuser/.google_authenticator", O_RDONLY) = 4
> > [pid  2105] open("/home/myuser/.google_authenticator~",
> > mm_sshpam_respond: pam_respond returned 1 [preauth]

The mobile phone already knows it; you scanned it via QR or typed it in.

  • 1
    This is a good example of how to demonstrate that the tokens are not being sent to the server, but doesn't actually explain how it works (Which is what OP asked)
    – Mr. E
    Commented Aug 31, 2018 at 0:17
  • It doesn't per se, but it does address the lack of connectivity.
    – james6125
    Commented May 10, 2019 at 20:25

You must log in to answer this question.