Getting off on the right foot with your MSSP
Our newest writer, Paul Ducklin, tells it as he sees it – that we’re all served better when we treat cybersecurity as a value to be maximised, not as a cost to be minimised.
MFA – The what, the how, and the why
Multi-factor authentication – what it can and can’t do for you.
If the media player above doesn’t work in your browser,
try clicking here to listen in a new browser tab.
Find TALES FROM THE SOC on Apple Podcasts, Audible, Spotify, Podbean, or via our RSS feed if you use your own audio app. Or download this episode as an MP3 file and listen offline in any audio or video player.
[FX: PHONE DIALS]
[FX: PHONE RINGS, PICKS UP]
ETHEREAL VOICE. Hello, caller.
Get ready for TALES FROM THE SOC.
[FX: DRAMATIC CHORD]
DUCK. Welcome back, everybody, to TALES FROM THE SOC.
I am Paul Ducklin, joined as usual by David Emerson, CTO and Head of Operations at SolCyber.
Hello, David.
DAVID. Hey, there.
DUCK. David․․․ MFA: The what, the how, and the why.
DAVID. MFA!
DUCK. Multi-factor authentication.
I like to call it 2FA, where you write 2 as a digit, because normally there are two factors rather than three or four.
The idea of multi-factor means it’s not just a password any more.
I’m not going to talk about general identity management things, like Microsoft Entra ID, or Octa SSO, or Linux’s Plugable Authentication Modules (PAM), which many people will have heard of․․․ and of course other identity management tools are available.
So, do you want to dive in and give us a bit of a background, a bit of a history, and let’s say the three main types of MFA that people will have probably experienced in their life?
DAVID. Sure.
The idea of multiple factors is something that’s been around for a long time, at least since the early 1980s.
There are a number of ways to look at it academically.
NIST, the National Institute of Standards and Technology, have defined factors as, “Something that you have, something that you know, or something that you are.”
DUCK. So by “something that you are,” that’s more the biometric side?
DAVID. Yes, your eyes, your hand, something that is you, is a characteristic of you.
And then “something you have” might be a token, some kind of an artifact that is not you, and is not knowledge.
So, when the NIST establishes these as factors, the reason they do that is to then contrast multi-factor from single-factor.
For example, two things that you know, two passwords, let’s say, is not multi-factor authentication.
DUCK. No, it’s just a much longer password, isn’t it? [LAUGHS]
DAVID. Right.
That’s a really important way to categorize this multi-factor authentication concept, because it is not multi-factor just because you have two different things.
It’s multi-factor because you have two different factors, two distinct factors, of things that you know, things that you have, or things that you are.
DUCK. And so a username-plus-password, that’s one factor.
Usernames are normally email addresses now, so you have to assume they’re public – they’re not meant to be secret.
But even if you did go, “Oh, I’ll have a secret username,” that plus your password is one factor that just has two fields to type in.
DAVID. So, that’s one of the innovations that happened in 1984, actually.
It wasn’t that nobody had done fingerprint authentication prior to that – they actually had.
It wasn’t that people hadn’t done iris or retina scans.
It was that there had not been a pervasive combination of multi-factors until there was a patent, essentially, in 1984, filed for Security Dynamics, which eventually became RSA.
DUCK. Those little tokens that have digits that change every so often?
DAVID. Yes, it’s a cryptographic, time-based algorithm that just generates a number, and that number changes every 30 seconds, and it is deterministic.
And so if you know the time, and you know the cryptographic seed, two parties can derive what number is showing on that device at the same time.
The point is not so much perfection.
The point is, at this moment, did you have the correct code?
Because it’s only good for this moment.
As with almost all the methods that we’re going to talk about today, it doesn’t necessarily rest on perfection.
It rests on being substantially better than just having a password.
Since the 1980s, our concept of multi-factor has evolved a little bit, to be more nuanced, and this is more of an evolution with contemporary threats.
In the 1980s, the concern was, “What else can we do to harden this password?”
Nowadays, we have concerns like phishing resistance, or replay resistance.
DUCK. The “how MFA works” that these days most people will have experienced, terminologies that people probably have heard of․․․
There’s the one you mentioned, the TOTP, time-based one-time password.
You might have an app on your phone that comes up with six digits that change.
The other sort is where you get the code via SMS.
And then the new thing that everybody’s talking about are things called passkeys, which provide, if you like, more cryptographic complexity.
So, do you want to say something about the strengths and weaknesses of each of those three main approaches?
DAVID. Yes.
They’re not all equal, but they are all significantly better than a single factor.
DUCK. Yes.
DAVID. You mentioned a spectrum of things there.
I would say the weakest of the ones that you mentioned is SMS.
DUCK. Right.
DAVID. For a couple of reasons.
Probably the biggest single reason is that the channel of SMS itself, the mobile phone via the SIM, is considered exploited at this point.
It’s vulnerable to attack.
You can swap the SIM out, and receive someone else’s text messages.
DUCK. If someone has it in for you, and they can go into a mobile phone shop and bribe or persuade the young, money-hungry salesperson in there (I hope I didn’t say that aloud) to reissue the number for the new phone they’re about to buy with a stolen credit card, then your phone goes dead.
So, you can’t even phone up and say, “Hey, my phone’s gone dead.”
And they get your magic codes until you can do something about it.
DAVID. Yes.
I don’t necessarily consider that a massive actual threat, in the sense that it’s unlikely someone would go through all that trouble to attack just you.
But there is a second reason that this sits at the lowest end of the hierarchy of second-factor tokens, and that is the cryptographic linkage to the site that you’re entering it into, or to the service you’re entering it into.
There is none!
Meaning, if you give away that code, or if you use that code yourself improperly, there is no check against, “Are you entering this into your bank, or are you entering this code into something else that has requested a code?”
DUCK. Like a phishing site? [LAUGHS]
DAVID. Yes, like a phishing site.
DUCK. My understanding is that NIST’s particular objection to SMS-based 2FA is not that having your SIM swapped out from under you is terribly likely (but it is more common than you might think).
NIST’s objection was that if they’re giving this recommendation, particularly to government employees, then because reissuing the SIM or eSIM is entirely down to potentially millions of salespeople or managers in mobile phone shops, there’s no way that the company that’s trying to protect its own assets can actually take control of that.
In other words, it is an unknown, uncontrollable factor.
DAVID. Exactly.
So, in respect of SMS, NIST considers it restricted, not banned.
DUCK. Oh, really?
DAVID. Meaning they acknowledge that it’s better than nothing, but they don’t consider it particularly great.
A restricted category factor, according to NIST, is something that you can use having accepted the risks, or having published the risks to the end user, and that you can’t use for an extremely sensitive system.
Moving up one tier in this hierarchy to what you mentioned – these token-based TOTP systems.
Those TOTP systems fail one of the two tests that I just laid out – a TOTP system is unlinked, cryptographically unlinked, to the target system.
DUCK. Oh, so in that sense it’s very much like the SMS system.
There are six digits, and you type them in, but the server doesn’t know where you’re typing them in from.
It doesn’t forge an obvious link between, say, your browser (and not anyone else’s), and a specific connection to a specific server.
DAVID. Right.
It is still a manual entry technology, essentially.
You’ve acquired this code by means of cryptographic algorithm and time, and now you’re going to enter this code, and that’s a manual input.
And so, a manual input technology is always going to have this vulnerability, this essentially analog loop.
DUCK. Basically, a man-in-the-middle, or a manipulator-in-the-middle, attack?
If you’re a LinkedIn user and you’re not yet following @SolCyber, do so now to keep up with the delightfully useful Amos The Armadillo’s Almanac series. SolCyber’s lovable mascot Amos provides regular, amusing, and easy-to-digest explanations of cybersecurity jargon, from MiTMs and IDSes to DDoSes and RCEs.
Even if you know all the jargon yourself, Amos will help you explain it to colleagues, friends, and family in an unpretentious, unintimidating way.
DAVID. Yes.
DUCK. If they get hold of it before you use it, they can use it first, and you can’t stop them easily.
DAVID. Right.
DUCK. There is also a risk that I think people sometimes either forget or underestimate with TOTP, whether the Secure ID token sort or the Authenticator app.
It’s based on a shared secret, isn’t it?
If you keep the seed secure, you can never be sure that the other end hasn’t had a blunder where their server got compromised, because they need exactly the same seed.
You have the secret, but the other end needs the same secret, like a Wi-Fi password, which isn’t quite as good as the cryptographic separation that you get with a passkey.
DAVID. Correct.
That is the vulnerability, that is one of the ways in which I’m referring to the cryptographic robustness of the solution.
DUCK. Yes.
DAVID. When you upgrade to the next tier that you mentioned, passkeys, whether physical or software, you’re now in a realm of validation, cryptographically, as well as a realm of the inability to easily spoof or manually enter this thing.
A Yubikey does depend on you touching it, but you touching it does not indicate that it should release its code to any old website.
DUCK. And unless you have one with a fingerprint reader, touching it is not the factor.
The factor is the cryptographic stuff that it does.
DAVID. In other words, if you present your Yubikey to a phishing website, that is not going to be a disclosure.
If you present your Yubikey to a valid website, the keys will match.
That will essentially provide a second factor.
And so that really is robust.
At that point, you’ve reached what NIST considers the maximum practical security, which is a cryptographically validated key.
DUCK. So, instead of using a seed, which both sides have to have, and instead of just being six digits, the private key is inside the passkey or the secure app on your phone.
And the other end of the equation doesn’t have a seed.
It has the corresponding public key, which is no use on its own.
DAVID. And that’s what all of this is about.
All of this is not about perfection.
It’s about raising the cost of breach high enough that it is not done casually.
DUCK. Given that you can now get the equivalent of a passkey that you run as an app on your phone․․․ because your phone also has secure storage.
Apple call it, I think, the security enclave; in Google, you’ll hear the word Titan key.
It’s like a special sub-chip on your phone that’s meant to behave a bit like a Yubikey.
What’s the objection that people have to getting them?
Why do so many people seem to dig their heels in, do you think, about adopting MFA given that NIST says, in an imperfect world, of the three sorts of MFA, this is by far the best?
DAVID. So, Google actually did some research on this.
Google found that the objections, in order, were, one, lockout.
And this is not the objection being hypothetically I could be locked out, but the objection being, “I am locked out, so how do I deal with this?”
That is the number one objection that users actually encounter, and feel encumbers their experience so that they are locked out.
The number two objection is – and it’s weird to me that they’re in this order, but the number two objection is availability.
Meaning, they attempted to log in, they were challenged for their second factor, and they realized, “Oh crap, my Yubikey is at home, but I’m at the office.”
So I think that’s telling.
It’s very practical, right?
These are the things that actually would happen to end users – they don’t have the thing that they’re supposed to have.
Or they’re locked out because they’ve completely lost it, and they have no idea how to recover it.
Those are the objections.
So it isn’t money, it’s lockout and availability.
DUCK. I don’t want to sound judgmental, David, but it sounds like a pretty thin objection.
DAVID. Well, we would․․․ we would think so, yes! [LAUGHS]
DUCK. If you can manage to keep your laptop with you, you can probably keep your Yubikey with you.
And I haven’t met somebody who is more likely to lose their phone than their laptop these days, given how welded people are to their phones.
So it sounds like, maybe, that’s a confected excuse?
DAVID. I’m unable to account for the behaviors of users.
I actually was at the Apple store yesterday to buy a laptop.
DUCK. [WIND-UP VOICE] Isn’t RAM cheap these days, David?
DAVID. [STRAINED] Oh, it’s not cheap at all. [LAUGHS]
I spent a fortune on that thing!
DUCK. [CROCODILE TEARS] Oh, dear.
DAVID. [BROKEN VOICE] It was terrible.
But just in the time I was there, the funny thing was the things I got to overhear – the problems that people go to the Apple store for.
And all I can say is, number one, I cannot work at the Apple store – that’s not going to work.
And number two, we are not at the point of worrying about people’s Yubikeys and their ability to use them.
The problems that users have are so fundamental, sometimes, that, yes, I can totally understand how multi-factor can be a barrier.
That is not to say don’t do multi-factor.
Absolutely everybody needs to do multi-factor, but it’s going to be painful.
Some people just aren’t going to get it.
DUCK. We’ve done the “What is is.”
We’ve given the “How it works,” the three main ways.
And, with passkeys, whether they’re physical keys (they’re the small things that you carry with you), or an app that you have on your phone, that if you leave your phone or your key at home․․․ bad luck, you cannot log in.
That’s by design.
So don’t leave your key at home.
You talked about phishing resistance.
But at this point, I’d like to talk about, “What are the parts of login sniffing, or data breaches, or data theft, that multi-factor authentication on its own does not solve?”
Such as authentication token theft.
Why can stealing something out of your browser, after you’ve logged in, sidestep a passkey that has this cryptographic funkiness and hardware security built in?
DAVID. In a very technical sense, there are post-authentication token compromises of various kinds.
Meaning that you’ve created this session, you’ve authenticated to a site, and now you have some kind of bearer token or some kind of tunnel, or whatever․․․ it depends on the service.
DUCK. Bearer token․․․ like a bearer bond, or like a banknote – it means whoever’s got it can pretend to be you.
And that’s by design, because it only lasts a little while, and they made you jump through hoops before you got the bearer token?
DAVID. Yes, exactly.
DUCK. So, it’s a bit like you show up at a building and they say, “Right, we need to see your passport; we want to take a photo of you.”
And then they give you like a swipe card and it says, “For the whole of this day, this will let you get into all the visitor areas and the toilets in the whole building.”
DAVID. Yes, precisely.
DUCK. No one asks you for your passport again.
DAVID. That re-challenge is something that you have to think about, depending on how sensitive the system is, of course.
DUCK. Yes.
DAVID. But there is an interval in which you want to re-challenge that credential.
That is not something that would be convenient, let’s say, on a one minute basis.
It would be almost unusable to re-challenge you every minute.
If you’re designing a secure service, though, it is not unreasonable to say, “OK, I’m going to let people log in; we’re going to give them a bearer token.”
Now they’ve got access to all the basic systems.
But if they want to make administrative-level changes or sensitive changes, maybe we ask them to re-present their YubiKey?
That’s not unreasonable.
DUCK. So that’s why if you’re using outlook.com, for example, for your home email․․․
When you go into your profile, and you want to change things like authentication method, you actually do have to basically log in afresh all over again?
DAVID. Yes.
DUCK. That’s to prevent somebody changing the really sensitive things based on this bearer token?
DAVID. Yes.
So this is one of the forms of hijacking.
The consideration you need to make is that MFA is not a silver bullet.
This is something that is a system design issue.
Another issue is fatigue.
We are all constantly pushing tokens around at this point.
I have 500 passwords in my password vault, and I have probably 110 TOTP tokens.
And who knows how many SMS codes I respond to a day?
So, fatigue is real.
Fatigue is absolutely a real thing.
And that is also another form of attack.
Uber, for example – I know two people that have fallen for an Uber fatigue attack lately.
That’s because you have this Uber wallet that the attackers want access to.
Your Uber wallet can contain, I don’t know, however many credit cards you’ve put in there.
So, if a delivery driver happens upon your telephone number, let’s say on the pizza that you ordered, they can text that number, or they can call that number, and say, “Hey, I was your Uber driver. I need the code that just came to your phone.”
Well, that code that just came to your phone – you might think it’s an innocent Uber code to validate delivery, which they also have.
DUCK. [LAUGHS]
DAVID. But it would be fatigue for you to read that off to them, which then subsequently allows them access to your Uber account.
You could potentially then have a situation where they can use your Uber wallet, having compromised it by using a fatigue attack, by asking you your code.
DUCK. Even if you’ve got a good idea about security and you want to take it seriously, you might just take the path of least resistance and go, [OK].
Or you might get so annoyed with the prompts, and you press, “[No], [No], [No], I’m not doing this, [No], this is fake – GO AWAY!”
And you get so apoplectic with rage that you press the wrong button one time.
DAVID. Yes, there’s a lot of sources for fatigue.
I think this is more likely to work on a service use a lot.
DUCK. Yes.
DAVID. And so, fatigue is real, right?
Fatigue is probably going to be related to services use all the time.
But some of those are important, like your email.
That’s really important – you use it all the time; you’re probably accustomed to getting prompted for it.
One more prompt easily could fly under the radar.
And then finally, we have this impersonation attack, the process-driven attack.
It cuts across all forms of TOTP to some extent.
And that would be like what happened to MGM.
So, MGM fell prey to Scattered Spider, which was a cyber-gang.
Not because Scattered Spider was sophisticated, but because they picked up the phone, and they called the MGM helpdesk and they convinced MGM that they were a user who had forgotten their password, and forgotten their token.
They got a new token generated, and a new password generated, and then used that to log in.
DUCK. Here, they just persuaded the helpdesk that they were person X, and they had a brand-new, genuine, 2FA protected account in somebody else’s name.
DAVID. Exactly.
And it perfectly illustrates the practical attack here.
Because a SIM-swap, which by the way, Scattered Spider probably is fully capable of doing a SIM swap if they want to target a single person, but that isn’t cheap – it’s not easy to do.
What is easy to do is call up the help desk and say, “Hey, I’m Sally. I forgot my password and I forgot my TOTP and I just need you to regenerate them, send it to my personal email. Here it is.”
It’s really cheap = that’s a whole lot cheaper than cloning a SIM.
It’s a whole lot less noticeable.
It’s really, really easy to do.
DUCK. And at the risk of sounding fatuous, David, the best defense for a helpdesk against that sort of attack is, “Don’t do that.”
DAVID. Well, yes, obviously. [LAUGHTER]
You could tell humans all kinds of things and they’ll still do it.
It’s a moth to a flame.
DUCK. So, David, if I can ask you one last question.
What should people who are still pushing back against using MFA, just because they think it’s one extra thing that they just can’t be doing with․․․
How would you convince them that it really is important to do at least the minimum that NIST is suggesting, just to make things harder for the crooks?
DAVID. Well, the “why bother” is obvious – it’s because you have something to protect.
But when it comes to how to deal with a person like that, honestly, you’re speaking to someone who is thoroughly fatigued.
My honest, unvarnished answer is that that person is not welcome in your sensitive systems.
They don’t need to get into the systems that you are attempting to protect if they truly believe that multi-factor authentication is unnecessary.
So, no, I don’t really have an accommodation for them.
They can use it, and they can enjoy the services that you’re offering․․․
․․․or they can not use it, and they can be locked out.
I don’t have another resolution.
DUCK. So if they want to take the risk in their own personal life, you can counsel them not to do that because you feel strongly about it.
But for business purposes, even if they’re the CEO, especially if they’re the CEO, the CFO, or somebody who’s been locked out before and it caused them great angst․․․ too bad!
One rule; everyone has to follow it.
DAVID. [FORCEFULLY] That is my opinion.
I know that there’s probably politics where everyone works, but that is my opinion and I’ve managed to maintain that for a while now.
It is not politically popular.
DUCK. 2FA, it’s not perfect.
You talked about some of the other things you have to watch out for.
But if you don’t do it, it does make things significantly easier for the crooks, even if using 2FA doesn’t lock them out altogether.
DAVID. Yes.
It’s like drunk driving.
Maybe your CEO is really good at drunk driving, too.
It’s possible that they won’t get in an accident this time.
But that isn’t the same thing as it’s a good idea to allow them to do it.
It’s a very similar sort of risk calculation.
You have to decide whether or not this is something you want to expose your system to.
If your system is sufficiently important that it should have second-factor or multi-factor authentication․․․
․․․well, the people that don’t want to participate in that are not permitted in that system.
DUCK. Strong words, David, but I think well-said.
So, a great way to finish.
Thank you so much for your time, and the historical stories going back more than 40 years.
So don’t think that this is something new that you’re being forced to do because “newfangled whatever.”
This technology has been with us for ages, and can be made to work well.
Thanks to everybody who tuned in and listened.
If you want to know more about cryptography, about how all of this stuff works, we have some excellent non-sales-schpiel articles on solcyber.com/blog.
So please visit there.
Please subscribe to the podcast.
If you listen on a podcast feed, why not leave a comment, and why not leave us a review?
Why not tell your friends, your family, your colleagues, and especially your boss about us?
It helps us get the message out that helps everybody do security a little bit better, and thereby push back against the crooks.
And lastly․․․
Until next time, stay secure.
DAVID. “Especially your boss.” [LAUGHS]
I like that line!
DUCK. [LAUGHS] Well, it’s true.
Like you said, “No exceptions.”
[FX: CALL ENDS]
Catch up now, or subscribe to find out about new episodes as soon as they come out. Find us on Apple Podcasts, Audible, Spotify, Podbean, or via our RSS feed if you use your own audio app.
Why not ask how SolCyber can help you do cybersecurity in the most human-friendly way? Don’t get stuck behind an ever-expanding convoy of security tools that leave you at the whim of policies and procedures that are dictated by the tools, even though they don’t suit your IT team, your colleagues, or your customers!
Our newest writer, Paul Ducklin, tells it as he sees it – that we’re all served better when we treat cybersecurity as a value to be maximised, not as a cost to be minimised.
Nightmare Eclipse hates Microsoft, loves dropping 0-days.
AI is woven into to this cyberattack in several fascinating ways.
By subscribing you agree to our Privacy Policy and provide consent to receive updates from our company.
