- Products & Services
- Free Tools
- Pricing
- Resources
- About Us
- Contact Us
- Account Login
Contrary to popular belief, all multi-factor authentication mechanisms can be compromised, and in some cases, it’s as simple as sending a traditional phishing email.
Decades of successful attacks against single-factor authentication methods, like login names and passwords, are driving a growing large-scale movement to more secure, multi-factor authentication (MFA) solutions in both corporate environments and by websites everywhere. This trend is exemplified by the fact that over the last few years, the most popular websites and services, including those owned by Google, Microsoft, Facebook, and Twitter, have offered MFA solutions to their customers. Many internet sites and services now offer both traditional login name/password solutions and more secure, MFA options.
Some large companies like Google are reporting great success in defending against some common hacking attacks by moving their user base from single-factor to multi-factor authentication. MFA solutions are supported by default in the most popular operating systems, and additional MFA solutions are offered by hundreds of third-party vendors. Common open MFA standards, such as those promoted by the FIDO Alliance, are being widely adopted.
MFA was previously used (mostly) for organizations and websites needing the highest security assurance. Today, MFA tokens are being offered or used by ordinary organizations and websites, and MFA tokens can be purchased as low as a few dollars per device. Many consumers trust the security of MFA solutions so much that they are purchasing and using MFA, when possible and allowed, on all the websites and services which allow it.
The broader adoption of MFA is a positive development for computer defenses and will defeat many of the threats that would otherwise be more readily successful against single-factor authentication solutions. All other things considered equal, all admins and users should consider and use MFA solutions instead of single-factor authentication solutions to protect sensitive data.
With that said, the ability of MFA to reduce computer security risk has been overstated by many vendors and proponents, leading to a misunderstanding that the application of MFA means all attacks that were successful against single-factor authentication cannot be successful against MFA. For example, many MFA admins and users believe that email phishing is no longer a threat because users cannot be phished out of their login credentials. This is not true.
While MFA does reduce, and in some cases, significantly reduce particular computer security risks, most of the attacks that could be successful against single-factor authentication can also be successful against MFA solutions. There are over a dozen ways to attack different MFA solutions. Often, a single MFA solution is susceptible to multiple exploitation methods.
Roger A. Grimes, KnowBe4's Data-Driven Defense Evangelist tested over 150 MFA solutions while researching his most recent book Hacking Multifactor Authentication.And he wants to share what he learned with you! Join Roger as he discusses the good, the bad, and the ugly lessons he learned from his research. He’ll share with you what works, what doesn’t, and what you should absolutely avoid.
Authentication is the process of a subject (e.g., user, device, group, service, etc.) proving ownership of a particular identity.
An identity is any unique (to the involved namespace) label identifying a specific subject. An identity is often represented by a login name (ex. johnd), email address (ex. johnd@abccompany.com), or unique series of characters, but can be any unique, previously agreed upon, label within the same namespace.
A namespace is an organized system to help collect, identify, and locate specific entities and their related attributes. Common name spaces are Domain Naming System (DNS), Microsoft Active Directory, and Lightweight Direct Access Protocol (LDAP) databases. A namespace may contain more than one identity label per subject (for example, Active Directory can use DNS, LDAP, email address, and User Principal Name (UPN), but each label must be unique in the same namespace and can only represent a single subject.
All authentication and access control steps involve one or more identities. All authentication involves an identity label, which uniquely identifies the subject doing the authentication. Identities have to be created prior to or as part of the initial authentication process. The identity should be different than what is being provided to prove ownership of the identity. For example, in Microsoft Windows, although a subject might use a fingerprint to authenticate (i.e., prove ownership of the identity), the label attached to an authentication attempt will probably be the user’s Active Directory login name, their UPN, or their email address. The identity label is very important in the authentication process.
Authentication is the process of a subject proving proof of (sole) ownership of an authentication identity within a namespace in order for the identity and its associated permissions, memberships, rights, and privileges, to be used in access control authorization operations related to that namespace.
The identity and the proof of ownership of the identity must have been previously, hopefully securely, stored in at least one location (e.g., table, database, registry entry, etc.), to be used in future authentication challenges. The storage of the authentication proofs is often not stored on the server/service/site directly involved in the authentication and is instead stored on third-party server/service/sites involved in the authentication, which both parties (server and client) trust.
Each storage location is a potential attack vector for compromising authentication. Anyone using authentication should think about where the authentication proofs are stored, who has access to those locations, and how trustworthy the storage of those credentials should be considered. Storage of authentication secrets should always be restricted to the bare essential number of administrators and aggressively monitored and audited. If the authentication secrets are compromised, the authentication process can no longer be fully trusted.
Authentication can be successful or unsuccessful. Only successful, legitimate authentication is supposed to lead to the next process.
After a successful authentication, in most cases, the access control process then associates an access control object (e.g., token, ticket, etc.) to the tested identity. What this access control token contains varies by system and protocol. In some systems, it may only contain another unique identifier, such as a series of numbers or characters. In other systems, it may contain a list of group memberships, permissions, privileges, and other needed information.
The token may or may not have a predetermined maximum lifetime, which upon expiration, forces the subject to re-authenticate to remain in an “active” session. In Microsoft Windows, an access control token may arrive in the form of a Kerberos ticket or an NTLM or LM token. On websites and services, most access control tokens are represented by an HTML cookie, which is a simple text file.
Authorization is the process of comparing the now successfully authenticated subject’s access control token against previously permissioned/secured resources to determine the subject’s access to those objects. In most cases, once a subject has been handed an access control token, the subject (or in reality, a process or program on behalf of the subject) submits the access control token for authorization and the subject does not need to reauthenticate until the expiration of the token. Once an access control token has been issued, authentication is not tested for each and every authorization access attempt. Possession of the access control token is considered proof of successful authentication.
HUGELY IMPORTANT POINT!
No matter how a person successfully authenticates, be it simple password, biometrics, or a multi-factor authentication token, once the authentication is successful, the authentication token assigned to the identity is usually the same for all authentication methods and often bares little resemblance to the authentication method used.
For example, suppose a subject uses his/her fingerprint to login to Windows and Active Directory using his/her laptop and the laptop’s built-in fingerprint scanner. The authentication process happens locally on the laptop. The laptop’s fingerprint recognition and authentication software and hardware combination successfully authenticate the user. At that point, the user’s fingerprint is no longer used anymore. The fingerprint is not sent around the network to be involved in access control operations. The user’s fingerprint is not copied or sent to another networked computer, so the user can access a file or folder.
Instead, once the user has been successfully authenticated using his/her fingerprint (or other authentication method), the Windows operating system issues them a Kerberos ticket or NTLM or LM token. It is that resulting ticket or token that the user (or more accurately written, processes or programs acting on behalf of the user) uses for all access control authorizations. And if an attacker can get their hands on the access control token, they don’t care how you authenticated. Possession of the token, from legitimate means or not, is usually treated by authorization processes the same as if the holder of that token successfully authenticated. The authorization process does not have a way of knowing whether or not the current holder of that access control token was the legitimate user or ever successfully authenticated. This key fact is often used by hackers to compromise multi-factor authentication.
This same concept applies more generally to the entire authentication process. Attackers exploiting authentication often look for weaknesses in implementations along the entire process. They will look to see if there are gaps in the linkages between the identity, authentication, and authorization… and there very often are.
Get your copy of the full 41-page eBook for everything you need to know about multi-factor authentication including the information listed here, as well as a deep dive on the dozens of ways it can be hacked. Plus get advice on the best ways to defend your organization from cybercriminals.
Authentication is normally conducted between two or more parties, often referred to as the server (the object/application/process being authenticated to) and client (the object authentication to the server) and can be one-way or two-way. Many authenticating objects can act as both a server or a client depending on the reason for authenticating. This is to say that a physical server isn’t always acting as a server and vice-versa. Additional servers may be involved in the authentication process, and so there may be multiple authentications occurring during a single authentication event. A good example of that is Kerberos, where the client must authenticate to the Kerberos authentication server as well as the intended target server.
Most authentication is one-way, meaning the client authenticates to the server or the server authenticates to the client, but the opposite is not true, at least during the same authentication event. A very common example of this is web servers using HTTPS. When HTTPS is involved, the web server has an HTTPS/TLS digital certificate, which is linked to its identity (usually its DNS address). When a client connects to the web server over HTTPS, the server sends its HTTPS digital certificate to the client, to prove its identity and to secure an encrypted channel in which to generate symmetric keying material. The client receives the web server’s HTTPS digital certificate and verifies its trustworthiness. If successful, the client will trust the server to be the server it says it is (based on the subject’s identity). In one-way authentication, the client does NOT prove its identity to the server, at least within the same transaction.
With two-way, “mutual” authentication, both the client and server authenticate to each other as part of the same authentication process. If one side fails, the other side automatically fails.
Proof of ownership of an identity is made by a subject supplying the identity and one or more authentication factors. An authentication factor is something supplied which only the subject knows or can supply, and by doing so, proves sole ownership of the authenticated identity. In general, there are only three basic types of authentication factors, widely known as:
Password, PIN, Connect the Dots, etc.
USB token, smartcard, RFID transmitter, dongle, etc.
Biometrics, fingerprints, retina scan, smell
You will sometimes hear about MFA solutions that have more than three factors (e.g., five-factor), but what these solutions are referring to are multiple instances of the same three factors. In order for the factors to be most protective in an MFA solution, the factors should be different.
The concept is that the use of two or three of these factors makes a hacker’s job more difficult. For example, the hacker may be able to con you out of a password, but it will take additional effort to also steal your hardware token if that is used in a MFA solution. Or if a malicious individual picks up your MFA hardware token, it would be useless to him/her if he/she did not also have your associated PIN that is required to use it.
There are single-factor hardware solutions that look like an MFA solution, but don’t require an additional factor. For example, existing versions of Google Security Keys™ and Yubikeys™, can be used for one-factor or multi-factor. In their one-factor implementations, it means that if a person finds those hardware devices, if he/she is not otherwise secured, it means he/she can use them and take-over the digital identity associated with the token. It might be more difficult for a hacker to obtain another person’s single-factor hardware token than phishing him/her out of a password online, but once obtained, it would mean immediate compromise of that identity. All other things being equal, MFA is always better than single-factor authentication for better security, although MFA is rarely universally allowed across all scenarios.
Although MFA solutions should always strive to require multiple factor types, even multiple instances of the same type of factor can improve security over single-factor authentication solutions. However, multiple uses of the same authentication factor IS NOT equivalent to the security given by additional authentication factor types. For example, if a user is required to use both a password and a PIN to login (both the same type of authentication factor (“Something You Know”), then he/she can be phished out of both almost as readily as one. It’s the additional factor types that provide the most protection because they require that the hacker do something completely different in order to be successful.
Authentication factors can be considered in-band or out-of-band.
"In-band" means that the authentication factor being used is conducted over the same communications channel as the primary login method.
"Out-of-band" is when the authentication factor is being sent over a channel different than the primary login channel.
For example, if you’re trying to login to an internet service application and you are required to type in a password and a password recovery answer within the same browser, this is considered two instances of the same factor, both in-band. If, however, you are required to type in a password on your computer and also a second PIN code that was sent to your external cell phone, the second factor is considered out-of-band.
Even better, if you are required to respond to both separate band authentication factors ONLY in those channels, and they aren’t “cross-channel” (i.e., authentication factor sent to you out-of-band can only be responded to in the same band as the other factor), then it provides even more security assurance. Authentication factors sent on the same device, even if in different channels, are not considered as secure as authentication methods using different channels over different devices.
As the number of separate authentication factors and communication bands increase, so too, does security assurance. In most scenarios, using an MFA solution can only improve security, and MFA should be used where and when it makes sense to do so. Unfortunately, not all authentication scenarios allow MFA, and often times not the same MFA solution. At least for now, users will still be required to use a single-factor authentication method in many scenarios.
Even when MFA is allowed and used, it can be hacked, sometimes just as easily as single-factor authentication solutions. MFA is good, but don’t look at it as the holy grail of security assurance. It’s a good tool to increase security, but there is a huge difference between MFA improving security assurance and MFA being unhackable. Understanding the difference is crucial to all entities and security administrators relying on MFA solutions. The key is not to overly rely on MFA as a security savior.
To put this in perspective, most companies that use MFA solutions still get hacked. This is because the most popular reasons for being compromised (e.g., social engineering, client-side attacks, unpatched software, and coding bugs) are not fully mitigated by MFA. MFA can reduce, sometimes significantly, some forms of hacking. But if the companies involved don’t put down the biggest reasons why they are successfully hacked, then MFA will not prevent the hackers and malware from being successful. MFA is good, but it is just one piece of a big puzzle to solve.
MFA cannot, by itself, make a company “unhackable”. Indeed, MFA itself is not unhackable.
There are well over a dozen ways to hack MFA solutions. Some of these attacks have been successfully used against millions of MFA-protected users. Every particular type of MFA solution is susceptible to multiple hacking methods. There simply is no MFA solution that can’t be hacked, multiple ways. Anyone claiming that their solution is unhackable is either lying to you or naïve. Either way you don’t want to be doing business with them. There are some MFA methods are more resilient to hacking or particular types of hacking. Although in most cases, as an MFA becomes less susceptible to hacking, the harder it is for the end-user to use. Security is always a usability-security trade-off, and MFA Is no different. Many people mistakenly believe that their use of an MFA device makes them unhackable. Nothing could be further from the truth.
When thinking about how MFA solutions are hacked there are four general ways: Social Engineering, Technical, Physical Attack, and Mixed.
Social engineering refers to the involved human element using the MFA solution inadvertently in a way that results in its bypass or misuse.
Technical manipulation refers to the methods of exploitation and manipulation that did not require that the human user make a mistake.
Physical attacks involve things like copying fingerprints and directly access secret keys on a key fob using an electron microscope.
Many MFA hacking methods require a mixture of two or more methods, although the vast majority require social engineering along with a technical attack.
To see detailed examples and explanations of these different types of hacks, download the eBook or watch the webinar.
No matter what the hacking methods are, they are attempts at taking advantage of weaknesses between the steps of authentication: identity, authentication secret storage, authentication, or authorization. The attacks are malicious interruption, modification, or false representation of one or more of those steps or transitioning between those steps.
Note: Often times an MFA solution provider will defend their solution against a successful demonstrated hack by saying that their MFA solution, itself, didn’t fail. And while this may be true in the technical sense, MFA solutions are not ultimately tested in sterile laboratories where only direct attacks count. If the MFA solution fails the user for any reason, in the user’s mind, the MFA solution has failed. They doesn’t care so much about the details of whether or not the MFA solution itself was technically responsible.
In a Friday regulatory filing, Microsoft has reported that its corporate email accounts were compromised by a Russian state-sponsored hacking group known as Midnight Blizzard, also identified as Nobelium or APT29. Microsoft's disclosure aligns with new U....
December 7, 2023 - The Wall Street Journal has an interesting perspective on K-12 Public schools suffering ransomware attacks. The number doubles between 2021 and 2022 to almost 2,000 a year. Here are a few paragraphs with a link to the full article:
October 30, 2023 the Wall street Journal broke news that the United States Security and Exchange Commission sued Solarwinds. Here are the first few paragraphs and there is a link to the full WSJ article at the bottom : "the software company victimized by ...
|
 |
 |
 |
 |
 |
 |
