The token label to be displayed inside the app - in our example, Google.The authenticator standard, HOTP or TOTP in this case, TOTP.The purpose of the URI - creation of an authentication token (that’s what otpauth at the beginning is for).Here’s an example of what it looks you can see, a whole bunch of parameters are transferred in the QR code, indicating the following: But either way, app-based authentication systems tend to use QR codes, in which a link (strictly speaking, a Uniform Resource Identifier, or URI) containing all the necessary information is encoded. And this leads us to the next question: how does these codes work? Authenticator QR code contentĪs far as I know, this is not among the standards developed by OATH, but rather a voluntary adherence to the format set by Google Authenticator. How do the app and the service come to an arrangement? In most cases, by means of a QR code. Additional parameters can also be set for creating tokens. When creating an authenticator, the client and the server must set a common standard and share the key - this is the absolute minimum required for the authenticator app to work. TOTP is the more common of course, simply because it’s better in every way, but HOTP can still be found in some prehistoric implementations. These two standards are used by authenticator apps. And since the interval after which the code changes is set rather short (30 seconds by default), if a one-time code is intercepted, the attacker won’t have much time to use it. And because the counter is based on Unix time, the code automatically changes at regular intervals, regardless of whether or not it is used.Īny internet-connected device now knows the exact time, so there’s no need to worry about one-time codes being out of sync. The principle remains the same: a secret key known to both parties is used to calculate a one-time code with the same cryptographic algorithm. In 2011, a new standard was unveiled - OATH TOTP (time-based one-time password), which uses the current time as a counter. Second, the code stays valid until the counter value changes - potentially giving an attacker time to use the intercepted code if they somehow manage to distract the victim. As a result, the generated codes no longer match. For example, if you request the authenticator to generate a code but don’t use it, the client-side authenticator changes the counter value, while on the service side it remains the same. First, the counter values easily get out of sync. So even if someone intercepts the one-time code, they won’t be able to calculate the secret key, reproduce the authenticator, and generate their own new codes. An algorithm is used that rules out performing reverse calculations and extracting the secret key from this code. What remains is to compare them: should the code you entered match the server-generated one, the authentication is successful.Īfter each request for a generation session, the counter value changes so that the code is one-time and unique. The data for calculating this code is the same on both sides, so if everything goes according to plan, the two codes will be identical. A counter is essentially a number that increments each time a new one-time code is generated. Next, a cryptographic algorithm is applied to generate a unique code based on this key and a counter value. The idea is that both the app and the service you’re using - remember the same secret key. This laid down the fundamentals of authentication using one-time codes that are synchronously generated on the client and server sides. Way back in 2005, the OATH HOTP (hash-based one-time password) authentication standard appeared. Authenticator apps are based on these standards (along with some other things, but which aren’t the topic of this post). Several open standards for strong authentication have been created under the umbrella of the Initiative for Open Authentication (OATH). Let’s start with how authenticator apps work in general. But if you’re curious about the whats, whys, and hows - read on… How authenticators work But what, if any, are the pitfalls? For those who have no time to read to the end, here’s the answer straight away: don’t worry, Google Authenticator is more than replaceable. Since these alternatives exist and clearly have a userbase, you might assume they could be full-fledged replacements for Google Authenticator. But is Google Authenticator the only option, or should you give one of the many alternatives - like Microsoft Authenticator or Twilio Authy - a whirl? Almost all services are compatible with it, and some even provide a link to the app when you set up 2FA. Google Authenticator is the most well-known and widely used authenticator app that generates such codes. Many online services allow (and sometimes even require) you to set up two-factor authentication (2FA) with one-time codes.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |