I think… I think I’ve just found the INFOSEC equivalent of a Poe. That is, one of those things where you can’t tell if it’s satire or sincere. It’s this article, from someone who works at a company called “Sakurity”, on why you don’t need multifactor authentication [page since removed].

First of all, not everything in it is wrong: the whole thing about multifactor being annoying and inconvenient and not a blocker against malware-based attacks? 100% true. As someone who has multifactor on pretty much everything, let me assure you: it is a monster fucking pain in the ass. And no, it does not protect against the things it isn’t designed to protect against, which is to say, anyone who has access to your authenticated session or OTP itself,1 no matter the mechanism by which that is achieved.

INFOSEC nitpicking time: security controls do not exist in a vacuum. You do not apply a control to a thing and watch its Security rise by five points, or ten, or twenty. Controls are not base armor class. Instead, controls are like elemental resistances; a +5 protection against fire is not gonna do squat when someone blasts you with lightning. We need to understand this analogy to understand not just good security, but also bad security.

In INFOSEC talk, our “elemental resistances” are called vulnerabilities, while dungeons bosses are called threats. A threat exploits a vulnerability against your system in the same way the Withered Sorcerer casts chain lightning at your party in DnD. Easy, right?2

Enter security controls.

In INFOSEC: The Roleplaying Game, there is no such thing as a base armor class, i.e. a control that gives blanket protection against everything. Instead, each control is armor against only a handful of specific types of vulnerabilities (damage types). So while multifactor authentication might give you +10 against brute-force login and side channel credential acquisition, it does shit-all against, say, session hijacking or physical device theft. This is not a failing on the part of your multifactor authentication item, it’s just the way the rules of the game work. In order to powergame correctly in I:tRG, you need to know which controls mitigate which vulnerabilities.

From the linked article:

TOTP authenticators generate just 6 digits – OTP bruteforce works like a charm and takes less than 3 days. On top of that 30 seconds limit is quite silly – it doesn’t make bruteforce any harder – just do the math and you will see.

(TOTP is time-based one-time password, which is the “get your authenticator code and enter it in within the next minute to login!” style of multifactor. It’s what most online account multifactor is, since it’s easy to implement.)3

I’m no mathematician, so I can’t validate whether the formula used at the link is correct or not; I’m going to assume it is. It doesn’t change my answer either way, which is:

So what?

TOTP is a kind of password, it’s just a kind of password that, a) changes much more frequently than you change your human passwords, and b) you have to have some kind of physical device to know. And the thing about passwords? All of them are brute forceable. All of them.4 This is just as true as it is for your shitty single dictionary word login to Facebook as it is for a 15360-bit encryption key. If you had an infinite number of monkeys guessing an infinite number of passwords for an infinite amount of time, you would eventually crack that 15360-bit key. I can’t actually give you a guess of how long it would take, because the length of time is so long I can’t find a brute force calculator that can deal with the numbers. But, in theory, it’s possible and–as with all of these things–it becomes more possible every year as computing power speeds up. Incidentally, your Facebook password could be done in a day.

Anyway. The point is that passwords aren’t supposed to be “unguessable”, they’re just supposed to be impractically unguessable. That is, hard enough that whomever’s trying to crack them will either give up or die before they’re broken. Remember, we’re only dealing with probabilities here. It’s entirely possible an attacker could get your password right on the first try, even if it’s 15360 bits long. It’s incredibly unlikely, but it’s possible, particularly if key is made up of 15360 bits of 0s. Remember how we said your dictionary word Facebook password could be cracked within a day? That’s if we’re just throwing random combinations of letters at it. What we’re actually going to be doing is throwing a dictionary at it, so just running through every word in the English language and seeing which one sticks. Then we’re going to start running through other languages, permutations of those languages (which is why replacing the ls with 1s in your password doesn’t make them more “secure”), and also all the passwords that have ever been leaked as part of a hack. Basically, this means we’re going to be able to find your password in seconds or minutes, not hours or days. So, yanno. Don’t use shitty passwords, protip.

Anyway. What was I talking about? Oh, right; brute-forcing TOTPs.

So, yeah. We can theoretically brute force an OTP. But if we’re going to use that “logic” to say OTPs are useless, you might as well use the logic that all passwords are useless, including the over-complex ones you store in your password manager which, incidentally, is also susceptible to malware and session hijacking.

From the original article:

A 2FA app is essentially a password manager. A 2FA seed/code is essentially a password. “Time-based” thing does not add any security, and 6-digits thing makes security even worse. 2FA is obscure, inconvenient, hard to backup, bruteforce-able password manager.

You don’t need 2FA, all you need is a unique complex password and a password manager.

There’s no plausible attack scenario where simple password + 2FA is better than good complex password alone. Why?


First off, this is not entirely wrong; a complex enough password, unique to a single system, will take just as long or even longer to brute force than a simpler password plus an OTP. Yes, this is mathematically true. Congratulations. It’s also completely irrelevant, because it assumes that, a) user behaviour is always secure, and b) that everyone is brute forcing all these things offline.

More neepery: there are two ways of brute forcing passwords, online and offline. Online is someone (usually a computer someone, because they’re faster and more patient) sitting there typing things into a login form over and over and pressing “submit”. But there’s also offline password cracking. Offline password cracking assumes two things. The first of which is that, a) you have access to a system’s passwords, and b) that those passwords are encrypted, and it’s this encryption you need to break. When people talk about the mathematics of passwords cracking, they are almost always talking about the latter scenario, basically because you can try more passwords per second than you can in an online scenario. How do you offline crack? You try and grab an encrypted password dump from somewhere, usually a less-secured system like a shitty forum site, take them back to your basement hacker lair, and run them through your multi-GPU password cracking cluster ((Graphics cards are way better at password cracking than your computer’s main CPU, so if you ever see someone with like a jillion huge GPUs in their case, they either do a mean multiboxed World of Warcraft, or they’re trying to crack password hashes.)) at your leisure.

That’s offline brute forcing.

Online brute forcing is different, and the #1 Main Reason why password+OTP is different to password alone; you cannot offline crack an OTP.5 To brute force it, you have to be making login attempts against the server. Hopefully said server, assuming it’s the kind of thing that’s going to be implementing an OTP, is also the kind of thing that’s going to be noticing multiple failed login attempts and, yanno. Doing something about it.

Doing what? The Sakurity article even mentions what, which is to say account lockouts, IP banning, and CAPTCHA tests.

This is where we get back to our INFOSEC: The Roleplaying Game analogy above. Because multifactor is not +10 to base security class. It’s +10 to specific types of attacks. But it in itself is susceptible to different types of attacks because, again, that’s how this game is played. So you implement multifactor, awesome. Then you implement other controls around it to deal with the way people exploit multifactor. Multifactor helps the problem of users not having unique passwords and not having sufficiently complex passwords, which means their passwords can be stolen from less-secure sites and used against your more-secure site. The controls around multifactor help the problem of people trying to circumvent multifactor.

See? Different problems, different solutions.

Which is, wow. Basically 1,500 words to say that if you could, a) 100% rely on all your users to only ever use complex passwords for your site that they use nowhere else, b) 100% guarantee you’ll never lose your password hashes to an offline attacker, and c) already implement anti-brute-force measures on your login forms, then yes. Yes, TOTPs would be useless. And if you can do a, b, and c I want a ticket to whatever magical security fantasyland you live in. Because seriously.

Also, the security advice that you give to end users protecting their own data, and the security advice you give to organisations protecting their users’ data is not the same. The advice in the Sakurity article is case-in-point, in that’s it’s actually pretty accurate if you’re talking about one single person attempting to protect one single account. Yes, if You, the Individual, use highly complex passwords that are unique to each site, you probably don’t “need” multifactor. Probably. But the Sakurity article seems to be really confused as to whether it’s targeting users or targeting organisations, given its initiating context around adding multifactor support to Bitbucket.

This is why security is hard. The reality is that “advice”/”opinion” like that given in the Sakurity article is a dime a dozen in the INFOSEC business, because unfortunately INFOSEC is crawling with cryptography and computer engineer nerds who’ve apparently never spoken to another human being and have never heard of the hammer attack. Or, more accurately, people who are only good at looking at one stat on their character sheet–in this case, the relative entropy of various password solutions–rather than watching the movements of the entire raid.

This, in other words, is why computers suck. Because people who charge $3,000 a day for security consulting don’t understand that their industry is driven by user behaviour, not mathematical formulas. Guh.

  1. This sounds like it should be frustratingly self-evident–OTP does not protect against anyone who knows your OTP–but we’re dealing with INFOSEC here, which is not a field known for its common sense. More on which later… []
  2. Yah, I know. I’m simplifying. Indulge me a bit here, okay? We can have neepery over the semantics of threats and attacks and exploits and whatever later. []
  3. The other most common implementation, incidentally, is two-step verification. 2SV is that “okay we just SMS’d you a code, enter it here” thing. The difference between it and authenticator-based multifactor is that in 2SV the “second password” comes from the server itself–and is thus theoretically possible to intercept–while in 2FA the second password comes from a device you possess which is physically synced with the server via secret sauce. A lot of multifactor-enabled accounts, like Google, will use a combination of both; often relying on 2SV if you forget/lose/desync your 2FA token. []
  4. Okay. Most of them. All of them that you’re ever likely to encounter, let’s put it that way. []
  5. … Kinda. For the purposes of this argument, you can’t. You can do other things, but not this. []