When it comes to cyber security architecture, you really are only as strongest as your weakest link. Your organisation switches to blanket AES encryption with a “military grade” (what does that even mean?) 256 bit key, but then you store the key in “user land” in an unprotected part of the OS, essentially rendering it public knowledge. Your organisation implements physical access control with a cryptographic challenge response mobile application that leverages NFC technology – but then staff are not trained to prevent tail gating. Workstations are configured to be patched nightly, but USB thumb drives are used regularly to transfer data between teams.
For every action, there is a potential reaction – even if the security control that is adopted is a genuinely good one.
Adversaries Are Lazy
But the bad guys are lazy (and so are some of the good guys). And I mean that actually as a compliment. Adversarial behaviour is likely driven by a risk/reward ratio – what can the attacker gain for as little risk (and effort) as possible?
The rise in cyber-war attacks often have many similar characteristics:
- They are difficult to attribute – meaning individuals as opposed to nation states are even less likely to be caught and prosecuted – driving more aggressive behaviours
- They are automated – scripting, tool-kits, botnets and AI are all leveraged to create a “computer versus computer” war game
- They are generic – yes specific organisations are targeted with business email compromise and spear phishing, but an attack against one oil pipeline might well have been against another
- Low capital expenditure – many attacks “stand on the shoulder of giants”, leveraging previous tactics, techniques and procedures from successful hacks
So what has this got to do with password resets? Well attackers will target the weakest link. They will find it, automate against it and improve upon existing knowledge.
Arise MFA – The Saviour?
Ah ha – but we’ve implemented multi factor authentication, so “we’re safe”. Well, unfortunately, as good a move MFA is – and it is an essential move for any doubters out there – it is, yet again, only one step on the journey of having an agile and adaptable security architecture. Whilst there are notable attacks against some MFA flows, I want to amplify the surrounding use cases associated with login flows. I’m thinking about MFA enrolment, device migration, device reset and of course, the omnipresent password reset.
MFA Enrolment
The enrolment of the MFA modal is likely to be a low frequency event – perhaps 2-3 times during the lifetime of the identity. Once for initial usage with subsequent enrolments likely for lost devices. But what does the enrolment process look like? Well, number one, it’s another authentication event. Don’t think of enrolment as a separate “special” journey. It’s authentication. Unfortunately the end user does not have MFA capabilities – otherwise they wouldn’t be enrolling. So what counter measures can be put in place? And you need to think about counter measures.
Simply leaving the user to authenticate with a username and password can negate the use of MFA for future logins. Some simple counter measures should include the basics – so bot prevention, rate limiting, user-agent validation and network address validation. A bit more conditional logic could include enrolment failing if an existing MFA modal was used recently. If of course a secondary enrolment is needed due to a device loss, perhaps another out of band measure is needed.
What does that look like? Perhaps an email to a pre-registered address or a dynamic knowledge based authentication (KBA). KBA is notoriously poor, with many answers simply public information, especially for consumer based authentication. However, it can be augmented with more dynamic information such as recent account balances or system activity.
Other enrolment steps could leverage ID proofing as per the NIST 800-63B guidelines for digital identity (essentially section 6.1.1). Here for example the use of a laptop camera to take a photo that maps to a verified claim of identity such as a driving license or passport might be the way to go. This of course assumes some workflow for identity assurance has taken place previously. We’re essentially trying to introduce a multi-step process. It is quite likely those steps will be more cumbersome than the MFA they’re enrolling for however.
Password Reset
If a password reset is required and MFA has been enrolled and is available – use it! Don’t allow a password reset to take place as a single factor authentication event. That can essentially end up with a user being locked out. If the user is already authenticated and perhaps accessing their profile page to perform a reset, leverage the enrolled MFA modal for validation as a “step up” or “transaction based authorization” event. If the user is not authenticated and the password is required as per an MFA flow, the reset should leverage the previously bound MFA modal if possible, perhaps combined with a magic link to trigger a push authentication or mobile device interaction.
Device Migration
A device migration (or the addition of a secondary device) should leverage existing active MFA modals. This is again described in NIST 800-63B section 6.1.2 Post Enrolment Binding where a flow that includes a push notification for example, or the use of an out of band challenge/response perhaps via a QR code.
Device Reset
A malicious attack against a device reset flow is going to create a denial of service event for a particular user. Whilst that may well be low reward for high effort for an adversary, the reward may of course be higher depending on who the user is. A reset is of course a reactionary event – either because the device has been lost – or has become compromised. As such, the barriers to use, should be low enough to apply a response quickly, but be secure enough to prevent misuse. What are our options here? Password authentication followed by a magic link sent to a pre-registered email address seems quick, dirty and cheap. Dynamic KBA via a chat bot app, perhaps accessed via a trusted laptop is also a more automated flow than having to call a help desk.
In summary, think about the orthogonal flows that are associated with the use of MFA. As those journeys are authentication events too, treat them as such. As their frequency of use is much lower than the main login process, it may well be acceptable to introduce some pretty high levels of friction here, that leverage proofing and biometry. Be aware of those journeys and map them out like you would any other asset.
About The Author
Simon Moffatt is Founder & Analyst at The Cyber Hut. He is a published author with over 20 years experience within the cyber and identity and access management sectors. His most recent book, “Consumer Identity & Access Management: Design Fundamentals”, is available on Amazon. He is a CISSP, CCSP, CEH and CISA. He is part-time postgraduate on the GCHQ certified MSc. Information Security at Royal Holloway University, UK. His 2021 research diary focuses upon “How To Kill The Password”, “Next Generation Authorization Technology” and “How IAM Countermeasures Can Defend Against Cyberwar”. For further information see here.