What’s the Difference Between Two-Factor Authentication (2FA) and Multi-Factor Authentication (MFA)?

Sage Driskell

by Sage Driskell

 

All Two-Factor Authentication (2FA) is Multi-Factor Authentication (MFA), but not all MFA is 2FA. Multi-Factor Authentication works on the principle of using multiple pieces of secret information in order to verify identity. Standard usernames and passwords can be brute forced, but using a separate piece (or more) of information makes this more and more impractical. Some MFA schemes will use secret questions (effectively extra passwords), or a one time key from some kind of authentication application.

MFA and 2FA are a prerequisite for security anymore. It used to take days to guess an 8 character password, now it takes literal minutes on a $35 Raspberry Pi. Everything requires a password, and people can be lazy and recycle passwords. If a user’s password is compromised for one site, who knows what other accounts are now compromised? Even the most trivial 2FA or MFA solution can reduce the impact substantially.

How Does MFA Work?

MFA (and by extension 2FA) add a protection scheme based on knowledge, possession, or biometrics.

Knowledge

This form of authentication relies on a knowledge based challenge. This can be an extra password, a security question, or some other type of challenge. The goal here is to buy time without inconveniencing the user. By adding a separate password, an attacker has to gain access to both passwords, and avoid locking themselves out trying to do so. Some challenges will have multiple potential knowledge tests to make this more complex.

Some of the first MFA I ever worked with was through a bank. The bank had a list of 20 images which you picked from and added a description to. Each time you logged in, it would give you a subset of the images, you picked the one you had, and then it prompted you for the description. If you got it wrong 3 times, it locked the account for some period of time. My password got hacked plenty of times, but my account never did. Even something this low-tech ended up stopping dozens of potential breaches.

By having you pick the specific image first, it tested your knowledge. The prompt would then pop up no matter what was picked. This method is somewhat safe, but not foolproof by any stretch of the imagination. A single incident with a keylogger could get everything.

Possession

Possession challenges rely on the physical possession of a device or some other item. This can be a USB key or a device which generates a code. Most things people think of as 2FA are generally going to be a password based on possession of an application which generates a one-time key.

Almost everyone has something like Microsoft Authenticator or Google Authenticator on their phone for work or just general security. If someone manages to compromise your computer, they don’t necessarily get your account outside of the current session. Using a separate device to authenticate mitigates the effectiveness of a keylogger or of a very coordinated attack to gather information on a target. A user can tell someone about their first pet “Mr. Fluffikins” (coincidentally their security verification answer), but if I tell you my authenticator says “224 544” right now it does absolutely nothing to getting through MFA on my account.

Biometrics

Fingerprint readers, retina scanners, facial recognition, etc. are all forms of biometrics. Biometrics rely on inherent properties of the user. This works for and against security though. A mask can fool facial recognition, while a carefully crafted gloves can trick the fingerprint reader. Biometrics are inherent properties, so the entire method needs to be changed if they’re compromised. Collecting biometrics for work and similar also presents privacy issues for their storage and usage.

Which Method Works Best?

Most standard 2FA solutions use the principle of possession, but this doesn’t mean it’s objectively the best method. Each of these methods performs a balancing act between convenience and security. Knowledge is the easiest to get and easiest to track without extra equipment. Biometrics are the hardest to copy (at present, deep fakes and technology aren’t helping here), but they’re also impossible to (practically) change. You can’t just grow new fingerprints. Possession strikes a balance. An item or a device can be revoked, but users have to account for an extra device. If you forget your phone, you’re out of luck.

Possession is the most practical at present. Having a physical device means that stealing a one-time key or password is near useless (unless the algorithm can be cracked), and the device can be revoked if it is physically misplaced or stolen. We use the principle of possession (and a degree of knowledge for an added challenge) for ID 20/20, our in-house MFA solution. The trick is using a device someone will (almost) always have and a way to authenticate without inconveniencing the user.

Why Is MFA So Important?

Phishing and social engineering are some of the biggest security threats to businesses. MFA helps neuter phishing and social engineering attacks by adding a layer that an end user will struggle to give away. It’s easy to type your password into the wrong box, but how do you give your phone or a USB key out too? You also know almost instantly when one of these devices is missing.

You can try and train end users, but people don’t always listen and don’t always want to learn. It’s hard to tell the difference between l and I, or why it matters if a site is .com or .org. What does it mean if a certificate is invalid? Most users don’t know, and more importantly, they don’t really care. They see an email saying they have to “act now” to prevent a catastrophe and they act. Attackers prey on ignorance and emotion.

MFA throws a wrench in the gears for this. The username and password are only two of the three parts to the key. Without the third part, the whole exercise doesn’t accomplish much for its direct target. If 2FA or MFA in general is available, enable it. If a product doesn’t offer MFA and it’s going to have personal information or other sensitive data, ditch it as soon as possible.

Using More Factors

The more factors in use for authentication, the harder it is for an attacker to get in. The more important information is, the more factors which should be in play. Ideally, use multiple challenges. Have a secondary knowledge test on top of a possession based challenge. Stack the odds in your favor.

A targeted enough attack might get the username and password, but it’s harder to get MFA information. Harder, but not impossible. Your user might tell someone their mother’s maiden name or it might even get breached from a targeted attack elsewhere. The more unrelated pieces of information and unrelated challenges there are, the harder it is to actually breach an account even if the credentials are leaked. Your mother’s maiden name doesn’t help much when it’s necessary in conjunction with a one-time password.

Using MFA

MFA is often seen as a hindrance and an inconvenience, but it’s more important now than ever to use it. Apply MFA where you can to reduce the attack surface for a given product. If you are helping your client find a MFA solution, try to go with something they use already. Don’t go with Google Authenticator if they have to use AuthAnvil already if you can help it.

You don’t want your bank giving away your money to the wrong person, and you don’t want your users doing the same to their employer either. Present MFA implementation as a protection for the client’s business rather than just a plain “security measure” with cryptic “future risks”. Don’t introduce a technical solution without making it mean something to the client. If you frame MFA the right way, clients will jump on it, but frame it the wrong way and it becomes an inconvenience with no tangible benefit. Sell MFA as a good business move.

Make MFA work for your client and not against them. Even an extra password or some other knowledge based challenge is going to be better than nothing. It doesn’t have to be over the most efficient solution, it just needs to work and provide security.

Sage Driskell

by Sage Driskell

 

MSPs large and small are systematically being targeted over and over in the news. It’s almost weekly a new article comes out about a given large provider being targeted. Many of these attacks come from API weaknesses. You can’t control the provider or service, but you can minimize the chance of these attacks impacting you and your customers.

Leaky APIs

Leaky APIs are APIs which allow easy exfiltration of data from a service. These exploits often stem from deprecated APIs or privilege escalations. Many deprecated APIs exist in products for backwards compatibility, but they often come with caveats and holes.

Privilege escalations can happen on APIs due to loose queries which can return data from outside of their scope. Other escalations rely on multiple APIs which accidentally return data outside the scope a user can see normally due to their interactions. A deprecated API may help break another API when glued together with the wrong product.

These types of attacks are often used to harvest credentials or information for attacks later. Stolen passwords can be used on any similar account on multiple platforms to see what is shared. Hackers glean data which makes their later attacks easier either for traditional attacks or for things like phishing attacks.

Weaponizing APIs

With the creation of things like fileless malware and easy, privileged access via RMM tools, weaponizing an API has never been easier. Other products like Webroot have been had similar incidents from adding the feature to run commands remotely. This feature creep combined with API access makes these tools further targets.

Most products rely on various SQL products for databases. Many APIs where the developers are not security conscious will be a thin layer between the user and raw SQL queries. These can be weaponized to poison the data allowing greater access or to exfiltrate useful data. Depending on the product, it may be possible to insert hostile, arbitrary code which gets run by something within the API. Some RMMs even store scripts as blobs in the database.

How Do These Attacks Happen?

These attacks happen because of lax security policies on both sides of the equation. Many vendors do not take into account the ramifications of the access their API can provide. Vendors which integrate their products may ask for more permissions than they should need to function. A lot of permission sets are too permissive in general because its easier for the developer and the user to set up.

Clients of these products often fail to limit users enough. API users floating around provide an easy in to a company if they are compromised. Sometimes, the way multiple APIs talk to one another may be targeted as well. A simple return status from a query in a limited API may provide information that the other API would not normally have given. A simple boolean reply may provide a necessary bit of information for a malicious actor to work off of.

What Can You Do?

Removing unnecessary API users or users which may have API access is one of the easiest steps to protecting yourself, even from APIs outside of your control. Turning obsolete or unnecessary API versions, or even entire APIs off, is another great step. Use it or lose it. Trim off enough of the fat, and the hunter will target easier, more profitable prey.

Shrink your attack surface to shrink what you have to keep safe. Besides just trimming off the obsolete, scope your API users. An API user which only reports from a product doesn’t need write access. Your users need Two-Factor Authentication (2FA) everywhere possible. Do not share credentials between API users and do not recycle user names if you can help it. These basic steps have headed off many attacks before they even have the chance to become a threat with very little imposition on our technicians.

If you run products in house which have an API you use, try blocking traffic based on IP for whatever is using it. This isn’t always possible, but can often be used to limit certain service APIs to specific, known entities which limits the impact of a leaky or broken API. Rate limiting connections is another great step. If your average client hits 5 requests per hour, why not set a limit of 10 requests per hour so that brute force attempts take significantly longer? Alerting on these thresholds is another great step, especially if you control something in the stack which can see this.

Researching Products

No product is going to be perfect, but you can shop around to minimize damage. How does your current product handle exploitation? Are they quick to report it or do they take their time? A vendor which reacts fast, may still get hit, but at least you’ll know before your clients do and be able to protect yourself.

A vendor which tells you about an exploit quickly is also a vendor which works on fixing it quickly. Look at the vendor’s response history and how long it takes them to clear out serious CVEs to know how big a threat they are to your business. If they can’t keep up with serious vulnerabilities which are reported, what else are the missing that’s not reported yet?

Always be on the lookout to how a vendor impacts you and your clients. A vendor which never has real access is easier to trust than one which can make system level changes. Look out for how they handle older APIs too. A vendor which leaves deprecated features in too long runs the risk of being exploited down the line.

Ask your vendor what they do about older versions and whether or not they rate limit requests and accounts. See what the scope of their API access is. The irony is that those proudest of their APIs open access will usually be the first to tell you about it. Weigh this with your other options and the impact on your client before signing.

Our Strategy

We minimize unnecessary API interaction and work to maintain best practices to prevent exploits. When an API becomes obsolete, it is removed from our system where possible. API access is also further limited for fixed entities to prevent more wholesale access from being available off premise. Users need 2FA to get into basically anything. These patterns heavily minimize the attack surface with very little maintenance. Our large community contributes to helping make sure every potential exploit is known as soon as possible.

Our Security Focus

We focus on a holistic approach to security, and try to stay ahead of exploits and reduce the risk of any given component. Your security is only as strong as its weakest link, so you must be vigilant. Prevent unauthorized API access by preventing any access unless necessary. We want to know about an exploit as soon as it is public, if not before and be able to react to it.

Cutting off your finger is better than losing your arm, but not having to lose either is best. Prioritization of exploits is extremely important to surviving in the modern security landscape. We’re well past the days of “perfect security” even being a pipe dream, let alone realistic. We work to hedge our bets and make our platform the least ideal for hackers without sacrificing functionality. An ounce of prevention, even if it’s bitter, is a lot better than a pound of cure.

Going Forward

Stay ahead of hackers by locking down every aspect of your security. APIs are one of the most often overlooked, easily exploited part of many products. Almost every major software product is going to have an API of some kind too. Know what you’re dealing with and limit the damage where you can. MSPs have become low hanging fruit to many hackers, elevate your security and elevate yourself from being next.

 

Our very own Sage Driskell is a Core Services Engineer at The 20. Interested in working for us? We’re hiring!