<rt id="aukqg"><nav id="aukqg"><button id="aukqg"></button></nav></rt>
    <rt id="aukqg"><optgroup id="aukqg"><p id="aukqg"></p></optgroup></rt>
    <tt id="aukqg"><noscript id="aukqg"><delect id="aukqg"></delect></noscript></tt>
    <rt id="aukqg"><meter id="aukqg"></meter></rt>
  1. <tt id="aukqg"><noscript id="aukqg"><samp id="aukqg"></samp></noscript></tt>
    <rt id="aukqg"><optgroup id="aukqg"></optgroup></rt>
    <rp id="aukqg"><optgroup id="aukqg"></optgroup></rp>
    MFA Header

    Multi-Factor Authentication Basics and How MFA Can Be Hacked.

    Multi-factor authentication is always preferable to single-factor authentication, but it's not unhackable. Here's why.

    Get the Whitepaper

    Multi-Factor Authentication Defined

    Multi-Factor Authentication (MFA) is the process of a user or device providing two or more different types of proofs of control associated with a specific digital identity, in order to gain access to the associated permissions, rights, privileges, and memberships. Two-Factor Authentication (2FA) implies that exactly two proofs are required for a successful authentication, and is a subset of MFA.  

    No MFA Solution is Unhackable

    Most companies that use MFA are still successfully hacked.” — Roger Grimes, 2018

    Background

    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.

    Multi-Factor Authentication Basics

    Authentication Basics

    Authentication is the process of a subject (e.g., user, device, group, service, etc.) proving ownership of a particular identity.

    Identity

    Login ScreenAn 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 identi?es the subject doing the authentication. Identities have to be created prior to or as part of the initial authentication process. The identity should be di?erent than what is being provided to prove ownership of the identity. For example, in Microsoft Windows, although a subject might use a ?ngerprint 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

    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.

    2-Factor Authentication Diagram

    Access Control Token

    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

    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.

    Biometrics

    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 the Full eBook

    12 Ways MFA EBook

    12+ Ways to Hack Multi-Factor Authentication

    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 the bad guys.

    Download Now!

    One-Way vs. Two-Way Authentication

    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.

    Authentication Factors

    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

    Something You Know

    Password, PIN, Connect the Dots, etc.

    USB

    Something You Have

    USB token, smartcard, RFID transmitter, dongle, etc.

    Fingerprint

    Something You Are

    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.

    One-Factor to Multi-Factor

    YubikeyThe 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.

    In-Band vs. Out-of-Band Authentication

    Authentication factors can be considered in-band or out-of-band.

    In-band Authentication

    In-Band Authentication

    "In-band" means that the authentication factor being used is conducted over the same communications channel as the primary login method.

    Out-of-band Authentication

    Out-of-Band Authentication

    "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.

    Hacking Multi-Factor Authentication

    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.  

    General Ways to Hack MFA

    When thinking about how MFA solutions are hacked there are four general ways: Social Engineering, Technical, Physical Attack, and Mixed.

    Social Engineering MFA Hacks

    Social Engineering

    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 MFA Hacks

    Technical Manipulation

    Technical manipulation refers to the methods of exploitation and manipulation that did not require that the human user make a mistake.

    Physical MFA Attacks

    Physical Attacks

    Physical attacks involve things like copying fingerprints and directly access secret keys on a key fob using an electron microscope.

    Mixed MFA Hacks

    Mix

    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.

    Watch this demo by Kevin Mitnick with an example of a mixed attack that uses social engineering and technical methods to perform a session hijacking:

    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, modi?cation, 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.

    How To Defend Against MFA Attacks

    Social Defenses

    • Realize nothing, including any MFA solution, is unhackable
    • Integrate MFA hacking awareness into your security awareness training
    • Share this data with co-workers and management
    • Don’t get tricked into clicking on rogue links
    • Block rogue links as much as possible
    • Make sure your users know a URL is legitimate before they click, check out this Social Engineering Red Flags Checklist

    Technical Defenses

    • Enable REQUIRED MFA whenever possible
    • Don’t use SMS-based MFA whenever possible
    • Use “1:1” MFA solutions, which require client-side to be pre-registered with the server
    • Use/required two-way, mutual, authentication whenever possible (ex. FIDO U2F’s Channel or Token Binding)
    • Does your MFA solution specifically fight session token theft and/or malicious replays? (i.e., replay resistant)
    • Can your MFA vendor’s support help be socially engineered?
    • Make sure MFA vendors use secure development lifecycle (SDL) in their programming
    • Make sure MFA has “bad attempt throttling” or “account lockout” enabled
    • Spread factors across different “channels” or “bands” (in-band/out-band)
    • Protect and audit identity attributes used by MFA for unique identification of MFA logins
    • Don’t answer password reset questions using honest answers
    • Encourage and use sites and services that use dynamic authentication, where additional factors are requested for higher risk circumstances
    • Understand the risks of “shared secret” systems
    • For transaction-based authentication, need to send user all critical details out-of-band before confirmation is transmitted/required

    ...and remember

    • MFA isn't unhackable.
    • MFA does not prevent phishing or social engineering from being successful.
    • MFA is good. Everyone should use it when they can, but it isn't unbreakable.
    • If you use or consider going to MFA, security awareness training has still got to be a big part of your overall security defense.

    MFA Resources

    Webinars19

    12 Ways to Defeat Multi-Factor Authentication Webinar

    Roger A. Grimes, KnowBe4's Data-Driven Defense Evangelist, will explore 12 ways hackers use social engineering to trick your users into revealing sensitive data or enabling malicious code to run. Plus, he'll share a (pre-filmed) hacking demo by KnowBe4's Chief Hacking Officer, Kevin Mitnick.

    Watch the Webinar

    12 Ways MFA EBook

    12+ Ways to Hack Multi-Factor Authentication eBook

    All multi-factor authentication (MFA) mechanisms can be compromised, and in some cases, it's as simple as sending a traditional phishing email. Want to know how to defend against MFA hacks? This eBook covers over a dozen different ways to hack various types of MFA and how to defend against those attacks.

    Get the eBook

    Hacking In The News

    Brand-New: Multi-Factor Authentication Security Assessment Tool Helps Assess Your Organization's MFA Vulnerabilities

    You already know that using multi-factor authentication (MFA) can decrease your cybersecurity risk, and certainly is a much stronger defense compared to using traditional passwords alone. However, did you know that all MFA mechanisms can be hacked, and in...

    Chinese Hackers Target Airbus Suppliers in Quest for Commercial Secrets

    European aerospace giant Airbus has been hit by a series of attacks by hackers targeting its suppliers in search of commercial secrets, sources told AFP, adding they suspected a Chinese link.

    WSJ: "U.S. Targets North Korean Hacking as Rising National-Security Threat"

    Ian Talley and Dustin Volz at the WSJ wrote:


    Get the latest about social engineering

    Subscribe to CyberheistNews

    色老板影院新地址