7 ms·

Understanding How the Time-Based One-Time Password Algorithm Works

110 points by aryamansharda 6y ago

supernova87a 6y ago
Years ago it took me a few times encountering these keys to realize how they were working (like for Google, etc). Now, on being presented any shared secret to initialize my Authenticator app, I screen capture / print out the secret and store it in my files at home. Just like those recovery codes. Too much of my life is with Google not to have this stored somewhere safe.
- modeless 6y ago
  Google Authenticator now allows exporting your entire list as a single QR code, so you don't have to save the initial QR code. It's a godsend for migrating between phones.
  - DennisP 6y ago
    Googling that, it appears to be available only on Android.
- riffraff 6y ago
  not affiliated with them, but I have used Authy for years for the simple reason that they allow easy sync across devices, backup, and import/export of the credential list. It's another party to trust, but I prefer it to google authenticator.
  - ahelwer 6y ago
    Yeah. I keep my Authy backup password in a tiny safe along with other important documents (note: NOT in my password manager, since that would reduce 2FA to 1FA). Last time my phone died a couple years back I just got a new one, registered it to my phone number, downloaded Authy, verified the phone number, entered my paper backup password, and I was good to go. The way Authy is set up this makes me immune to SIM cloning attacks, because they offer no recovery method if you lose your backup password. As an additional 2FA backup I keep one of those cheap Yubico security keys in the safe, registered to as many sites as will accept them.
- thinkmassive 6y ago
  Some sites only display the QR code. For those I found ZBar Barcode Tools helpful for converting an image/screenshot to alphanumeric seed: https://github.com/mchehab/zbar https://github.com/mchehab/zbar
arunchan27 6y ago
I didn't know how it worked. Thanks for the blog.
margo209320 6y ago
What confuses me is that TOTP is usually referred to as "something you have" (the app on your smartphone, with the secret), as opposed to "something you know" (your password). But the TOTP algorithm and the current time is known to any attacker. What remains, is just the secret, which is the same as a password (a password given to you by the service provider instead of a self-chosen one). So in the end, TOTP just increases password complexity, doesn't it? EDIT Trying to answer my question: it prevents a MITM attacker from sniffing your password hash once and using that forever, since the TOTP code is different each time and the attacker would still need to brute-force the secret. But if that's the only benefit of using TOTP, couldn't that be combined with the password: The service where I want to authenticate sends me a "challenge" (random number), I enter my password and an algorithm on my client combines the challenge and my password-hash to create the result to send back to the service. This way the value sent over the insecure line is always different, since it is based on the challenge. The user would not have the added inconvenience of having to enter the TOTP code.
- metafunctor 6y ago
  Kind of, but TOTP differs from passwords in important ways. Unlike user-selected passwords, the TOTP secret is guaranteed to be unique and strong as it's generated by the server. Observing some TOTP codes doesn't reveal the secret, so even if the password leaks the TOTP secret probably remains safe. Finally, the TOTP secret is typically managed in a device separate from the one where the TOTP code is entered, making it harder to steal.
  - earthboundkid 6y ago
    I think you can get most of the advantages by just assigning users their passwords. Users either have a password manager to store the assigned password in, or they’re totally insecure and can’t be trusted to make up a password. Either way, just assign something random to them.
    - GoblinSlayer 6y ago
      It's not all that difficult to remember a strong password, and if you use it with pwdhash, it's unbreakable.
suprfsat 6y ago
>TOPT and HOPT
madarcho 6y ago
So the HOTP/TOTP rely on the same secret being stored "plaintext" by both the server and the client? I am guessing this is not as concerning at all, as storing a password plaintext on the server, since this mechanism is used _on top of_ a password...
- DavidSJ 6y ago
  If the server had a public key with which it could verify OTPs, then the small search space (only 1 million for 6-digit OTPs) means an attacker with that key could also produce one.
- dafoex 6y ago
  Ideally the secrets would be encrypted to prevent outside snooping (and my authenticator app does this at my end) but it would seem that at some point the secret does need to be in plain text at some point.
- tialaramex 6y ago
  Yes. The main thing going for these mechanisms is that they're so cheap to implement. A Nokia 6310 can run the algorithm, the set of people who could receive SMS based one time codes but can't do TOTP on their phone is close to zero. If you have a "programmer" employed and they can't add TOTP to your system check they said "computer programmer" - my father was a "programmer" who figured out the "programme" as in schedule for a paper factory, that's the wrong kind. In every other respect they're pretty bad: The article suggests they can resist phishing. Against a poor adversary (e.g. Email links to a web form masquerading as "fraud check" by your bank) that hasn't considered TOTP they might be enough, but there are ready-to-use tools to help phish TOTP, SMS one time codes, RSA-style key fobs, even the old crude Yubikey one time code thing where you press a button and it squirts text into a form field. If either the server or the client gets knocked over, the attackers get this long term underlying secret that they can use to fulfil the role of the other permanently. It's not as likely you'd stupidly log the underlying secret as a password sent to your server in an HTTP POST request, but you still might do it and then you're screwed. The right take away is probably that this is the low bar, it's so easy that it's inexcusable for a site to pretend it cares you used a "good" password (e.g. by having password complexity rules or requiring Pwned Passwords checks) and then not even bother having TOTP. Oh you want me to put in real effort to protect your stupid web site but then you aren't even doing the bare minimum, how about fuck off?
asaph 6y ago
I did my own deep dive on TOTP a few years ago and wrote a blog post on how to implement a Google Authenticator compatible 2fa system in java including generating QR codes[0]. Demo code is on GitHub[1]. [0] https://www.asaph.org/2016/04/google-authenticator-2fa-java.html https://www.asaph.org/2016/04/google-authenticator-2fa-java.... [1] https://github.com/asaph/twofactorauth https://github.com/asaph/twofactorauth
- nazgulsenpai 6y ago
  The code samples make it super easy to follow. This is fantastic; thank you for sharing!
mark254 6y ago
There's an bug - the base64 value is being hex-encoded, not the binary SHA1 result. So the hex values are wrong, and the rest as well.
grijul 6y ago
I wrote a TOTP library and a client program that uses this library (in C - as an attempt of learning C) to make the desktop tool compatible with andOTP encrypted files. Things went well. I was able to get OTPs from andOTP encrypted JSON files. But I am unable to get time to work on it further. The code is open-source. It was fun :) https://gitlab.com/grijul/libzotp https://gitlab.com/grijul/libzotp https://gitlab.com/grijul/zotp https://gitlab.com/grijul/zotp

110 points by aryamansharda 6y ago

Years ago it took me a few times encountering these keys to realize how they were working (like for Google, etc). Now, on being presented any shared secret to initialize my Authenticator app, I screen capture / print out the secret and store it in my files at home. Just like those recovery codes. Too much of my life is with Google not to have this stored somewhere safe.

modeless 6y ago
Google Authenticator now allows exporting your entire list as a single QR code, so you don't have to save the initial QR code. It's a godsend for migrating between phones.
- DennisP 6y ago
  Googling that, it appears to be available only on Android.
riffraff 6y ago
not affiliated with them, but I have used Authy for years for the simple reason that they allow easy sync across devices, backup, and import/export of the credential list. It's another party to trust, but I prefer it to google authenticator.
- ahelwer 6y ago
  Yeah. I keep my Authy backup password in a tiny safe along with other important documents (note: NOT in my password manager, since that would reduce 2FA to 1FA). Last time my phone died a couple years back I just got a new one, registered it to my phone number, downloaded Authy, verified the phone number, entered my paper backup password, and I was good to go. The way Authy is set up this makes me immune to SIM cloning attacks, because they offer no recovery method if you lose your backup password. As an additional 2FA backup I keep one of those cheap Yubico security keys in the safe, registered to as many sites as will accept them.
thinkmassive 6y ago
Some sites only display the QR code. For those I found ZBar Barcode Tools helpful for converting an image/screenshot to alphanumeric seed: https://github.com/mchehab/zbar https://github.com/mchehab/zbar

arunchan27 6y ago

I didn't know how it worked. Thanks for the blog.

margo209320 6y ago

What confuses me is that TOTP is usually referred to as "something you have" (the app on your smartphone, with the secret), as opposed to "something you know" (your password). But the TOTP algorithm and the current time is known to any attacker. What remains, is just the secret, which is the same as a password (a password given to you by the service provider instead of a self-chosen one). So in the end, TOTP just increases password complexity, doesn't it? EDIT Trying to answer my question: it prevents a MITM attacker from sniffing your password hash once and using that forever, since the TOTP code is different each time and the attacker would still need to brute-force the secret. But if that's the only benefit of using TOTP, couldn't that be combined with the password: The service where I want to authenticate sends me a "challenge" (random number), I enter my password and an algorithm on my client combines the challenge and my password-hash to create the result to send back to the service. This way the value sent over the insecure line is always different, since it is based on the challenge. The user would not have the added inconvenience of having to enter the TOTP code.

metafunctor 6y ago
Kind of, but TOTP differs from passwords in important ways. Unlike user-selected passwords, the TOTP secret is guaranteed to be unique and strong as it's generated by the server. Observing some TOTP codes doesn't reveal the secret, so even if the password leaks the TOTP secret probably remains safe. Finally, the TOTP secret is typically managed in a device separate from the one where the TOTP code is entered, making it harder to steal.
- earthboundkid 6y ago
  I think you can get most of the advantages by just assigning users their passwords. Users either have a password manager to store the assigned password in, or they’re totally insecure and can’t be trusted to make up a password. Either way, just assign something random to them.
  - GoblinSlayer 6y ago
    It's not all that difficult to remember a strong password, and if you use it with pwdhash, it's unbreakable.

suprfsat 6y ago

>TOPT and HOPT

madarcho 6y ago

So the HOTP/TOTP rely on the same secret being stored "plaintext" by both the server and the client? I am guessing this is not as concerning at all, as storing a password plaintext on the server, since this mechanism is used _on top of_ a password...

DavidSJ 6y ago
If the server had a public key with which it could verify OTPs, then the small search space (only 1 million for 6-digit OTPs) means an attacker with that key could also produce one.
dafoex 6y ago
Ideally the secrets would be encrypted to prevent outside snooping (and my authenticator app does this at my end) but it would seem that at some point the secret does need to be in plain text at some point.
tialaramex 6y ago
Yes. The main thing going for these mechanisms is that they're so cheap to implement. A Nokia 6310 can run the algorithm, the set of people who could receive SMS based one time codes but can't do TOTP on their phone is close to zero. If you have a "programmer" employed and they can't add TOTP to your system check they said "computer programmer" - my father was a "programmer" who figured out the "programme" as in schedule for a paper factory, that's the wrong kind. In every other respect they're pretty bad: The article suggests they can resist phishing. Against a poor adversary (e.g. Email links to a web form masquerading as "fraud check" by your bank) that hasn't considered TOTP they might be enough, but there are ready-to-use tools to help phish TOTP, SMS one time codes, RSA-style key fobs, even the old crude Yubikey one time code thing where you press a button and it squirts text into a form field. If either the server or the client gets knocked over, the attackers get this long term underlying secret that they can use to fulfil the role of the other permanently. It's not as likely you'd stupidly log the underlying secret as a password sent to your server in an HTTP POST request, but you still might do it and then you're screwed. The right take away is probably that this is the low bar, it's so easy that it's inexcusable for a site to pretend it cares you used a "good" password (e.g. by having password complexity rules or requiring Pwned Passwords checks) and then not even bother having TOTP. Oh you want me to put in real effort to protect your stupid web site but then you aren't even doing the bare minimum, how about fuck off?

asaph 6y ago

I did my own deep dive on TOTP a few years ago and wrote a blog post on how to implement a Google Authenticator compatible 2fa system in java including generating QR codes[0]. Demo code is on GitHub[1]. [0] https://www.asaph.org/2016/04/google-authenticator-2fa-java.html https://www.asaph.org/2016/04/google-authenticator-2fa-java.... [1] https://github.com/asaph/twofactorauth https://github.com/asaph/twofactorauth

nazgulsenpai 6y ago
The code samples make it super easy to follow. This is fantastic; thank you for sharing!

mark254 6y ago

There's an bug - the base64 value is being hex-encoded, not the binary SHA1 result. So the hex values are wrong, and the rest as well.

grijul 6y ago

I wrote a TOTP library and a client program that uses this library (in C - as an attempt of learning C) to make the desktop tool compatible with andOTP encrypted files. Things went well. I was able to get OTPs from andOTP encrypted JSON files. But I am unable to get time to work on it further. The code is open-source. It was fun :) https://gitlab.com/grijul/libzotp https://gitlab.com/grijul/libzotp https://gitlab.com/grijul/zotp https://gitlab.com/grijul/zotp