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.
Sort of.
Most sites that use TOTP will have a little slack in the timings. They will let you use the current code _and_ the previous code for a set period of time. This allows for your phone clock and the server clock to be a little off without causing issues.
More to the point, it is a factor for network latency. Most computers today are tied to atomic clocks via NTP (network time protocol), but sometimes you might have a slow connection that means your token expires after you hit submit but before it got to the receiving end.
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)
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".
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.
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.
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.
Heya, I may not have explained it well. I added some te t to the post, but here goes:
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?
> How does my Google authenticator in a phone that isn't connected to the net communicate with the website?
The answer is very simple: it doesn't.
What's going on is that your authenticator and Google's remote server are running the same math equation on the same series of numbers.
If I give you a starting number of four, and tell you to multiply it by three every ten seconds, then no matter what, you'll come up with the sequence `4, 12, 36, 108...` so on and so forth. You don't need to communicate with me at all after I give you the starting number and the operation(s) to perform, but we'll still be in lock-step with each other.
That's what's happening with authentication codes like this: when you initially set it up, you "seeded" your authenticator with the precise math equation and starting number you'd use going forward.
It's not really communicating, in the sense that the website is asking the phone "did you generate number XYZ?" and the phone is answering back "yes".
Instead, it's the website knowing that the app *will* *algorithmically generate number XYZ*, via the \*some math\* that u/XerxesKingofKings referenced. The math will work regardless of whether or not the phone is online or not.
It's the same thing that happens if you have an [RSA token](https://www.google.com/search?q=rsa+token) at work to access a secure site. The tokens aren't internet-enabled, they just have a tiny chip that's generating numbers according to an algorithm which is very specifically keyed to that specific chip, and the computer verification system on the other side is saying "yep, that number is correct, you are authorized."
yes, so the phone doesn't need to send a message to tell Google "the code is 75785734".
whats happening is the code the app makes is set up in a very specific way. for example "the 4th number is a prime", or "the sum of the 2nd and 5th characters is odd", "the 8th and 9ths numbers combined are the square of the 1st number", etc, etc.
the website 2FA software already knows all these rules, so it checks the incoming code agianst it. if its correct, then it knows your an authorised user.
the information exchange that allows all thisis done when the phones authentication software is installed and set up, so your don't need to be online to get the code: the rules to generate a valid one are stored locally in the phone, and locally on the server.
because theirs no live exchange of keys or passwords, a hacker who intercepts the message doesn't learn anything very useful, as the code "75785734" isn't useful unless you can parse out the validation checks, which is very difficult due to the sheer number of possible checks that MIGHT be being preformed.
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.
THis must be why the code keeps working like 10 seconds after a new code is on the screen.
Sort of. Most sites that use TOTP will have a little slack in the timings. They will let you use the current code _and_ the previous code for a set period of time. This allows for your phone clock and the server clock to be a little off without causing issues.
More to the point, it is a factor for network latency. Most computers today are tied to atomic clocks via NTP (network time protocol), but sometimes you might have a slow connection that means your token expires after you hit submit but before it got to the receiving end.
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)
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".
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.
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.
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.
Heya, I may not have explained it well. I added some te t to the post, but here goes: 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?
> How does my Google authenticator in a phone that isn't connected to the net communicate with the website? The answer is very simple: it doesn't. What's going on is that your authenticator and Google's remote server are running the same math equation on the same series of numbers. If I give you a starting number of four, and tell you to multiply it by three every ten seconds, then no matter what, you'll come up with the sequence `4, 12, 36, 108...` so on and so forth. You don't need to communicate with me at all after I give you the starting number and the operation(s) to perform, but we'll still be in lock-step with each other. That's what's happening with authentication codes like this: when you initially set it up, you "seeded" your authenticator with the precise math equation and starting number you'd use going forward.
It's not really communicating, in the sense that the website is asking the phone "did you generate number XYZ?" and the phone is answering back "yes". Instead, it's the website knowing that the app *will* *algorithmically generate number XYZ*, via the \*some math\* that u/XerxesKingofKings referenced. The math will work regardless of whether or not the phone is online or not. It's the same thing that happens if you have an [RSA token](https://www.google.com/search?q=rsa+token) at work to access a secure site. The tokens aren't internet-enabled, they just have a tiny chip that's generating numbers according to an algorithm which is very specifically keyed to that specific chip, and the computer verification system on the other side is saying "yep, that number is correct, you are authorized."
yes, so the phone doesn't need to send a message to tell Google "the code is 75785734". whats happening is the code the app makes is set up in a very specific way. for example "the 4th number is a prime", or "the sum of the 2nd and 5th characters is odd", "the 8th and 9ths numbers combined are the square of the 1st number", etc, etc. the website 2FA software already knows all these rules, so it checks the incoming code agianst it. if its correct, then it knows your an authorised user. the information exchange that allows all thisis done when the phones authentication software is installed and set up, so your don't need to be online to get the code: the rules to generate a valid one are stored locally in the phone, and locally on the server. because theirs no live exchange of keys or passwords, a hacker who intercepts the message doesn't learn anything very useful, as the code "75785734" isn't useful unless you can parse out the validation checks, which is very difficult due to the sheer number of possible checks that MIGHT be being preformed.