What if you could have a secure password generated fresh each time you need it? Authenticator apps do just that. Tom explains how.
Featuring Tom Merritt.
Please SUBSCRIBE HERE.
A special thanks to all our supporters–without you, none of this would be possible. Become a supporter at the Know A Little More Patreon page for exclusive content and ad-free episodes.
Thanks to Kevin MacLeod of Incompetech.com for the theme music.
Thanks to Garrett Weinzierl for the logo!
Thanks to our mods, Kylde, Jack_Shid, KAPT_Kipper, and scottierowland on the subreddit
Send us email to feedback@dailytechnewsshow.com
Episode transcript:
If you’ve heard our episode on multifactor authentication, you probably already know that authenticator apps are one of your choices for securing an account. If you haven’t, here’s a quick explanation. Multifactor authentication makes your account more secure by requiring two different types of authentication to log you in. Typically this is a password, something you know, and a second thing, something you have. The something you have could be a physical object like a Yubikey – that you stick in a USB port, or might could also be a text message with a code you need to type in, – making the something you have be your phone- which is probably the most common method people will experience these days. But SMS can be intercepted sometimes, so a more secure way, that is a bit more convenient than a physical key, is an authenticator app. The app generates a new numeric code on a set time scale. Typically a six-digit code every 30 seconds. When you log in you put in your password, then the site asks for your code. You open the authenticator app, look at the code, type it in, and you’re in.
It’s secure because you’re the only one who has your phone and the code is not traveling over the internet (or by text message), so nobody can intercept it. But if there’s no communication between the site and your authenticator app, how does it know your code is right?
Let’s help you know a little more about authenticator apps.
The code the authenticators generate is called a Time-based One-Time Password or TOTP. Why not TBOTP? I think you can immediately tell why.
Anyway It’s all right there in the name, time-based one-time. It’s a code that is only meant to be used once, and within a limited amount of time. It’s different from your regular password because you don’t know it. You have to look at the authenticator generating it, to know what it is at any given moment. And since you have the app, it counts as something you have.
So where does that code- that TOTP come from? How is that made. It is created by an algorithm. Identical versions of the algorithm run both in your authenticator app and the server you are trying to log into. To distinguish your code from all the other people trying to log in, you use a shared secret that only the server and the authenticator app have access to.
Typically the shared secret is created on the server and then shared with the authenticator app. It’s quite often a QR code you scan, since the apps usually run on phones with cameras. But it can also be a longer code you type in manually.
Either way the connection to the server is end-to-end encrypted to stop any eavesdropping. And the shared secrets are stored with strong encryption at rest on both ends.
That secret is unique to the device it’s on and to the user it’s associated with on the server. There’s a lot of complex math of course to make it hard to predict but essentially, to oversimplify, the algorithm makes what’s called a hash combining the current time to the nearest 30 seconds with your shared secret.
And no, you don’t need to be in the same time zone as the site you’re logging into.
The time isn’t your clock time, it’s UNIX time, so it’s not affected by time zones. Unix time is the number of seconds elapsed from January 1, 1970 00:00:00 UTC. The server and the device just need to have a way of tracking current time either by an internal clock or checking server time. Even so, there may be some drift between the two, especially because of internet latency and such. So the time is usually rounded to the nearest thirty seconds so your clocks just need to be close, not precisely the same. As long as the device you have can calculate the correct time within 30 seconds, then it will calculate the same number as the server.
That code refreshes with a new one every 30 seconds so that if someone were to see your code they couldn’t use it later. And because humans can be slow, some implementations will count the previous code as accurate, but that still limits the usefulness to 60 seconds.
Here’s another way to think about it.
Kelly and Al want to be certain that their text messages have not been compromised. So they agree on a system to put a code in their text messages so they can be sure it’s them. However they’re really paranoid, so they want to change the code every hour, that way somebody can’t just see one of their messages and have the code. But they also can’t always be checking in with each other on the code, or else why would they need to text right? So they agree to take their mutual favorite number, 1,590,876 and multiply it by the hour. So at 10 AM the code would be 15,908,760 but at 11 AM the code would be 17,499,636. Granted it wouldn’t be impossible for someone to reverse engineer this, so in practice TOTP systems use much more complicated hashing algorithms that are almost impossible to reverse engineer with current computer power.
The point of all this is that if your username and password gets leaked, an attacker would not be able to get into your account without also getting your authenticator code. And to get the code they would need to get your device away from you or crack into the server and get the algorithm and decrypt the shared secret. The server method is extremely hard. The device method would also be hard and made more difficult if you protect the phone on which you run the authenticator app with thumbprint or Face ID and a hard to crack passcode.
Of course the downside is that if you lose your phone, you lose the authenticator app. Most sites have a recovery mechanism in those cases but they intentionally make them very difficult to deter malicious actors. Apps like Authy let you share your secret between devices, and store it in the cloud but that does mildly reduce the security since you have more than one device that could be stolen. You’re also trusting their cloud encryption to protect your shared secret. Similar to how you trust the server of course, but now all your shared secrets are in one place.
But in the end it’s pretty simple. You share a secret securely between the app and the server you want to log into. Your app and the server use the same algorithm to calculate a code based on the UNIX time and your shared secret. That code changes every 30 seconds or so but all you need to do is have your phone on you and look at it and type it in when you need to log in. And your login is made more secure.
Passkeys are going to make this process even easier by automating some of this process for you so you don’t have to do anything but have the device. We have an episode about Passkeys as well if you want to find out more about those.
Thanks to BigJim for the email suggesting this topic! I hope he and you know a little more about authenticator apps.
CREDITS
Know A Little More is available without ads to direct supporters at patreon.com/knowalittlemore. It was researched, written and hosted by me, Tom Merritt. Editing and production provided by Anthony Lemos and Dog and Pony Show Audio. It’s issued under a Creative Commons Share Attribution 4.0 International License.