Multi-factor authentication

Multi-factor authentication is an authentication method in which a computer user is granted access only after successfully presenting two or more pieces of evidence (or factors) to an authentication mechanism: knowledge (something the user and only the user knows), possession (something the user and only the user has), and inherence (something the user and only the user is).[1]

Two-factor authentication (also known as 2FA) is a type, or subset, of multi-factor authentication. It is a method of confirming users' claimed identities by using a combination of two different factors: 1) something they know, 2) something they have, or 3) something they are.

A good example of two-factor authentication is the withdrawing of money from an ATM; only the correct combination of a bank card (something the user possesses) and a PIN (something the user knows) allows the transaction to be carried out.

Two other examples are to supplement a user-controlled password with a one-time password (OTP) or code generated or received by an authenticator (e.g. a security token or smartphone) that only the user possesses.

Two-step verification or two-step authentication is a method of confirming a user's claimed identity by using something they know (password) and a second factor other than something they have or something they are. An example of a second step is the user repeating back something that was sent to them through an out-of-band mechanism (such as a code sent over SMS), or a number generated by an app that is common to the user and the authentication system.[2]

Authentication factors

The use of multiple authentication factors to prove one's identity is based on the premise that an unauthorized actor is unlikely to be able to supply the factors required for access. If, in an authentication attempt, at least one of the components is missing or supplied incorrectly, the user's identity is not established with sufficient certainty and access to the asset (e.g., a building, or data) being protected by multi-factor authentication then remains blocked. The authentication factors of a multi-factor authentication scheme may include:

Something you have
Some physical object in the possession of the user, such as a USB stick with a secret token, a bank card, a key, etc.
Something you know
Certain knowledge only known to the user, such as a password, PIN, TAN, etc.
Something you are
Some physical characteristic of the user (biometrics), such as a fingerprint, eye iris, voice, typing speed, pattern in key press intervals, etc.
Somewhere you are
Some connection to a specific computing network or using a GPS signal to identify the location.[3]

Knowledge factors

Knowledge factors are the most commonly used form of authentication. In this form, the user is required to prove knowledge of a secret in order to authenticate.

A password is a secret word or string of characters that is used for user authentication. This is the most commonly used mechanism of authentication. Many multi-factor authentication techniques rely on password as one factor of authentication. Variations include both longer ones formed from multiple words (a passphrase) and the shorter, purely numeric, personal identification number (PIN) commonly used for ATM access. Traditionally, passwords are expected to be memorized.

Many secret questions such as "Where were you born?" are poor examples of a knowledge factor because they may be known to a wide group of people, or be able to be researched.

Possession factors

Possession factors ("something the user and only the user has") have been used for authentication for centuries, in the form of a key to a lock. The basic principle is that the key embodies a secret which is shared between the lock and the key, and the same principle underlies possession factor authentication in computer systems. A security token is an example of a possession factor.

Disconnected tokens

RSA SecurID token, an example of a disconnected token generator

Disconnected tokens have no connections to the client computer. They typically use a built-in screen to display the generated authentication data, which is manually typed in by the user.[4]

Connected tokens

Connected tokens are devices that are physically connected to the computer to be used. Those devices transmit data automatically.[5] There are a number of different types, including card readers, wireless tags and USB tokens.[5]

Software tokens

A software token (a.k.a. soft token) is a type of two-factor authentication security device that may be used to authorize the use of computer services. Software tokens are stored on a general-purpose electronic device such as a desktop computer, laptop, PDA, or mobile phone and can be duplicated. (Contrast hardware tokens, where the credentials are stored on a dedicated hardware device and therefore cannot be duplicated, absent physical invasion of the device.) A soft token may not be a device the user interacts with. Typically an X.509v3 certificate is loaded onto the device and stored securely to serve this purpose.

Inherent factors

These are factors associated with the user, and are usually biometric methods, including fingerprint, face, voice, or iris recognition. Behavioral biometrics such as keystroke dynamics can also be used.

Location based factors

Increasingly, a fourth factor is coming into play involving the physical location of the user. While hard wired to the corporate network, a user could be allowed to login using only a pin code while off the network entering a code from a soft token as well could be required. This could be seen as an acceptable standard where access into the office is controlled.

Systems for network admission control work in similar ways where your level of network access can be contingent on the specific network your device is connected to, such as wifi vs wired connectivity. This also allows a user to move between offices and dynamically receive the same level of network access in each.

Use of mobile phones

Many multi-factor authentication vendors offer mobile phone-based authentication. Some methods include push-based authentication, QR code based authentication, one-time password authentication (event-based and time-based), and SMS-based verification. SMS-based verification suffers from some security concerns. Phones can be cloned, apps can run on several phones and cell-phone maintenance personnel can read SMS texts. Not least, cell phones can be compromised in general, meaning the phone is no longer something only the user has.

The major drawback of authentication including something the user possesses is that the user must carry around the physical token (the USB stick, the bank card, the key or similar), practically at all times. Loss and theft are risks. Many organizations forbid carrying USB and electronic devices in or out of premises owing to malware and data theft-risks, and most important machines do not have USB ports for the same reason. Physical tokens usually do not scale, typically requiring a new token for each new account and system. Procuring and subsequently replacing tokens of this kind involves costs. In addition, there are inherent conflicts and unavoidable trade-offs between usability and security.[6]

Two-step authentication involving mobile phones and smartphones provides an alternative to dedicated physical devices. To authenticate, people can use their personal access codes to the device (i.e. something that only the individual user knows) plus a one-time-valid, dynamic passcode, typically consisting of 4 to 6 digits. The passcode can be sent to their mobile device by SMS or can be generated by a one-time passcode-generator app. In both cases, the advantage of using a mobile phone is that there is no need for an additional dedicated token, as users tend to carry their mobile devices around at all times.

As of 2018, SMS is the most broadly-adopted multi-factor authentication method for consumer-facing accounts. Notwithstanding the popularity of SMS verification, security advocates have publicly criticized it[7] and in July 2016 a United States NIST draft guideline proposed deprecating it as a form of authentication.[8] A year later NIST reinstated SMS verification as a valid authentication channel in the finalized guideline.[9]

In 2016 and 2017 respectively, both Google and Apple started offering user two-step authentication with push notification as an alternative method.[10][11]

Security of mobile-delivered security tokens fully depends on the mobile operator's operational security and can be easily breached by wiretapping or SIM cloning by national security agencies.[12]

Advantages

  • No additional tokens are necessary because it uses mobile devices that are (usually) carried all the time.
  • As they are constantly changed, dynamically generated passcodes are safer to use than fixed (static) log-in information.
  • Depending on the solution, passcodes that have been used are automatically replaced in order to ensure that a valid code is always available, transmission/reception problems do not therefore prevent logins.

Disadvantages

  • Users may still be susceptible to phishing attacks. An attacker can send a text message that links to a spoofed website that looks identical to the actual website. The attacker can then get the authentication code, user name and password.[13]
  • A mobile phone is not always available—they can be lost, stolen, have a dead battery, or otherwise not work.
  • Mobile phone reception is not always available—large areas, particularly outside of towns, lack coverage.
  • SIM cloning gives hackers access to mobile phone connections. Social-engineering attacks against mobile-operator companies have resulted in the handing over of duplicate SIM cards to criminals.[14]
  • Text messages to mobile phones using SMS are insecure and can be intercepted by IMSI-catchers. Thus third parties can steal and use the token.[15]
  • Account recovery typically bypasses mobile-phone two-factor authentication.[16]
  • Modern smartphones are used both for receiving email and SMS. So if the phone is lost or stolen and is not protected by a password or biometric, all accounts for which the email is the key can be hacked as the phone can receive the second factor.
  • Mobile carriers may charge the user for messaging fees.

Advances in mobile two-factor authentication

Advances in research of two-factor authentication for mobile devices consider different methods in which a second factor can be implemented while not posing a hindrance to the user. With the continued use and improvements in the accuracy of mobile hardware such as GPS,[17] microphone,[18] and gyro/acceleromoter,[19] the ability to use them as a second factor of authentication is becoming more trustworthy. For example, by recording the ambient noise of the user's location from a mobile device and comparing it with the recording of the ambient noise from the computer in the same room in which the user is trying to authenticate, one is able to have an effective second factor of authentication.[20] This also reduces the amount of time and effort needed to complete the process.

Legislation and regulation

The Payment Card Industry (PCI) Data Security Standard, requirement 8.3, requires the use of MFA for all remote network access that originates from outside the network to a Card Data Environment (CDE).[21] Beginning with PCI-DSS version 3.2, the use of MFA is required for all administrative access to the CDE, even if the user is within a trusted network.[22]

European Union

The second Payment Services Directive requires "strong customer authentication" on most electronic payments in the European Economic Area since September 14, 2019.

India

In India, the Reserve Bank of India mandated two-factor authentication for all online transactions made using a debit or credit card using either a password or a one-time password sent over SMS. This was temporarily withdrawn in 2016 for transactions up to ₹2,000 in the wake of the November 2016 banknote demonetisation. Vendors such as Uber have been pulled up by the central bank for allowing transactions to take place without two-factor authentication.[23][24]

United States

Details for authentication for Federal Employees and Contractors in the USA are defined with the Homeland Security Presidential Directive 12 (HSPD-12).[25]

Existing authentication methodologies involve the explained three types of basic "factors". Authentication methods that depend on more than one factor are more difficult to compromise than single-factor methods.[26]

IT regulatory standards for access to Federal Government systems require the use of multi-factor authentication to access sensitive IT resources, for example when logging on to network devices to perform administrative tasks[27] and when accessing any computer using a privileged login.[28]

NIST Special Publication 800-63-3 discusses various forms of two-factor authentication and provides guidance on using them in business processes requiring different levels of assurance.[29]

In 2005, the United States' Federal Financial Institutions Examination Council issued guidance for financial institutions recommending financial institutions conduct risk-based assessments, evaluate customer awareness programs, and develop security measures to reliably authenticate customers remotely accessing online financial services, officially recommending the use of authentication methods that depend on more than one factor (specifically, what a user knows, has, and is) to determine the user's identity.[30] In response to the publication, numerous authentication vendors began improperly promoting challenge-questions, secret images, and other knowledge-based methods as "multi-factor" authentication. Due to the resulting confusion and widespread adoption of such methods, on August 15, 2006, the FFIEC published supplemental guidelineswhich states that by definition, a "true" multi-factor authentication system must use distinct instances of the three factors of authentication it had defined, and not just use multiple instances of a single factor.[31]

Security

According to proponents, multi-factor authentication could drastically reduce the incidence of online identity theft and other online fraud, because the victim's password would no longer be enough to give a thief permanent access to their information. However, many multi-factor authentication approaches remain vulnerable to phishing,[32] man-in-the-browser, and man-in-the-middle attacks.[33]

Multi-factor authentication may be ineffective against modern threats, like ATM skimming, phishing, and malware.[34]

In May 2017 O2 Telefónica, a German mobile service provider, confirmed that cybercriminals had exploited SS7 vulnerabilities to bypass SMS based two-step authentication to do unauthorized withdrawals from users bank accounts. The criminals first infected the account holder's computers in an attempt to steal their bank account credentials and phone numbers. Then the attackers purchased access to a fake telecom provider and set-up a redirect for the victim's phone number to a handset controlled by them. Finally the attackers logged into victims' online bank accounts and requested for the money on the accounts to be withdrawn to accounts owned by the criminals. SMS passcodes were routed to phone numbers controlled by the attackers and the criminals transferred the money out.[35]

Implementation considerations

Many multi-factor authentication products require users to deploy client software to make multi-factor authentication systems work. Some vendors have created separate installation packages for network login, Web access credentials and VPN connection credentials. For such products, there may be four or five different software packages to push down to the client PC in order to make use of the token or smart card. This translates to four or five packages on which version control has to be performed, and four or five packages to check for conflicts with business applications. If access can be operated using web pages, it is possible to limit the overheads outlined above to a single application. With other multi-factor authentication solutions, such as "virtual" tokens and some hardware token products, no software must be installed by end users.

There are drawbacks to multi-factor authentication that are keeping many approaches from becoming widespread. Some users have difficulty keeping track of a hardware token or USB plug. Many users do not have the technical skills needed to install a client-side software certificate by themselves. Generally, multi-factor solutions require additional investment for implementation and costs for maintenance. Most hardware token-based systems are proprietary and some vendors charge an annual fee per user. Deployment of hardware tokens is logistically challenging. Hardware tokens may get damaged or lost and issuance of tokens in large industries such as banking or even within large enterprises needs to be managed. In addition to deployment costs, multi-factor authentication often carries significant additional support costs. A 2008 survey[36] of over 120 U.S. credit unions by the Credit Union Journal reported on the support costs associated with two-factor authentication. In their report, software certificates and software toolbar approaches were reported to have the highest support costs.

Research into deployments of multi-factor authentication schemes[37] has shown that one of the elements that tends to impact the adoption of such systems is the line of business of the organization that deploys the multi-factor authentication system. Examples cited include the U.S. federal government, which employs an elaborate system of physical tokens (which themselves are backed by robust Public Key Infrastructure), as well as private banks, which tend to prefer multi-factor authentication schemes for their customers that involve more accessible, less expensive means of identity verification, such as an app installed onto a customer-owned smartphone. Despite the variations that exist among available systems that organizations may have to choose from, once a multi-factor authentication system is deployed within an organization, it tends to remain in place, as users invariably acclimate to the presence and use of the system and embrace it over time as a normalized element of their daily process of interaction with their relevant information system.

Controversies

In 2013, Kim Dotcom claimed to have invented two-factor authentication in a 2000 patent,[38] and briefly threatened to sue all the major web services. However, the European Patent Office revoked his patent[39] in light of an earlier 1998 US patent held by AT&T.[40]

Examples

Several popular web services employ multi-factor authentication, usually as an optional feature that is deactivated by default.[41] Many Internet services (among them Google and Amazon AWS) use the open Time-based One-time Password algorithm (TOTP) to support two-step authentication.

gollark: Why are you using `<=` on what are presumably booleans? What?
gollark: And if it's SQLite, it has transactions, so it's fine.
gollark: Well, if it's persistent, then it's obviously SQLite, because yes.
gollark: Æ.
gollark: +<markov

See also

References

  1. "Two-factor authentication: What you need to know (FAQ) – CNET". CNET. Retrieved 2015-10-31.
  2. "Two-Step vs. Two-Factor Authentication - Is there a difference?". Information Security Stack Exchange. Retrieved 2018-11-30.
  3. Seema, Sharma (2005). Location Based Authentication (Thesis). University of New Orleans.
  4. Press, Gil. "141 Cybersecurity Predictions For 2020". Forbes. Retrieved 2019-12-18.
  5. van Tilborg, Henk C.A.; Jajodia, Sushil, eds. (2011). Encyclopedia of Cryptography and Security, Volume 1. Springer Science & Business Media. p. 1305. ISBN 9781441959058.
  6. Anonymous Two-Factor Authentication in Distributed Systems: Certain Goals Are Beyond Attainment (PDF), retrieved 2018-03-23
  7. Andy Greenberg (2016-06-26). "So Hey You Should Stop Using Texts For Two-factor Authentication". Wired. Retrieved 2018-05-12.
  8. "NIST is No Longer Recommending Two-Factor Authentication Using SMS". Schneier on Security. August 3, 2016. Retrieved November 30, 2017.
  9. "Rollback! The United States NIST no longer recommends "Deprecating SMS for 2FA"". July 6, 2017. Retrieved May 21, 2019.
  10. Tung, Liam. "Google prompt: You can now just tap 'yes' or 'no' on iOS, Android to approve Gmail sign-in". ZD Net. ZD Net. Retrieved 11 September 2017.
  11. Chance Miller (2017-02-25). "Apple prompting iOS 10.3". 9to5 Mac. 9to5 Mac. Retrieved 11 September 2017.
  12. "How Russia Works on Intercepting Messaging Apps – bellingcat". bellingcat. 2016-04-30. Archived from the original on 2016-04-30. Retrieved 2016-04-30.
  13. Kan, Michael (7 March 2019). "Google: Phishing Attacks That Can Beat Two-Factor Are on the Rise". PC Mag. Retrieved 9 September 2019.
  14. tweet_btn(), Shaun Nichols in San Francisco 10 Jul 2017 at 23:31. "Two-factor FAIL: Chap gets pwned after 'AT&T falls for hacker tricks'". Retrieved 2017-07-11.
  15. Toorani, Mohsen; Beheshti, A. (2008). "SSMS - A secure SMS messaging protocol for the m-payment systems". 2008 IEEE Symposium on Computers and Communications. pp. 700–705. arXiv:1002.3171. doi:10.1109/ISCC.2008.4625610. ISBN 978-1-4244-2702-4.
  16. Rosenblatt, Seth; Cipriani, Jason (June 15, 2015). "Two-factor authentication: What you need to know (FAQ)". CNET. Retrieved 2016-03-17.
  17. "Location Authentication - Inside GNSS". www.insidegnss.com. Archived from the original on 2018-04-18. Retrieved 2016-07-19.
  18. "Continuous voice authentication for a mobile device".
  19. "DARPA presents: Continuous Mobile Authentication - Behaviosec". 22 October 2013. Archived from the original on 12 June 2018. Retrieved 19 July 2016.
  20. Sound-Proof: Usable Two-Factor Authentication Based on Ambient Sound | USENIX. www.usenix.org. ISBN 9781931971232. Retrieved 2016-02-24.
  21. "Official PCI Security Standards Council Site – Verify PCI Compliance, Download Data Security and Credit Card Security Standards". www.pcisecuritystandards.org. Retrieved 2016-07-25.
  22. "For PCI MFA Is Now Required For Everyone | Centrify Blog". blog.centrify.com. 2016-05-02. Retrieved 2016-07-25.
  23. Agarwal, Surabhi (7 December 2016). "Payment firms applaud RBI's move to waive off two-factor authentication for small value transactions". The Economic Times. Retrieved 28 June 2020.
  24. Nair, Vishwanath (6 December 2016). "RBI eases two-factor authentication for online card transactions up to Rs2,000". Livemint. Retrieved 28 June 2020.
  25. "Homeland Security Presidential Directive 12". Department of Homeland Security. August 1, 2008. Archived from the original on September 16, 2012.
  26. "Frequently Asked Questions on FFIEC Guidance on Authentication in an Internet Banking Environment", August 15, 2006
  27. "SANS Institute, Critical Control 10: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches". Archived from the original on 2013-01-28. Retrieved 2013-02-11.
  28. "SANS Institute, Critical Control 12: Controlled Use of Administrative Privileges". Archived from the original on 2013-01-28. Retrieved 2013-02-11.
  29. "Digital Identity Guidelines". NIST Special Publication 800-63-3. NIST. June 22, 2017. Retrieved February 2, 2018.
  30. "FFIEC Press Release". 2005-10-12. Retrieved 2011-05-13.
  31. FFIEC (2006-08-15). "Frequently Asked Questions on FFIEC Guidance on Authentication in an Internet Banking Environment" (PDF). Retrieved 2012-01-14.
  32. Brian Krebs (July 10, 2006). "Security Fix – Citibank Phish Spoofs 2-Factor Authentication". Washington Post. Retrieved 20 September 2016.
  33. Bruce Schneier (March 2005). "The Failure of Two-Factor Authentication". Schneier on Security. Retrieved 20 September 2016.
  34. "The Failure of Two-Factor Authentication – Schneier on Security". schneier.com. Retrieved 23 October 2015.
  35. Khandelwal, Swati. "Real-World SS7 Attack — Hackers Are Stealing Money From Bank Accounts". The Hacker News. Retrieved 2017-05-05.
  36. "Study Sheds New Light On Costs, Affects Of Multi-Factor".
  37. Libicki, Martin C.; Balkovich, Edward; Jackson, Brian A.; Rudavsky, Rena; Webb, Katharine (2011). "Influences on the Adoption of Multifactor Authentication".
  38. US 6078908, Schmitz, Kim, "Method for authorizing in data transmission systems"
  39. Brodkin, Jon (23 May 2013). "Kim Dotcom claims he invented two-factor authentication—but he wasn't first". Ars Technica. Archived from the original (html) on 9 July 2019. Retrieved 25 July 2019.
  40. US 5708422, Blonder, et al., "Transaction authorization and alert system"
  41. GORDON, WHITSON (3 September 2012). "Two-Factor Authentication: The Big List Of Everywhere You Should Enable It Right Now". LifeHacker. Australia. Archived from the original on 17 January 2018. Retrieved 1 November 2012.

Further reading

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.