Are TOTP (Time-based One Time Password) authentication apps better than passwords?

The short answer: Only if you are bad at passwords. Otherwise, probably not.

Want to protect your information with better and easier Multi-Factor Authentication? BrilliantRoot Three-Factor Authentication is more secure and works almost invisibly. Let us know how we can help!

The long answer:

As more and more IT services have been forced into the public cloud, we have been experiencing more and more of the downsides of relying on passwords for security. And, as usual, service providers have come up with a solution that allows them make their customers feel more secure than they really should, and gives them room to blame their customers for any resulting security failures.

In order to really understand this, We’ll need take you on a tour of the spy-versus-spy world of breaking into systems using stolen credentials. The reason for this journey is so that we can compare and contrast the world of username + password authentication with username + password + one time password authentication, and what you will see is that almost nothing has changed.

In the Beginning, There Was the Username and Password.

Getting access into a computer system involves a set of problems we abbreviate to AAA: Authentication, Authorization, and Accounting. Authentication involves knowing who is accessing the system, Authorization involves knowing what they are allowed to do with the system, and Accounting involves keeping an audit log of activity. We’re focused on the Authentication part here.

From the very first shared computer systems to the most modern cloud-based distributed systems, we have come to rely almost exclusively on the same two things: The Username and the Password. This worked reasonably well in the simple and trusting islands of simple, low-power computer systems that existed before everything in the world started becoming interconnected on the global Internet. Virtually everyone is familiar with the user’s side of this process and that story is mostly tedious and boring, so we’ll be looking at it from the attacker’s side of things. This brings us to our first two Geek Concepts:

Geek Concept 1: Shared Secret Authentication

Shared Secret Authentication means that two (or more) parties know a secret of some sort – the easiest example of this is a password – and use knowledge of that shared secret, usually in addition to some sort of name that identifies a specific user, to allow the user to identify (authenticate) themselves to the system they’re connecting to.

Geek Concept 2: Entropy

Entropy is just a fancy word used to for describing randomness. Randomness is important for security, because if all parts of a security system are working properly then bypassing it requires an attacker to deal with some random factor. For discussing security, we use it to refer to the number of guesses it would take to arrive at a password or other secret thing.

The easiest way to describe this in a non-technical way is the PIN code for your phone or ATM card. If you have a four-digit pin, there are 10,000 possible combinations (0000 – 9999), or a for a six-digit pin there are 1,000,000 possible combinations (000000 – 999999). From a security standpoint, 10,000 or 1,000,000 would define the amount of entropy in the combination, or how many guesses you would have to make to be able to guarantee you can find the answer.

Well, that’s the amount of entropy in theory. The problem is that the human mind hates randomness. In fact, when confronted with random information our brains will try to create patterns out of it. This results in anything from rational problem solving and deductive investigation work to crazy conspiracy theories. It also means that we are terrible at choosing PINs and passwords. In fiction, there’s a common trope for guessing the combination to a safe with a dial-lock: the answer is usually an important date like a birthday or anniversary, or a woman’s measurements, because these are easy to remember. The same thing applies to PINs and passwords: a human mind is absolutely incapable of choosing one at random on its own. We are literally not only wired that way; in fact, we are explicitly wired against it. Our brains hate random. So while in theory there are 10,000 possible combinations to a 4-digit PIN, the reality is that most people, when allowed to choose, will chose from a set of a few dozen. So for practical purposes the amount of entropy in a user-selected four-digit PIN is well under 100, or less than 1% of what it is in theory.

The same thing goes for passwords. The amount of entropy in the average person’s password is tiny unless they use a password management system with randomly-generated passwords. When a meaningful amount of entropy exists in a security system, then we have a challenge worth discussing. It doesn’t mean that the challenge can’t be overcome, it just means that it has become interesting.

There are only a few categories of ways to bypass Shared Secret Authentication systems like the Username & Password combination (we generally assume that the username is already known), and these really haven’t changed much over the years.

• Guess or Brute-Force the Password at login. Either just guess the password using information about the user that you know, or just have your computer try every possible combination. Even a random password doesn’t have enough entropy to defeat brute-forcing, and most passwords aren’t random.
• MITM (Machine-In-The-Middle) and other eavesdropping / system impersonation attacks: These involve the attackers system either invisibly injecting itself into the middle of the conversation between the user’s system and the system they are logging into, or spying on the communications between the various machines involved.
• Human Tricks the Human (also called “Social Engineering”) attacks. The attacker uses some sort of scam, often pretending to be a tech support or customer service representative but countless clever variations exist, and tricks the user into giving up their password.
• Steal the Password Directly. As people have had to deal with more and more password, they have had to rely on tools to manage them. On the end-user side of things, these range from the post-it note on the screen (yes, this still happens to this day), to a word processor or spreadsheet file with passwords (yes, still very common), to modern-day password managers. On the system side of things, there are usernames and passwords are stored either in password files or in a database. Breaking into a system would give an attacker a complete list of usernames and passwords, and also the opportunity to steal them as they are entered when people log in.

Guessing or Brute-Forcing the Password at Login.

This has been the easiest intrusion method to defeat at the login screen: simply limit the number of guesses allowed. After a certain number, introduce speed-bumps like captchas or other problems that a human can solve easily but require a lot of effort for a machine. If these speed-bumps are insufficient, then lock out the account for a period of time or until a human can intervene and set things straight.

MITM (Machine-In-The-Middle) and other eavesdropping / system impersonation attacks.

Eavesdropping attacks are far less common these days because virtually everyone uses encryption, and contrary to what you see in movies and television encryption itself is virtually never broken. Encryption keys are stolen, cracks around and mistakes using the encryption are exploited, and other indirect ways of getting in and around are always a thing, but modern encryption itself is pretty solid.

The problem with encryption is that its use is only as good as the user’s ability to make sure that they are talking to the system that they believe they are talking to. If a user wanting to make a secure, encrypted connection to www.myglobalbank.com can be tricked into making a secure, encrypted connection to a malicious MITM system at www.mygIοbalbank.com then the attacker can get their username and password. Oh, wait, you don’t see the difference between www.myglobalbank.com and www.myglοbalbank.com? Let’s use a different font and break it down:

     www.myglobalbank.com
     www.myglοbalbank.com
             ⇧

There is a lower-case Latin alphabet “o” in the correct domain name and an lower-case Greek letter “ο” (omicron) in the attacker’s domain name. Even side-by-side with a font specifically-chosen to highlight the difference and an arrow pointing at them, they look virtually the same. This is called a “homograph attack,” and there are plenty of other extremely tricky techniques that can fool even attentive users. In some cases, the attacker’s system is simple and just steals the credentials – this is very common in phishing attacks. In more sophisticated cases, the attacker’s system sits invisibly between the user and the system they are accessing and spies on the activity or even adds activity of its own. This can be used to illegally access a system while piggybacking on a legitimate connection, and from an audit perspective makes it look like the actual user was behind any of the attacker’s activity. The encryption worked perfectly and was never broken. The attacker just managed to trick the user into creating a perfectly secure, encrypted connection to the wrong place.

Human Tricks the Human (also called “Social Engineering”) attacks

Most humans want to be helpful, and most humans are very trusting. Good for humans! Being helpful and trusting makes society work in a smooth and convenient fashion. It also often make things smooth and convenient for attackers. There are a million ways to trick a person into giving up access to their system – pretending to be a support or customer service technician, dropping a USB stick loaded with spyware that a user will helpfully plug into their system for you, or sometimes just straight up bribery works. In real-world tests, a large percentage of users would sell their username and password for accessing their employer’s system to a random person on the street for $20.

Steal the Password Directly

This is where things get interesting, because an attacker can steal the password from either the user side, the system side, or the other system side. On the user side this is straightforward: user store their passwords

• On physical things like post-it notes. If you must do this, the best place to store this physical thing is in your wallet under (not stuck to!) your driver’s license. This is not a perfect or even a great solution, but it’s often the best compromise because most people are good at keeping track of and protecting their driver’s license.
• In password lists kept in word processor or spreadsheet files stored on their computer (terrible enough), in their email system (heaven help us), or in the cloud (don’t get me started).
• In password management systems (best).

In most cases, stealing the password from the user involves breaking into their computer, mobile device, or cloud system and getting access to their list or password management system. Some password management systems have mitigations against this, and these should be used when available.

The system side is a much more valuable target, because this is where all of the passwords live. There are lots of attacks here. Some involve intercepting usernames and passwords as they are entered. This is a very common method used with web sites. Others involve attacking the password lists.

Originally, systems stored usernames and passwords in plain-text lists (whether in a file or a database system doesn’t really matter):

0

Admin

IAmSuperman

1

Alice

MyCatIsMittens123

2

Bob

FerarrisAreCool!!

3

Christy

!P1ckGr34tP4$$w0rdZ&

The problem with this system is that if an attacker got access to the server, they got instant access to everybody’s username and password. We’re going to go into what will seem like a silly amount of information about how this problem was solved, because it’s also going to help explain how One Time Password systems work later on.

The next step in protecting passwords on the server was encrypting them with a key. This was stupid and didn’t last long, because encryption only protects things when you can keep the key secret and the key also had to be stored on the server. It’s like having a super-unbreakable vault and leaving the combination written on a post-it note stuck to the door. We’re just going to skip past this embarrassing moment in computer science history (even though today most public cloud systems boast about encrypting the data they store on your behalf with more or less the exact same caveat because checklists).

Encrypting passwords was terrible, but there was a similar and far more clever approach: hashing passwords.

Geek Concept 3: Hashes

A hashing function is a process that takes an input (in this discussion we’ll be taking about using hashing functions with passwords and other shared secrets) and produces a fixed-sized output. What’s special about hashing is that – in theory – you can’t use the output to guess the input without just guessing every possible combination. In practice there are lots of caveats, but we can ignore them here. Hashing is used to artificially increase the amount of entropy of a shared secret. If we have an eight-character password using only lower-case letters, there are in theory 208,827,064,576 (approx. 2.0×10¹²) possible combinations, assuming they were chosen at random by a computer. This sounds like a lot, but a computer can make 208,827,064,576 guesses in mere seconds. If we take even a terrible password like “password” and run it through the SHA-1 hashing function, we get:

c8fed00eb2e87f1cee8e90ebbe870c190ac3848c

To guess either the original password or one that produces the same hash (called a “hash collision”) involves testing up to 9,223,372,036,854,775,808 (approx. 9.2×10¹⁹) possible combinations, about 4.5 million times more work, and a much more interesting challenge for a computer. In theory. This is because there are lots of ways to cheat when attacking hashing functions in situations where we know that there isn’t really that much entropy in what was fed into them.

With hashing, the system could store the hashes of everybody’s passwords. They couldn’t be decrypted, because hashing is a one-way function. When a user logged in, the system would compute the hash of their password and check it against the hash in the user list. Things then looked like this (yes, these are the actual SHA-1 hashes):

0

Admin

c348678ccf22a20f42cc1878253a1d6e722d0f4f

1

Alice

b0cd6862ab1d7d1bfcf19530db59751182944fef

2

Bob

fbd98725441da424544b581224882d7b1689a5b0

3

Christy

a37e9537f14a17cd4ea892c9bb65d77589260a5e

Perfect, right? Wrong. Because, remember, for this discussion we are the attackers and we are sneaky and we cheat. Why bother searching through a stupid number of guesses when we remember that people are still terrible at picking passwords? Enter a fun little intrusion tool called “John the Ripper,” decades old and still used to this day by cyber-criminals everywhere. John the Ripper takes dictionaries of words (often sorted by usage probability, and available in every language there is), creates permutations of these words – phrases, typos, letter-number-symbol substitutions (where people change the letter “O” to the number “0” or the letter “S” to a dollar sign “$” or whatever), added numbers and punctuation, etc. It then creates hashes of these potential combinations and tests them against the system’s user list. John the Ripper knows language, it knows user behavior (all of your cute little password disguise tricks), it knows statistics, and it will guess passwords accordingly. And it is very, very good at this. It will break many hashes in mere minutes, most within hours or days, and nearly all within weeks or months.

And even this is not sneaky enough. Who wants to wait months or even days? In this fast-paced world, ain’t nobody got time for that. So us attackers took John the Ripper and made it even better: we created what are called “Rainbow Tables:” taking every guess John the Ripper makes and adding them to massive databases of hashes that can be easily searched. Billions and trillions of password guesses reduced to a tiny fraction of a second. This pretty much broke hashing completely. For a little while.

Hashing struck back with a very simple change: a pinch of salt. A “salt” is just a few random bytes of information added to the beginning of a password before hashing it. Salting hashes doesn’t make them more difficult for John the Ripper to attack directly – good old John understands how to process salts – but it effectively made the rainbow tables useless, because every password now had millions or billions of possible salted variations.

0

Admin

S.s82t

f19fe1756f8a6947d4889137e0976b7cc558d3b2

1

Alice

^@sd45

cbf4b7591ae825d9dc7ffa5cbff8cce5fb3964f2

2

Bob

Sdg3#

86e66149c6858e31b618286e2cf7444bdeb6512d

3

Christy

gNs34

71970621108cc56347a1c9dd75ea7488113dbdc7

This is where we are today. Hashes are bigger – SHA1 is considered too small to protect passwords and has been replaced by SHA256 and other newer, variants, and everybody (we hope) salts their hashes. John the Ripper can still break bad passwords, but long, random passwords simply take too long to search for even with the ability of attackers to rent massive clusters of specialized machines in the cloud for their searches.

Oh, except for the one other odd thing: attacking and getting the password from the other system. This often works because people can’t remember lots of passwords and instead of using a password manager they just use the same password over and over and over again. So if we as attackers can’t get the password from their impenetrable investment account system… what about getting the same password they re-used on the gardening blog site that hasn’t seen a security update in three years and was leaky as a sieve back then? Easy.

What the heck were we talking about again?

Oh, yeah, One-Time Passwords (OTPs)

Having very briefly (2800 words) gone through the history of passwords, we now add the One-Time Passwords. You can’t steal or guess a password that changes every 30 seconds. Everything is perfect again, right?

Wrong. Because, remember, for this discussion we are the attackers and we are sneaky and we cheat. And also… well, maybe One-Time Passwords aren’t really what they claim to be.

Let’s go through the list of attacks again:

• Guessing or Brute-Forcing the Password at Login. It was already dead and hasn’t come back to life.
• MITM (Machine-In-The-Middle) and other eavesdropping / system impersonation attacks. Just stealing the username and password no longer works, but creating a “secure” connection to an attacker’s system disguised as the real system still works perfectly well. Things are a little better here.
• Human Tricks the Human (also called “Social Engineering”) attacks. People who will give up their passwords will give up their One-Time-Passwords just as easily. An attack can’t be as easily sustained, but most attacks are just one-time anyway. Things are a little better here.

And now we’re going to slow down again at “Steal the Password,” because here a lot of things actually get a lot worse. Remember when we said that One-Time Passwords aren’t really what they claim to be? It was only a few paragraphs ago. How on Earth does your computer or mobile device know how to generate a code that matches the code that the system you are connecting to knows? Unicorns? Witchcraft? Ummmmm…. No.

When you scan this magic 2D barcode with your authenticator app, what is happening? Your device decodes it into something like this:

otpauth://totp/Google%3Ayourgmailaccountname%40gmail.com?secret=beyt3aa74kp7djsinneiipidy4ulx227&issuer=Google

Roughly translated into a more human-readable format:

otpauth://totp

Google:yourgmailaccountname@gmail.com

beyt3aa74kp7djsinneiipidy4ulx227

Google

What, wait, huh? This looks like a username and password. Just another shared secret.

And that’s what a One-Time Password really is. Just another shared secret.

All an authenticator app does is take that shared secret, hash it using the current date and time as a salt – the constantly changing salt is what creates a different code each time, creates a very large number, and just chops off the last six digits of the number for your magic and mysterious “One-Time” Password.

So if an attacker can get access to the computer or mobile device that holds your authenticator app (or a backup of the data on your computer or device), all they have to do is extract that secret and they can create the exact same One-Time Passwords on whatever device they want, forever (or until you create a new One-Time Password relationship).

This could be considered a little bit better than a regular password, because if you write it down or deliberately share it then it can’t be re-used. But it’s also worse because almost everybody believes that these work using unicorns or witchcraft. They don’t realize that it’s just another shared secret that can be stolen from their device.

But what about the system side of things? Now it gets ugly. Because the salt (based on the date and time) is constantly changing, the system cannot store the shared secret as a hash. The shared secret for authenticator apps must always be stored on the authenticating system in plain text. No exceptions, no magic workarounds.

The official Internet Standard (RFC6238) entitled “TOTP: Time-Based One-Time Password Algorithm” states in section 5.1, “Security Considerations, General:”

We also RECOMMEND storing the keys securely in the validation system, and, more specifically, encrypting them using tamper-resistant hardware encryption and exposing them only when required…

We leave to your imagination how many organizations actually use these extremely expensive, temperamental, and specialized tamper-resistant hardware encryption systems. By “temperamental,” we mean that once set up their configurations can’t be changed without compromising device security or deleting all of the data inside of them. This means either “no mistakes, once you’re set up that’s it” administration or “there’s still a back door” administration. The biggest players can and do use machines like this. Apple has been known for being exceptionally-clever in how they are used, and once set up taking all of the administration key cards and putting these cards through what Apple calls a “physical one-way hash function” (they run them through a blender). But the smaller players? Not as often.

At the end of the day, from an attacker’s perspective the list of options for compromising a user’s security using one-time passwords is more or less identical to the list of options for a user with solid password management skills. They add very little security, and quite a bit of inconvenience. This also ignores password / One-Time Password access recovery mechanisms, which often rely on less-secure channels like email. So far we have not come across any service provider that brings up the limitations or weaknesses of One-Time Passwords, and our experience has been that they create a vastly overblown sense of security and invulnerability with end-users. Here’s a quick summary of the methods listed and how One-Time Passwords fare against bad password management and good password management:

Why On Earth Does Anybody Actually Do This?

So why do public cloud services still insist on using One-Time Passwords? Simple: they’re cheap, and require minimal interaction with their customers. They don’t add much real security, but they let their customers have the false impression that they’re invulnerable even though they’re a ridiculous hassle to use. They add little value and externalize the real costs. There are other, better forms of multi-factor authentication. but they require actual customer relationships and personalized customer service. BrilliantRoot helps its customers secure their information with our superior BrilliantRoot Three-Factor Authentication that is far more secure while being practically invisible to the end-users. Let us know when your organization is ready for BrilliantRoot security.

And no, we don’t mind poking a little fun at ourselves for this.