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
A Hacker Got All My Texts for $16
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. 😆 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
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)
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.
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
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)
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.
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? 🤔
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?
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. 👍
⁂
/gemlog/