How does Google Authenticator work?
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?
- 7 years ago
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.
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.
@MarioAwad The answer to that can be found on the HOTP RFC, section 7.4. http://www.ietf.org/rfc/rfc4226.txt
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.
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 https://netknights.it/en/the-problem-with-the-google-authenticator/
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).
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
Also check out this github project for GO implementation: https://github.com/robbiev/two-factor-auth/blob/master/main.go
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
sshddaemon, 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~", > > O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_NOFOLLOW, 0400debug3: > > mm_sshpam_respond: pam_respond returned 1 [preauth]
The mobile phone already knows it; you scanned it via QR or typed it in.
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)