
Understanding How the Time-Based One-Time Password Algorithm Works - aryamansharda
https://blog.digitalbunker.dev/2020/08/27/how-do-time-based-one-time-password-totp-services-work/
======
asaph
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....](https://www.asaph.org/2016/04/google-authenticator-2fa-java.html)

[1]
[https://github.com/asaph/twofactorauth](https://github.com/asaph/twofactorauth)

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

------
margo209320
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
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
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
It's not all that difficult to remember a strong password, and if you use it
with pwdhash, it's unbreakable.

~~~
SAI_Peregrinus
But you need multiple strong passwords for (almost) every site. You need at
least one to start, and when one of those sites inevitably leaks all of its
passwords you'll have to change that one. Also 50% or more of the sites will
have incompatible password content rules, so you'll have to work around that.

Password managers are a lot easier than trying to keep the state for a
deterministic system. They're just as unbreakable with a good master password,
and actually work with real-world site's rules around passwords.

~~~
GoblinSlayer
See how it works:
[https://pwdhash.github.io/website/](https://pwdhash.github.io/website/) \-
the master password is hashed with the site name, you supply the resulting
hash as the password, you can't reverse this hash if the master password is
strong. The result has uppercase letters and lowercase letters and digits,
which is good enough for most sites. In practice I saw one site restricting
password length to 16 chars, but in case of a hash 16 chars are decent: they
contain 95 bits of entropy. And saw one site requiring fourth complexity -
punctuation characters - this is easy to circumvent by adding a minus at the
end, you can store this information in the open, since circumvention of
password policy doesn't affect password strength.

~~~
SAI_Peregrinus
I know how it works. It doesn't help the issues I listed. You can't change
passwords when required without storing a database of site names & increments
(or similar) to allow you to get the right password. So it's not stateless,
and you may as well get all the other benefits of a properly encrypted storage
database (autofill, metadata, storing extra things like TOTP keys, SSH keys,
etc).

------
supernova87a
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
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
Googling that, it appears to be available only on Android.

------
grijul
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)

------
madarcho
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...

~~~
tialaramex
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?

~~~
GoblinSlayer
Oh, do all dumbphones run unsigned code? Big if true.

~~~
tialaramex
I don't know about _all_ dumbphones, some models from last century (many of
which won't function on today's networks because the radio standards they need
are no longer deployed) aren't even smart enough to manage over-the-air
firmware updates and it may be impossible to meaningfully reprogram those.
But, like I said, if it doesn't speak a modern radio protocol it can't use the
network so who cares?

I believe a Nokia 6310 is just barely new enough that it should work
everywhere in the world, although I might be mistaken.

This phone (and many from that era) implement Java MIDP, a thin Java API to do
some simple things commonly across different models of mobile phone. In
particular we need to discover the UTC time (or at least a local time and then
use a stored offset) and remember a secret, and then calculate the TOTP code
and display it.

Getting a program _onto_ these phones isn't necessarily easy though. It's not
like they're running a web browser and you can just type in a URL somehow. You
need to either have a dedicated program and a cable to connect it to a PC, or
else you might be able to use WAP, a long obsolete simplified hypermedia
protocol for these phones.

------
mark254
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.

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

