MFA: More Fun in Authentication or Most Faulty Authentication?

After coming across two very different blog posts on MFA in a short period of time and finding them contradictory at first glance, I looked into the subject a bit more.

Daniel Miessler’s blog has an overview of various MFA methods, as an extension of a post on the Consumer Authentication Strength Maturity Model (CASMM).

You can certainly disagree on the details, but I find this approach very helpful. Also, the suggested customization to the particular threat model is something that should not be underestimated.

The use of SMS at level 5 could mean a lowering of the security level if weaker passwords are used for this purpose or if they are used more carelessly. Unfortunately, I have come across this before. That SMS are a bad option was shown often enough at the Chaos Communication Congress. Nevertheless, even banks still offer them to me in various scenarios.

I often vacillate between level 6 (app-based 2FA codes – TOTP, for example, as I understand it) and level 7 (app-based codeless 2FA). Level 7 is usually more convenient, but I feel like I’m more of a Level 6 guy 😉. Especially when more than one device has been activated or they can’t be restricted, I’m skeptical. On the other hand, in these cases, controlling the amount of devices allowed is often easier, or even possible in the first place. That’s only possible with TOTP if the QR codes are protected over their lifetime, but if that’s not the case, other than being notified of a service login, I have no way to tell anymore. Tricky. Most of the time you don’t have an option per service either and then you don’t have to dig into it.

I honestly didn’t have the option to backup TOTP on my radar until the episode two-factor authentication of the INNOQ Security Postcast. Prior to that, when my device broke, I used the various recovery options (one-time codes, second email address, and also SMS) to get my TOTP flying again in Google Authenticator. One service was not trivial to restore at the time: For Bitcoin.de, it was fortunately possible to make the old smartphone functional again for a short time (with the Samsung Galaxy Note 4, it really helps to cool the device in the fridge before booting when the error message “ddi mmc_read failed” appears). Otherwise, it would have been more complex. As a result, I had stepped away from TOTP for a while. Thanks to the episode in the podcast I have a backup and now use TOTP for many more services. Recently, the recovery test also ran successfully.

In making the switch and creating the backup, I looked around for alternatives for many services and still stumbled upon SMS as the only option far too often. Even if it is not the primary option, as an enabled fallback option it brings its weakness to full effect. Very often, I also encounter email as an alternative to SMS. This is at least a small advance (in one case even with PGP), but usually not the big hit. Also, I have often experienced that the e-mail was on the way longer than the code would have been valid.

I would have loved to switch to FIDO2 on a large scale, but there were really only a small number of services offering it at all – maybe I’m just doing the wrong things on the internet. For the enthusiasm FIDO2 generated when I first heard about it, I find it very disappointing.

In principle, I find the idea of FIDO2 directly in the OS charming, even if I clearly prefer a second dedicated hardware. However, for many services, anchoring authentication in the OS would be better than username/password. Most of the time, however, storing a simple account in my KeePassXC is sufficient. For some accounts with FIDO2, I find the corresponding login options too well hidden.

According to comments on CASSM, U2F is also assigned to the top layer (Passwordless). In many implementations, this is not a real MULTI factor for me, since the password is not needed – apart from the PIN for the hardware token. From a purely technical point of view, I think FIDO2 is simply a more elegant solution. In the end, however, the characteristics of the implementations by the using services are probably almost more determining for the usability and the security.

The fact that MFA is not the holy grail of authentication and that even Level 7 has its weaknesses only really became clear to me after the Lapsus$ attacks (at least it sounds like Level 7 in the reports). Sure, weaknesses have been pointed out frequently before, but through a blog post by Bruce Schneier, I came across a post on Ars Technica that illustrates MFA bombing well: “Call the employee 100 times at 1 am while he is trying to sleep, and he will more than likely accept it. Once the employee accepts the initial call, you can access the MFA enrollment portal and enroll another device.” Well, I have to admit one thing to Lapsus$, I didn’t come up with such ideas as a teenager.

The fact that such attempts do not show up in the evaluation of log entries (e.g. by a SIEM) is in my opinion a fax pas – at least if the attempts were really as brute as it reads. With discreet, but continuous attempts it depends again on the awareness of the employees and whether they also report faulty requests. Whether these are then correctly recognized and handled as a security incident is another source of error that opens up a lot of room for error.

Nevertheless, MFA bombing based on social engineering or brute force, depending on its design, is a threat that I would like to consider in the future.

So, MFA is only secure in conjunction with other supporting measures, and the interaction probably rarely works out-of-the-box and is an important learning process.

I have somewhat mixed up the problems from the private and the enterprise environment here. In both cases, however, evolved environments combined with suboptimal prioritization are encountered and account for a large part of the problem. However, I am confident that there will be improvements in the future.

The technical basis for my blog is also a good example of the problems. Thanks to the small number of accounts and roles, I can be notified of every successful and unsuccessful submission and evaluate everything manually (this is not meant to be a challenge). I would have liked to use FIDO2, but in the overall interaction TOTP seemed the most viable and reliable.

In general, a central authentication provider would be a bit cool for many sites, but mostly you only encounter services from Google and Facebook for this and they are questionable and not an option for me at this point. And since there are currently no comprehensive alternatives, I don’t need to worry about the other disadvantages of a central solution. That’s much easier in the enterprise environment.

Source:

Translated with www.DeepL.com/Translator (free version)