Protect your organization from scandalously easy-to-hack MFA security "solutions"
Multi-Factor Authentication (MFA) isspreading like wildfire across digital environments.However, hundreds of millions of dollars have been stolen from MFA-protected online accounts.How?Mostpeoplewho usemultifactor authentication (MFA)have been told thatitis far less hackablethan other types of authentication, or eventhat it isunhackable. You might beshocked to learnthatall MFA solutions areactually easy to hack.That's right: there is noperfectlysafe MFA solution.In fact, most can be hacked at leastfivedifferent ways. Hacking Multifactor Authentication willshow youhow MFA works behind the scenes and how poorlylinkedmulti-stepauthentication steps allowsMFA to be hacked and compromised.
Thisbook coversovertwodozenwaysthatvarious MFA solutions can be hacked, including the methods (and defenses) common to all MFA solutions.You'll learn about thevarious types of MFA solutions, their strengthens and weaknesses, andhowto pick the best, most defensible MFA solution foryour (or your customers') needs.Finally, this book revealsa simple methodforquickly evaluatingyour existing MFAsolutions.Ifusingor developing a secure MFA solutionis important to you, you need this book.
Learn how different types of multifactor authentication work behind the scenes
See howeasy it is to hack MFA security solutionsāno matter how secure they seem
Identify the strengths and weaknesses in your (or yourcustomers') existing MFA securityand how to mitigate
AuthorRoger Grimes is an internationally known security expert whose workon hacking MFA has generated significant buzz in the security world. Read this book to learnwhat decisions and preparationsyourorganization needsto take toprevent losses from MFA hacking.
Frequently asked questions
Simply head over to the account section in settings and click on āCancel Subscriptionā - itās as simple as that. After you cancel, your membership will stay active for the remainder of the time youāve paid for. Learn more here.
At the moment all of our mobile-responsive ePub books are available to download via the app. Most of our PDFs are also available to download and we're working on making the final remaining ones downloadable now. Learn more here.
Both plans give you full access to the library and all of Perlegoās features. The only differences are the price and subscription period: With the annual plan youāll save around 30% compared to 12 months on the monthly plan.
We are an online textbook subscription service, where you can get access to an entire online library for less than the price of a single book per month. With over 1 million books across 1000+ topics, weāve got you covered! Learn more here.
Look out for the read-aloud symbol on your next book to see if you can listen to it. The read-aloud tool reads text aloud for you, highlighting the text as it is being read. You can pause it, speed it up and slow it down. Learn more here.
Yes, you can access Hacking Multifactor Authentication by Roger A. Grimes in PDF and/or ePUB format, as well as other popular books in Computer Science & Cyber Security. We have over one million books available in our catalogue for you to explore.
Chapter 21: Test: Can You Spot the Vulnerabilities?
5 Hacking MFA in General
Chapter 5 will cover hacking MFA generally, without showing any specific techniques. Anything can be hacked. Anyone telling you that they have something that can't be hacked is lying or naĆÆve. Either way, they shouldn't be trusted. Multifactor authentication (MFA) has many components and supporting infrastructures many of which the MFA solution vendor has no control over, and each can be hacked by various means. This book is dedicated to showing dozens of ways that all, or specific implementations, can be hacked, although this particular chapter just addresses the topic in a generalized way.
This book will not be able to show all the ways MFA can be hacked, although I'll fit as many as I can within these pages. There are ways that I don't know about; I haven't thought of them or encountered them, or I've simply forgotten them. Many MFA vulnerabilities are only known to the potential attacker who is keeping them secret until they are otherwise needed. Or they are used sparingly and rarely in a way that the exploited victim isn't even aware of. The biggest nation-states have thousands of nonpublic vulnerabilities cataloged away, awaiting a specific need. Others are known by their vendors and kept secret because the vendor doesn't know a good way to mitigate the risk.
Many MFA vulnerabilities haven't been discovered yet. The world is full of examples of hacked things that had vulnerabilities that went undetected for decades, until they were finally discovered by a single, curious soul. Vulnerabilities often sit in plain sight for years, until someone reviewing the code or trying a specific action saw a potential weakness and explored it. Many vulnerabilities are found by accident. Someone is trying to do something new, such as extend or automate functionality, and they end up accidentally causing an error that reveals a previously unfound vulnerability.
Many, if not most, vulnerabilities will go undiscovered, without anyone recognizing the vulnerability that could be exploited. Humans are imperfect. Just as we can't stop all programming mistakes, we don't find every mistake or vulnerability. We will always create more vulnerabilities than we will find. It's just the nature of programming. Even the software that we design to specifically find vulnerabilities doesn't find every one; it can only find the vulnerabilities we all already understand and know how to find.
Chapter 5 is not only a generalized look at how MFA vulnerabilities are found, but also summarizes all the different components. This chapter should be used by nonmalicious hackers looking to ensure that an MFA solution they are considering is as secure as possible as well as by MFA developers to ensure that the solution they are delivering is as secure as possible from the start when they offer it to consumers. Nothing is vulnerability free, but by learning and using the lessons of past exploits, the number of future bugs can be minimized. Many of the discussions in this chapter apply to most digital solutions and not necessarily just authentication or MFA. The rest of Part II will cover specific examples of MFA vulnerabilities that illustrate the generalized vulnerabilities covered here.
MFA Dependency Components
No MFA solution is an island. Every MFA solution is just one part of multiple components, relationships, and dependencies, as visually depicted in Figure 5.1, and each of these components is an additional area where an exploitable vulnerability can occur.
Essentially any component in the entirety of the MFA's life cycle, from provisioning to deprovisioning and everything in between, is subject to having exploitable vulnerabilities and hacking. And like the proverbial chain, it's only strongest as its weakest link. Here is a list of the phases and components involved in MFA:
Enrollment
User
Devices/hardware
Software
Authentication factors
Authentication secrets store
Cryptography
Technology
Network/transmission channel
Namespace
Supporting infrastructure
Relying party
Federation/proxies
APIs
Alternate authentication methods
Recovery
Migrations
Deprovision
The rest of this section will explore these components in more detail. Some of this chapter will repeat terms learned in early chapters, but they are included here again for completeness and redundancy canāt hurt when discussing authentication systems.
Enrollment
Enrollment (also known as provisioning) is the process of a subject being registered and verified to get an authenticated identity (label). An unverified and unregistered subject is known as an applicant. They are applying for an authenticated identity. The credential service provider (CSP) asks for and receives one or more (unique) subject attributes, which can be used to clearly identify the subject. This process is known as identity proofing. The subject can enroll themselves or have another enrollment agent trusted by both the applicant and the CSP do it on their behalf.
A critical part of the process is that the CSP verifies the applicant's submitted attributes. Without the CSP strongly verifying the applicant's submitted attributes and ensuring that the applicant is who they say they are and that the submitted applicant attributes truly belong to the applicant, authentication is nearly worthless. How strongly the CSP verifies the identity and attributes of the applicant determines the level of assurance.
Think of the enrollment process like a person applying for a driver's license. The person must pass a physical driving test to show that they have basic driving skills, answer a set of knowledge-based questions to prove they know the ārules of the road,ā and prove they are who they say they are. The latter involves providing sufficient proof to the driver license issuer (the CSP in this example in the United States is the Department of Motor Vehicles [DMV]) to get the official driver's license. The applicant does this by providing multiple forms of acceptable identity attributes, such as a birth certificate, Social Security card, and a bill sent to their home residence to verify the address. Years ago, the DMV didn't require as much assurance as they do now, but previous weak validation allowed serious identity crimes to occur, and so now the DMV requires stronger identity assurance.
But if you get a driver's license issued to you, almost anywhere (e.g., law enforcement, liquor store) that requests proof of your identity will accept the DMV-issued driver's license as proof of your identity. It's the same thing with CSPs. Any relying party that trusts the CSP will trust that a CSP-verified identity submitted by a subject to them is accurate. But if the CSP doesn't do their job and doesn't accurately verify the subject's identity and attributes before issuing a verified identity, then the whole process breaks down.
A good, everyday digital example of this is the use of Pretty Good Privacy (PGP) asymmetric encryption keys. Created in 1981 by Phil Zimmerman, PGP is a very popular encryption program that comes in both open source and commercial versions. Everyone who gets a PGP...