This is Hacker Public Radio episode 3,784 for Thursday the 2nd of February 23.
Today's show is entitled, two factor authentication without a phone number.
It is part of the series' privacy and security.
It is hosted by Celeste and is about 18 minutes long.
It carries a clean flag.
The summary is, diving into privacy aware and offline methods to generate one-time passwords.
Today's show is licensed under a Creative Commons attribution non-commercial share alike license.
Hello everyone and welcome to this new Hacker Public Radio episode.
Today's topic is OTP or one-time password.
I'll go with them to generate them and how they work.
So first of all remember that Hacker Public Radio is a crowd-sourced podcast, so it's made
by people like you and if you have something to share make sure to record a podcast and
upload it.
It's really easy to go to the Hacker Public Radio.org slash calendar.php and book is lot.
So back to the main topic, one-time passwords.
They are one of the most common and easy to implement true factor authentication methods.
It is, when you try to login to a website, you enter your username and password and then
the website asks you some kind of possession factor, something you own and troll, something
you own and control to check who you are claiming to be.
One of the most basic examples is sending you an SMS with code and you need to enter that
code into the web page to complete the login process.
That works pretty well, unless you get scammed by someone at the phone pretending to be
the company asking you to tell them the code, but scamming aside, it works pretty decently.
And it's really easy to implement, you don't even need a complex algorithm on the server,
you just need random number and send that number via SMS to the user.
The problem with that is that the user has to give their phone number to the company managing
the service and you might not want to do that, also because we know that phone numbers
are working like a global universal identifier of yourself because you rarely change your
phone number, so it's very valuable and if you have people's phone number and maybe who
they contact, you can even reconstruct the social graph of a person, so it's very valuable
information.
You might not want to give that to external companies, also because there are much cleaner
and safer methods to achieve the same level of security of the SMS based one time password.
Virtual alternatives exist, one was used more or less 10 years ago by banks and now it got
almost replaced with the new one.
The old one is named HOTP, which stands for HMAC based one time password.
HMAC is a form of is a computation based on hashing functions, that combines a message
and a nursing function and a secret to produce a value and it's needed to ensure that
the message was not tampered with, so they got generated a long with the message and the
receiver read the access computation and if they get the same result, the message is legitimate.
In this context, it's used in order to produce some value and make the user recreate
that computation and get the same value, so even without communicating the client can generate
a valid code, which the server will understand and check its correct.
I guess it's confusing for now, but I will try to make some examples.
The HOTP works by combining true things, a secret and a counter, a secret is random number
shared by the client and the server, so both of them know and store this secret and the
second thing is the counter. It's a simple counter that is incremented each time a code
is generated. Maybe you remember those little tokens with the LCD screen that some banks
gave you a year ago with a single button and each time you press the button, a new code
is generated. That's a HMAC based one-time password generator, so the bank produces a secret
and stores it both in the server, both in the little token that they give you and they
are both initialized at the counter set at zero.
Then you try to login your banking system, you press the button and your token combines
the counter, which is one because it has been incremented, with the built-in secret that
it stored also on the bank side to produce a numeric code. You enter that code along with
your credential into the bank, the banking login system, and the bank, the bank server
read us did that exact computation. It takes the counter, which now it will be one and the
secret tries to redo the same computation and if it gets the same code as the one you
generated, then that's a valid code and it goes to the conclusion that you actually own
that token and you can again. Now you might say, hey, I can not enter the code fast enough
and maybe I have to press three or four times, or maybe the button on the token is pressed
by mistake, then the counter goes out of sync because the server thinks to be the counter
with the value one, while your token has been pressed actually maybe eight times, so
they are out of sync, and that's why the server actually doesn't check only the next
value in the counter, but it checks the next 80, or something like that, values in the press
in the button to check that even if they are out of sync, you can still log in even if you
make 20 unwanted presses on the token, and then when a new value code is entered, the counter
on the server is reset and the kept in sync again with the one on the token you own.
One attack, there's one attack on this type of token, that works, it's exactly exploiting
the fact that the server and the client are not in sync, and the server actually has a window
of anticipating and reading the next 80 codes, and they are still valid, so if someone takes
your credential and then has temporary access to your token, they can press the button even 10
times and write down the code that has been generated, so imagine that your server thinks
to be at counter one, your token is at counter one, and a attacker presses the button 10 times
and writes down the code generated for the counter value 2, 3, 4, 5, up to 11, up to
10, sorry, and then the 11, then the counter has the value 11, inside your token, while the
server still thinks to be at counter one, so the attacker goes away and leaves your token
where it was, you didn't notice anything, anything bad, and then the attacker takes that
credential, takes that code that have been generated for example for counter value 2, and that
code is valid, because the server thinks, hey, I'm at counter number 1, and the code I received
is from counter number 2, so it's valid, and then the attacker puts counter number 3,
the code generated by the counter number 3, and that's valid too, up to 11, 1, so unless
you log in with your token before the attacker, the attacker can successfully enter a lot
of valid codes, my exploiting that out of signature of this type of token and generation,
so there has been a new way of generating the one-time passwords, which is still offline,
it still doesn't need any phone number, and it's a bit more robust about this, and it's
called TOTP, it stands for time-based one-time password, instead of using the counter to combine
it with the secret key to generate a one-time password, they use the milliseconds from epoch,
the unique time, the number of milliseconds, or seconds maybe, the number of seconds, yeah,
I think it's correct to say seconds here, they use the number of seconds from epochs from
first January 1970, rounded up to steps of 30 seconds each, as a value, to combine with the
secret key, that is shown from both from the server and the client, to produce the numeric code,
the one-time password, the actual one-time password, so we don't have the problem of being
out of sync anymore, because as long as the client device has a correct time stamp, a current
date and time, it will generate the same one-time password as the server, by only knowing
the current time and the secret key, which is shared between the two, in this way you can no longer
press a button and create 10 or 20 valid codes to be used later, because the generated codes
extremely tied to the current time stamp, so unless you know the secret that is combined with the code,
it's combined with the time stamp to generate the code, unless you know that secret, you can
not forge new codes, but before you could just press the button and write down the valid codes
and use them in the correct order, and you can log in in the bank account of sound one,
which is what's quite bad, how do you use time-based one-time password today,
you can use an authenticator up, there are many dual mobile Google authenticator and similar,
but I highly suggest you, IGs for Android, it's called AEGIS, it's on Android, it's completely
free and open source and it works, as I said, the calculation it does it, it's simply straightforward,
it just takes the current time stamp, it's around it, and it combines it with the secret key
to produce a hash digest, and that's used to create a short numeric code to enter.
Another alternative is to use a password manager like QPSXC, which is QT-based, the password manager
for desktop computer Windows and Linux, like, it actually is used only to store passwords,
static passwords, but if you write a leak on an entry, you can access the set TOTP menu,
where the QPSXC can store the secret key and generate the time-based password for you,
and that's it, you can use that to login, copy and paste it into the clipboard and paste it into
the login form. Another advantage is of this TOTP one-time passwords compared to the
HOTP token-based ones that were available in the past, is that you can easily replicate if you
have access to the secret key, you can easily make a backup of that and replicate it on many
devices. For instance, I have saved the secret key to generate the one-time password in QPSXC,
and then I copied that in Android app, and they both work and give the same result because
they don't, they are not dependent on a counter that could go out of sync between the devices,
they're only dependent on the secret key, which is static and the same, and the current time
stamp, which is available for both devices, both the computer, both the Android phone.
So it really works to have a backup of the two-factor authentication method, just in case
you don't get your self-locked out of important accounts. Another
maybe in the future I could try to talk about web both and security key-based authentication,
but that's it for today, and I hope you enjoyed it, and I hope you don't sound
thing, let me know if you have some new details of if I made some mistake during the podcast. Bye,
and see you next time!
On the side of our status, today's show is released on our creative comments,
attribution for going to international license.