Multi-factor authentication (MFA) has become so commoditized in the recent years that it’s easy to forget that it’s a service running on servers. And as such, that it can suffer interruptions and hacks. Recognizing this has consequences on how to pick and to use an MFA service.
Wait! MFA is a service
However, it’s not a conventional one. First, because it’s a first layer that a user needs to go through before she can access her applications. If the MFA service is down, users can’t access your applications. Said differently: as a component of your IT architecture, MFA is what we call a SPOF, a single point of failure. Second, because MFA’s only purpose is to provide higher access security to your applications. If MFA is attacked or bypassed, even if it is runs, it becomes pointless.
MFA security = Robustness + Availability
The important characteristics to look for in an MFA service are not just that it “works” or that it’s easy to use. Don’t misunderstand me, these characteristics are important. But the key characteristic is security.
There are several meanings for that word. Let’s speak about robustness when we’re talking about what makes it difficult for MFA to be hacked. And let’s speak about availability when we’re talking about MFA having as little downtime as possible. Robustness and availability are both paramount.
Is AWS availability enough for your MFA?
Let’s take a closer look at availability. Whether you rely on a 3rd-party MFA service such as inWebo, or you want to build your own MFA infrastructure, you have to decide what is an acceptable interruption to your business. Then, you need to source an MFA solution that can deliver this level of availability.
You can buy it or you can build it but, either way, the availability level can’t be higher than that of the infrastructure on which it relies. For instance, MFA solutions built on top of AWS suffer AWS downtimes. I’m taking the AWS example here because it has become very frequent for software vendors – including security vendors – to completely outsource their service infrastructure to AWS. Nowadays, it almost sounds like a no-brainer but, you might want to think about it.
If you need less downtime than what an AWS-based MFA can deliver, what are your options? Actually, there aren’t so many. You need the MFA service to rely on several completely independent infrastructure providers (e.g. different datacenters or cloud providers, different power grids, different Internet peering points, etc.). Yet, to avoid so-called replay attacks, you also need the credentials database to be replicated between the datacenters in real time.
The MFA service provider’s dilemna – Part I
You might think this is overkill. Who does really need that? Our experience at inWebo working with global organizations since 2011 is that high-availability is totally key for them. This is often their number one requirement. Also, if you think about it, there’s no such thing as an MFA service that is too much available – provided of course that the high-availability feature is not overpriced. So why don’t most MFA providers offer it?
At inWebo, we have chosen to design our MFA infrastructure in a way so that it can offer “super-high-availability” – well beyond AWS. And it does. Does everyone need it? Certainly not. Do I think that most large organizations need it? Probably so.
As a provider, our role is to serve a solvent market, not to decide who needs high-availability. However, as the saying goes, who can do more can do less, not the opposite. The only choice that we have made was to be able to serve the entire market. Of course, it would have been less expensive to exclude high-availability savvy organizations from our target customer segments, but making this choice early enough has required much less investment than on second thought.
Is your security infrastructure secure?
The question sounds absurd, but it is not, especially for MFA. Why is that? MFA robustness questions how the credentials are protected and how the MFA service itself can be trusted.
How are users’ credentials protected – In most implementations, MFA is like a safe containing all your jewels – here, your users credentials. If hackers get hold of a user’s credentials – let alone, of all users’ credentials -, they can easily impersonate that user. Does it sound like a security consultant’s prophecy? Just ask RSA, the company that invented MFA (to my knowledge) and still owns a significant market share. In 2011, hackers got hold of the “jewels” – a big part of the users’ credentials database – thanks to a sophisticated attack. In the months following this attack, several of their customers especially in sensitive industries such as Aerospace & Defense were in turn the victims of attacks through user impersonation. No one will argue that RSA isn’t serious about security, so how could it happen and, more importantly, what are your options if you want to make sure that no one can access and mess up with your users’ credentials?
There’s only one answer to that question: make the users’ credentials stored with the MFA service non-sensitive so that if hackers can get hold of them, they won’t be able to start anything with them. Let’s mention that it doesn’t depend on what the ‘safe’ actually is, a database in your infrastructure or with an MFA service provider, or … a blockchain. There are actually 2 approaches to make the credentials non-sensitive: to use asymmetric credentials (this is one of the key ideas developed in the FIDO standards), and to use encryption at rest and in use enforced by hardware security appliances (aka HSM), which is the approach that inWebo has been developing and implementing for MFA since 2011.
How can you trust MFA – MFA’s role is to answer in a trustworthy and reliable manner the following question: is the user really who he / she’s pretending. Can MFA be wrong? I’m not saying that MFA isn’t engineered to correctly answer these questions, but what if MFA is hacked or bypassed? How do you know that your MFA service hasn’t been compromised and that you can still trust what it tells you? How do you know that a hacker isn’t using the trust you put into MFA in order to bypass the challenge that MFA poses to hackers? What are your options if you don’t want to ignore these questions?
You can only be secure thanks to providers that you trust, but how can you trust that they are secure? It’s a hard question. Fortunately, that’s textbook in cryptography. You need the MFA provider to sign its answers to your questions with its private key. This leads to a further problem: how can you make sure that no one else has access to the private key. For that, the signature must be created in a tamper-proofed hardware security appliance (HSM). But, wait. What if the MFA server has been hacked and provides a ‘wrong’ answer for signature? This series of questions leads to a unique answer: the MFA service must run within in a protected environment, such as an HSM.
The MFA service provider’s dilemna – Part II
This raises the same question as for availability: who does really need that? Isn’t that over-engineered? This is a similar question you face when renting a car, should you take all these extra insurance options? Some of us do, “just in case”, some of us don’t. The nature and amount of assets that you’re trying to protect have probably a direct impact on your decision about insurance options. There’s a difference with MFA though. It’s a security service. If you’re taking the MFA option, is there a reason to choose a low-security one that won’t reduce your risks? I have an answer to that, slightly provocative I admit. In many situations – at least before they’re hit by an attack -, organizations implement MFA not to reduce their risks but because they have to check a compliance box (see another post on that topic).
As one of the early SaaS MFA providers, robustness was a particularly critical question for inWebo. Should we invest in making our MFA infrastructure extra robust – beyond making it just work in the first place, and making it highly-available. For the same reason (“who can do more, can do less”), and because we took that decision very early and could therefore avoid the costs and service disruption of a later decision, we chose to build a highly-robust MFA infrastructure. An obvious reason for that decision was that, a young cyber-security startup then, our only possible differentiating factor was the quality of our Product – we couldn’t play with our reputation as an established vendor (but how does reputation correlate with security – that’s a possible topic for a future post), and even less with large marketing budgets.
What MFA is right for you?
In this post, I’ve tried to highlight the fact that the features list and the pricing, though the most visible ones, aren’t the only decision factors to pick an MFA service – and maybe not even the most important ones.