Multi-Factor Authentication involving TOTP
==========================================

Until recently I have largely avoided MFA (Multi-Factor
Authentication) for anything but my bank. In fact (for my bank) I
didn't really even choose this, rather all banks in Norway require it.
;) I was issued with a small "key fob" (hardware token generator) that
I use as part of the login process.

Yes I have used SMS-based one time passwords historically on some
sites but such setups are problematic and not much of a security
improvement. Some argue they make things worse because the false sense
of security stops people using higher quality passwords. Here are just
a couple of articles that scratch the surface of this topic.

~ Company that routes SMS for all major US carriers was hacked for
  five years:
https://arstechnica.com/information-technology/2021/10/company-that-routes-sms-for-all-major-us-carriers-was-hacked-for-five-years/

~ A Hacker Got All My Texts for $16:
https://www.vice.com/en/article/y3g8wb/hacker-got-my-texts-16-dollars-sakari-netnumber

So over the years I have been relying on passwords (more recently with
a password manager) for all my access to websites. My avoidance of
extra "factors" for more secure logins, has primarily been down to
misunderstandings on my part.

Now that I have spent more time understanding this topic I have
decided to "brain dump" my thoughts and discoveries below. This post
is going to be a little long (20-30 mins read time) but perhaps it
will be helpful to someone out there. If not, it was still helpful to
me in organising my thoughts. ;)

Knowledge, possession, inherence and magic
------------------------------------------

When talking about MFA (of which 2FA [Two-Factor Authentication] is a
form), the most commonly mentioned factor types are:

* Knowledge: something you know, like a password

* Possession: something you have, like a key

* Inherence: something you about you (usually biometric), like a
  fingerprint

The first (knowledge) is all I have been using (in the form of
passwords) until recently because the others did not appear to be
viable options for me. The biggest part of my misunderstanding was
that making use them would likely involve me needing to upgrade my
phone or buying more (expensive) "things", both of which I would like
to avoid. Most people making use of inherence are using their
smartphone, via a fingerprint reader or camera with technology like
"Face ID"--interestingly in many cases these are still used in a one
factor sense, replacing a password, rather than being used in
addition. For the possession part, many people use apps like "Google
Authenticator", which is only available on smartphones.

I don't have a smartphone and have no current intention of buying one
(a story for another time), thus I figured I couldn't really do either
of the last two factors easily. Yes I could get a Yubikey (possession
again) but I was unsure if I wanted to commit to that both in terms of
the monetary cost and the effort in terms of management of backups.

The (recent) change was that the company I work for (Vivaldi) has
being pushing towards using 2FA and I needed to look at this again. We
quickly settled on TOTP (time-based one time passwords) as being the
first thing we would work towards.

 ``
  Any sufficiently advanced technology is indistinguishable from magic
  - Arthur C. Clarke


TOTP is the standard that Google Authenticator is using behind the
scenes and once I read up on this, I quickly realised that much of the
magic I imagined to be present wasn't there. XD That is not to say it
is bad, it is just not what I thought it was. I sort of thought that
this was Google tech, rather than a standard, in part because many
sites specifically mention "Google Authenticator" as though it is the
only option. I also incorrectly assumed that the reason you find apps
like Google Authenticator only on phones is that they were tied to
some special hardware included in the phone. They aren't and indeed,
whilst the majority TOTP implementations are for mobile versions,
there are certainly many desktop programs that can generate TOTP codes
once you look around. Indeed there are examples of TOTP software being
written in 20 lines of python code.

~ MinTOTP: a minimal TOTP generator written in Python:
https://github.com/susam/mintotp

What is TOTP?
-------------

Let's consider how TOTP actually works. At least on a high level.

One time passwords (also called "tokens") are about creating a
relatively short passcode that appears to be random. The
implementations we commonly see used are based on a key (also called
code, seed or secret) and a counter. These are combined together via a
complex calculation (involving a "cryptographic hash function"). This
is then truncated down to 6 digits (default). The point of this
process is to get a result that is hard to reverse. If you know the
result (and even the value of the counter), you cannot work out what
the key is, helping to keep that key secure. You do not need the
original key to login, just the generated OTP.

The system works like this. The website generates the initial key
(some alphanumeric text) that it shares with you (and only you). You
store this key inside some authentication software that knows how to
do the "complex calculation" and keeps track of the counter value.
When you want to login, you use your software to calculate the OTP (it
will use the key and the counter) and the website's software (which
also knows the key and the counter) does the same. Since you both have
the same inputs and do the same calculation you should get the same
result, even though the one time password appears to be "random" from
a human perspective.

The older, standard implementation of this was called HOTP (HMAC
[hash-based message authentication codes] one-time password). Here the
counter is updated each time a OTP is used (generated). However if you
(the user) view "extra" OTPs in your HOTP capable software without
logging in to the website, the counters (yours and the website's) can
get out of sync. Thus there is some re-syncing logic to deal with
this. I won't go into that now because this post is already going to
be very long and I really want to focus on TOTP but here is a link if
you are interested.

~ HMAC-based one-time password (Wikipedia):
https://en.wikipedia.org/wiki/HMAC-based_one-time_password

While there are likely still some places using HOTP and popular
authentication applications support it, most sites have moved onto a
newer standard, TOTP. The counter in time-based OTP is you guessed it,
time. More specifically the number of seconds since the start of the
year 1970, with no timezone offsets (yes... really! ;)). So long as
your authentication software and the website both have accurate
sources of time, the counter will remain in sync.

~ UNIX Epoch time:
https://en.wikipedia.org/wiki/Unix_time

There are a few other considerations. For TOTP, one time passwords are
typically created at 30 second intervals (default). Shorter would be
more secure as it would reduce the window of attack where a third
party, who somehow got access to the current OTP, would be able to
make use of it. However, it is also infeasible for a human to enter a
password fast enough for very short intervals (e.g. every second). So
we have 30 seconds as reasonable compromise. Websites using such
systems will often however calculate the password for the previous and
next 30 seconds and allow these to be entered a little bit early or a
little bit late. This is done for two reasons. If your clock has a
slight drift (i.e. it gained or lost time relative to the website) or
because you might have received the code just as it was changing.

Also if you have ever used a Token-Based Authenticator (HOTP/TOTP app)
like Google Authenticator on your phone you have likely scanned a QR
code. What is that all about? Well it is just the raw key and some
other information, such as your username and the website that issued
the key, encoded and presented in QR code format. There are also
sometimes optional values, like the number of digits displayed or the
time intervals (i.e. if the website wants more or less than 30
seconds). Rarely do websites change these values though as some
popular TOTP apps ignore any change from the defaults anyway.

~ Key Uri Format, Google Authenticator wiki:
https://github.com/google/google-authenticator/wiki/Key-Uri-Format

Scanning a QR code makes it easier to quickly transfer all this
information into your phone for storage in your TOTP app. That said,
normally you will also find the raw key written out on screen as well
in case you want/need to enter it manually (e.g. a faulty camera on
your phone). If the raw key is not written on screen there may be a
link that says something like "Can't read the code, click here" which
will then display it.

Is this really 2FA and why are the "apps" mobile based?
-------------------------------------------------------

So I will speculate here but I suspect I am on the right track. There
are two reasons that readily occur to me.

For TOTP to work it is exceptionally important that you have accurate
time because without this your TOTP software will be creating the
wrong key and thus you cannot login. Modern mobile phones are much
more likely to have accurate time. They typically have access to
multiple sources to accurate time keeping (internet-based time
servers, cellphone towers and GPS). Modern computers are also pretty
likely to have very accurate time keeping but sometimes time servers
are not configured (or misconfigured) and additional accurate time
sources are less likely to be available. For this reason you will
still sometimes find computers that are slightly out of sync and since
we are talking of relatively short timescales, that is pretty
problematic.

The other thing to consider is that you are basically using software
as part of the possession factor. You do not normally know the shared
key after your first receive it because that would be pretty hard for
most users to remember and you are not going to use it directly
anyway. You therefore "possess" it via the device that stores it.
Anyone who wants to login to a site as you, needs to have "the thing
that generates codes", i.e. your mobile phone (in addition to the
regular password).

The concept of a second factor makes the most sense when the thing
that generates the codes (your mobile in this case) is separate from
the thing you are entering them on (your computer). If you have both
your regular password (increasingly stored by people in a password
manager) and the key used to generate your OTP on stored on the same
computer, do you really have two factors? If you think of this another
way, if your computer is comprised and you login with that computer
the attacker potentially has access to both (the raw passwords and the
raw TOTP key). The multiple factor concept was specifically designed
to prevent this. On the other hand, if your TOTP generator is on your
phone then a compromised computer potentially gives the attacker
access to your password store but not your underlying TOTP code
generation (because they do not have the raw key). They may get the
OTP you manually input that one time (which granted might be enough
for their attack) but at least they have no access to generate a
future OTPs, so the attack vector is still somewhat reduced.

Incidentally some password managers (e.g. 1Password) can store the
both your passwords and your TOTP keys, and then present both to a
website for you. This is still likely an improvement over just a
password, as the "one-timeyness" makes it harder for nefarious third
parties, by limiting the window or attack (and of course it is highly
convenient for you) but at this stage it is clear that it is very much
single factor. To be 100% fair to 1Password, they fully admit and
understand this.

~ TOTP for 1Password users (blog post):
https://blog.1password.com/totp-for-1password-users/

The fact that requiring TOTP in addition to a password is not always
fully 2FA might be part of the reason that some providers prefer the
terminology "two-step authentication" and reserve terms such as 2FA
for the likes of hardware token (a Yubikey and Titan key) when used in
addition to passwords. They are perhaps covering their bases in their
choice or terminology. Somewhat related to this, Google doesn't even
allow login via TOTP for users who have joined their "Advanced
Protection Program". Only a hardware token will do. It is widely
agreed that such setups are more secure for this and other reasons,
which I will not go into here.

~ Advanced Protection Program:
https://landing.google.com/advancedprotection/

Backup codes and the problems with managing them
------------------------------------------------

While TOTP is a very clever system and increases security (even in
scenarios where it is not fully adding a second factor), it can work
against you when things go wrong. If OTPs become unavailable, you
could be permanently locked out of your account even if you know the
password. That this is intentional and baked into the design.

Consider a typical scenario where your TOTP authentication software is
running on your phone and you lose your phone. Like losing the keys to
your house or car, you now have a serious problem. While there are
exceptions, many popular TOTP applications will not sync copies your
raw TOTP keys anywhere, nor provide any way to export them. This is
done specifically to prevent them getting leaked or captured by those
wishing to compromise you. However, if you lose your phone that can
leave YOU in a very awkward situation as well.

To deal with this, as part of the signup process, most sites will also
offer you several "backup codes". These can be used in the event you
lose access to your TOTP app or the hardware it is running on. The
advice from websites is to store these "securely" but what does that
mean? You cannot just store these on your phone alongside your TOTP
app because if you lose your phone, you would lose them too and thus
they did not help you in the slightest. You can't just send them to
yourself via email or some other messenger. That might expose them on
route, particularly with unencrypted email or SMS. In addition if you
lose access to your email or messaging accounts in the future (because
they are potentially also protected by TOTP) you could not access
backup codes when you needed them anyway. Maybe you would want to
store them on your desktop machine but then you would need to encrypt
them to keep them secure in case your computer was compromised and
what if your hard drive fails one day? Perhaps you have a password
manager that can store encrypted/secure notes where you can place
them? But if your backup codes are stored alongside your passwords,
then you have certainly lost factor. Even if you are ok with that, if
you setup your password manger to use TOTP codes for login, you would
not be able to login in the first place. You could write them down (or
print them out) and store them in a safe place within your house (like
an actual safe). And if your house burns down? [thinks]

In reality there is no perfect answer that is correct for everyone.
Which is worse... having accounts compromised or being permanently
locked out of the accounts because you lost something? So stop and
think about how you will access them in the future if anything goes
wrong, while weighing up if they are "securely" stored.

You might even want to make a second copy and store them in two
"secure" places. Yes this may increase the chances that they can fall
into nefarious hands but also increases the chances they will be
available to you, should you need them. The main point I am making
here is that you really need to think this through carefully and work
out what is right "for you". But one thing you should not do is just
ignore the backup codes and think you don't need them. It is actually
pretty likely that you will want them at some point.

QR code and raw key backup
--------------------------

Since you are going to have to find a way to store those backup codes
"securely", I suggest you use whatever method you come up with, to
store something else at the same time. More specifically the original
key you were given and/or the QR code itself. This information was
provided to you before the backup codes. If for example you decided to
print out your backup codes, why not also print the page where the QR
code was provided and store it with your backup codes? Or write down
the raw key. This will make things a lot easier for you in the future,
not just in the worst case of a lost, stolen or broken phone but also
for various more every day scenarios.

Since many TOTP apps provides no way to export codes and no syncing,
this is your best chance to get this information. Consider you just
want to upgrade your phone (something we all do eventually). Without
the ability to export codes to your new device, upgrading a phone can
be quite involved with regards to TOTP. The process would be to login
to each and every service you have setup, temporarily disable 2FA then
start the setup process again, this time scanning the new QR codes
with your new phone. If you have 15 or more logins expect to spend
over an hour doing this. Imagine instead you have print outs of the
original 15+ QR codes. Now you can just scan them in one by one on
your new phone and will likely be done in less than a minute. Same
thing if you phone goes missing. No need to get out those backup
codes, just install a new app on your replacement phone and scan away.

Having the QR code or raw key also helps in other scenarios. Say there
is a service that more than one person in your family has access to,
like a VPN. In such scenarios people in the household will often share
a password (hopefully securely via a password manager that supports
this). But a password alone is not much help if this is a 2FA system
using TOTP. The person with the app still has to provide OTPs to
anyone who wants to login. Instead of this, more than one (trusted)
member of the household could scan the same QR into their own phones.
Now they would then both have a source for OTPs for that service. This
is actually not a hypothetical scenario or even a new idea but the
suggested practice of some providers.

~ How to enable 2FA for multiple users?:
https://support.surfshark.com/hc/en-us/articles/360011448379-How-to-enable-2FA-for-multiple-users-

You might argue, do you even need the backup codes in such a case, but
I would suggest that you should take them anyway. Printers can play
up, and a poorly printed QR code might not be scalable when you come
to need it. Similarly if you don't have a printer and wrote down
backup information by hand those raw TOTP keys are quite long and you
could easily write them down incorrectly (or perhaps you just have bad
hand writing). Backup codes on the other hand are relatively short and
you are often provided with several, thus there is a better chance
that at least one is useable.

Consider the options available from your TOTP app
--------------------------------------------------

While many TOTP apps will not provide key backup, sync or export (and
this is often by design), this is not universally true. Some will do
one or more of these and occasionally all three. Syncing your TOTP
keys to a second device (so long as the method is secure) is very
handy. If your phone is lost or stolen but you have another app
already configured on your desktop with a recent sync you won't even
need to rescan those backup up QR codes. On the other hand syncing
them to a multitude of devices increases the likelihood that someone
who should not have access, gets access, if any one of these devices
is compromised.

This is another area where you will have to make a judgement call. Now
that you understand how the process works, look at what the apps your
are using or choosing between actually do and the features they offer.
A software that does not backup, export or sync keys is not
necessarily worse than one that does. It is more secure but it is
putting the onus on you to handle all of that. On the other hand
syncing might decrease security but it is a lot more convenient,
especially when things go wrong.

Ok, I think that about covers my brain dump on 2FA and TOTP. Let me
know if I missed something or if anything was not clear. Stay safe and
stay secure. [+1]

* * *