To expound, I access a website that has a 2FA that asks me a temporary authentication code generated by Google authenticator. My Google authenticator is in my Android phone, which is usually offline. Even so, the temporary code that it generates still works when I input it in the website.
How does that work? How does my Google authenticator in a phone that isn’t connected to the net communicate with the website?
In: Technology
I’m sorry, theirs a few ways to do this, You’d have to describe what you do with the phone and the app to use it in offline mode to narrow down which is used in this case.
but if your inputting a code into some device that your phone generated for you, then the answer is that code is sent to google and *some math* is done on it, the result of which validates you as the person who has access to the authorised phone, and google confirms to the site your Authorised.
When you setup the authenticator, the qr code contains secure string that your app and server know.
Your code is generated from this string and current time (up to a minute). It’s a deterministic math function.
Your phone generates you a number, and when you submit it, the server uses the same secret key, current time and function to generate own code, and if they are the same, it lets you in.
This protocol can be used on [fully offline MFA keys](https://www.watchguard.com/sites/default/files/ldr_token_support.jpg)
It is a TOTP – **Time** based One-Time Password. The website gives your authentication app a specific seed value that is combined with the current time to generate a predictable six-digit code. Since both your app and the website know the seed value and know what time it is, they both can generate the same six digit code whenever asked. So when you give the site the code, it compares it with the code it expects to get from you _at this specific time_.
This tech will work offline so long as your phone clock doesn’t drift too far from the current time.
Its time based, notice that the authenticator code changes every 60 seconds.
When you setup an entry in the authenticator app you normally scan a 3d barcode which provides a unique value for the authenticator entry, the value is specific to you and the web site, I suspect it also may setup a reference time zone (perhaps UTC?).
With some clever math the authenticator app uses your web-site specific unique value and time to generate a code which you manually enter into a page on the web-site.
The web site also generates a code using your unique value (which it knows because it generated the 3d barcode when you setup the entry in the authenticator app) and the time and compares it to the code you entered. If the two match then your are authenticated.
So no on-line connection, the system works by using a shared secret value and a common time reference , the only requirement is that the time on your phone is reasonably accurate.
They are not communicating back and forth. In short, the app and site are using the same algorithm to calculate the same code at any given time.
When the authenticator is first set up, the authenticator and site “agree” on the same algorithm to use for all subsequent requests.
Like if I called you on the phone, at random, and we couldn’t talk until I told you today’s date, which is information you also know.
They don’t communicate. They both agreed *beforehand* on a Super Secret Math Code.
With the Super Secret Math Code, you can take the current time and put it into one end of the math, and you get some number out the other end. Since the site and the authenticator both agreed on the same Super Secret Math, they’ll both get the same answer to the math problem.
So authenticator says “according to the math that we agreed on, the answer based on the time now is 12345”. And the website says “based on the time right now, it looks like 12345 would be the right answer to the math we agreed on”.
Google, like pretty much every other major webiste, implements the [RFC 6238 TOTP](https://en.wikipedia.org/wiki/Time-based_one-time_password) for 2FA. Let’s break that down.
RFCs are standards for all things digital. It defines data formats, communication protocols, etc. We have them so all our internet devices speak the same language and know how to talk to each other. RFC 6238 is a standard defining TOTP, or time-based one-time passwords, a way to get time-based rotating codes.
The way it works is the server and client both share a secret, established when you first set up 2FA: when you set it up, accounts.google.com had your phone scan a QR code or else enter a string of random characters into the authenticator app. There is now a shared secret between the server and your phone’s authenticator app. Now based on that secret, your phone and the server feed that secret + the current time (truncated to 30 second increments from the Unix epoch) into a cryptographic hash function (and then does some further manipulation, like truncating the result and serializing it to decinal), which allows both of you to arrive without communication at the same result that is “unique” (or at least, hard to guess or compute) for the current 30 second slice of time and for your account.
Latest Answers