|This article is part of a series on|
|Related security categories|
- knowledge factors ("things only the user knows"), such as passwords
- possession factors ("things only the user has"), such as ATM cards
- inherence factors ("things only the user is"), such as biometrics
Requiring more than one independent factor increases the difficulty of providing false credentials.
- 1 Background
- 2 Knowledge factors
- 3 Possession factors
- 3.1 Disconnected tokens
- 3.2 Connected tokens
- 3.3 Magnetic stripe cards
- 3.4 Smart cards
- 3.5 Wireless
- 3.6 USB tokens
- 3.7 Audio port tokens
- 3.8 Other form factors
- 3.9 Soft tokens
- 3.10 SMS one-time password
- 3.11 Mobile phones
- 3.12 Missed Calls
- 4 Inherence factors
- 5 Regulation
- 6 Security
- 7 Implementation considerations
- 8 Adoption
- 9 Examples
- 10 See also
- 11 References
- 12 External links
The number and independency of factors is important, since more independent factors imply higher probabilities that the bearer of the identity evidence indeed holds that identity in another realm (e.g., computer system vs real life). However, there are more variables to consider when establishing the relative assurance of truthfulness in an identity assertion than simply how "many factors" are used.
Two-factor authentication is often confused with other forms of authentication. Two-factor authentication requires the use of two of the three independent authentication factors. Each of the independent factors are identified in the standards and regulations for access to U.S. Federal Government systems.
Multi-factor authentication is not a new concept, having been used throughout history. When a bank customer visits a local automated teller machine (ATM), one authentication factor is the physical ATM card the customer slides into the machine ("something the user has"). The second factor is the PIN the customer enters through the keypad ("something the user knows"). Without the corroborating verification of both of these factors, authentication does not succeed. This scenario illustrates the basic concept of most multi-factor authentication systems: the combination of a knowledge factor and a possession factor.
Multi-factor authentication is sometimes confused with "strong authentication", however, "strong authentication" and "multi-factor authentication" are fundamentally different processes. Soliciting multiple answers to challenge questions may be considered strong authentication but, unless the process also retrieves "something the user has" or "something the user is", it would not be considered multi-factor authentication. The U.S. Federal Financial Institutions Examination Council issued supplemental guidance on this subject in August 2006, in which they clarified, "By definition true multifactor authentication requires the use of solutions from two or more of the three categories of factors. Using multiple solutions from the same category ... would not constitute multifactor authentication."
Knowledge factors ("something only the user knows") 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.
A personal identification number (PIN) is a secret numeric password and is typically used in ATMs. Credit and ATM cards do not contain the PIN or CVV on the magnetic stripe. This aligns with the principle that the PIN is not part of "something the user has" for this use.
Secret questions such as "Where were you born?", which an authenticating entity arranges ahead of time with the user, are also a knowledge factor.
Possession factors ("something 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.
There are several ways of attacking such a system, including:
- An attacker can determine the shared secret, for example by attacking the authenticator or a management system, reverse-engineering the possession factor, or intercepting the secret during authentication. In the case of a lock and key, the lock can be picked. In an inadequately secured computer system, for example, a database containing the shared secrets can be attacked through SQL injection.
- An attacker can steal the possession factor. In the case of a lock and key, the attacker can steal the key and use it before the rightful owner notices the loss and has the lock changed. In the case of a computer system, the attacker can steal the possession and use it before the rightful owner notices and has the device cancelled.
- An attacker can copy the possession factor while it is inadequately safeguarded. An attacker can take an impression of a physical key and make a duplicate; and in the case of computer systems, can clone the possession factor.
- The attacker can intercept the authentication process and masquerade as the authenticator to the party seeking authentication and vice versa, in a man-in-the-middle attack. In the case of the lock and key, the attacker can interpose a dummy lock that will allow them to make a copy of the key then later use the copy in the real lock. In the case of a computer system, the attacker can for example interpose a counterfeit authentication interface to intercept the communications and relay the authentication information between the legitimate user and the real authenticator.
- The attacker can hijack access after authentication. In the case of a lock and key, the attacker can wait until the owner of a key has opened the lock, and then gain access to the locked facility. In the case of a computer system, the attacker can for example use man-in-the-browser malware, session fixation, or sidejacking to gain access to a secured facility as soon as a legitimate user has logged in.
The security of the system therefore relies on the integrity of the authenticator and physical protection of the possession factor. Copy protection of the possession factor is a bonus. This may comprise some form of physical tamper resistance or tamper-proofing that may use a challenge/response to prove knowledge of the shared secret whilst avoiding risk of disclosure, and it may involve the use of a pin or password associated with the device itself, independent of any password that might have been demanded as a first factor. While a challenge/response would not defeat a man-in-the-middle attack on the current authentication session, it would prevent the attacker from successfully reusing or replaying credentials.
Many commercial and a few non-commercial solutions are available for providing the possession factor, as described in the following sections. The system designer must consider various trade-offs, such as between costs of deployment and support, usability, user acceptance, and hardware and software requirements. Physical tokens might authenticate themselves by electronic means (e.g., a USB port) or might display a number on a screen, derived from the shared secret and which the user has to type in. In the former case, device drivers might be required which the system designer may or may not be able to rely on if he had no control over the client device (as in the case of authentication to a public website). A one-time pad (such as PPP, described later) is a little different but can still be classed as a possession factor.
A number of types of pocket-sized authentication token are available which display a changing passcode on an LCD or e-ink display, which must be typed in at an authentication screen, thus avoiding the need for an electronic connection. The number is derived from the shared secret by a cryptographic process which makes it infeasible to work out the secret from the sequence of numbers. Essentially, the secret is hashed or otherwise cryptographically combined with a challenge, and the result is displayed. The same process repeated on the authentication server will yield the same result if the correct secret was used. The challenge can take one of three forms:
- In a "sequence-based" token, the token may have a button that is pressed to switch it on and display a new pass code. The cumulative number of button pushes can be used as the challenge. The server, however, must assume that the button may have been pressed a number of times since the last actual use, and attempt the authentication with all likely numbers of button pushes.
- In a "time-based" token, the token generally contains a quartz time source, allowing the absolute time to be used as the challenge and a new pass code to be displayed (usually) every 30 or 60 seconds. In this case, the authentication server must allow for a drift in the time source by trying the authentication with a previous and subsequent time as well as the current time. It can hence keep track of the drift in the clock.
- The token may have a small keypad on which a challenge can be entered. This may either be a fixed PIN assigned to the user, or a challenge generated by the server and displayed at the authentication screen, or both.
Most such tokens have at least a basic level of copy protection in that it would take a certain level, perhaps a high level, of sophistication to extract the secret from the chip on which it is stored.
Display tokens have the advantage that no drivers or electronic interfaces are required on the user access device. Often, it is possible to arrange for the pass code from the display to be appended to a password in an existing password field, so that the only modifications required are in the authentication server. A disadvantage in some sectors is that the display is usually small, and may be difficult to read for visually impaired users.
There are several manufacturers of display tokens used to authenticate online transactions. These are generally designed as a keyfob to be attached to a key ring or lanyard, or as a device that can conveniently be carried in a pocket or handbag.
Recently, it has become possible to take the electronic components associated with regular keyfob tokens and embed them in a credit card form factor. However, because card thickness (0.79 mm to 0.84 mm) prevents traditional components or batteries from being employed, special polymer-based batteries must be used which have a much lower battery life than their traditional coin cell brothers, and an e-ink rather than LCD display is generally used. Additionally, low-power semiconductor components are necessary to conserve the power used during sleep and/or actual use of the product.
Like display tokens, connected tokens embody a shared secret (either a long number or in some cases an X.509 certificate). This is normally interrogated by a challenge/response to avoid exposing it. Most types of connected tokens have at least some level of copy protection. For electronic tokens that require a physical connection (as opposed to wireless), the form-factor of the electronic interface used to connect the token to the machine (card-reader for magstripes and smartcards, USB port, audio port) sets a minimum size for the token. Because the necessary electronics are miniaturised, end-user resistance to carrying around authentication-tokens based on their size, bulk, or weight is uncommon (ATM cards and driver's licenses are the most common examples). Some types of tokens require a device-reader, possibly with special device drivers, whereas others use an interface which is almost universally available such as USB. Even USB-based tokens, however, may not be available on highly locked-down terminals such as thin clients or kiosk systems.
In a business or government environment, where the details of the user-access-device (connected-token hardware) and its capabilities are known, and any required device drivers are deployed in advance, an authentication-token may be more convenient than a pin or a passphrase, as there is no need to type a passcode. When such a token replaces a password, one type of single-factor authentication (knowledge-based) has been replaced with another (possession-based). This is distinct from multi-factor authentication, where more than one mode of authentication is required, such as requiring both an authentication-token, plus a password or PIN. Adding token-based authentication to a password-based authentication system monotonically improves overall security, but reduces overall convenience, and increases overall maintenance and replacement costs. Replacing passwords with tokens can improve overall security, but can also reduce overall security, depending on the defenses against specific threats relevant to the authentication scheme in question (passwords can be compromised by keyloggers, the adversary seeing a written version, the user telling their password to someone else ... passwords can be denied if the user forgets the password or if the user/adversary enters too many wrong passwords inducing lockout and/or ruins the keys used for password-entry ... tokens can be compromised by being stolen/lost, by being cloned, or by the user giving their token to someone else ... tokens can be denied if the user loses them or the user/adversary ruins the token and/or token-reader). Replacement of a compromised or lost physical token is considerably less convenient (hardware and software) than replacement of a compromised or forgotten password (software only).
Because passwords are supported by multiuser operating systems which finally became ubiquitous between by circa 2005, and because connected-tokens are used commercially as a convenient single-factor possession-based replacement for single-factor knowledge-based passwords—although ironically replacement of a lost token is significantly more inconvenient than resetting of a lost password—many multi-factor authentication systems rely on passwords as one factor, and connected tokens as another factor. This is a classic model used by ATMs, which rely on possession of a magstripe card, plus knowledge of a PIN for large transactions (or at some petrol pumps a zip code). In a certain sense, most business and governmental facilities have always used a kind of multi-factor authentication system. In order to login to the computer (since the 1970s for mainframe-class hardware or since the 1990s for microcomputers as used in enterprises), one must have the password... but in order to access the computer in the first place, one must also have a magstripe card (or a door key) to gain entry to the building and/or the office. Traditionally, this type of only-authorized-personnel-get-in-the-door followed later by enter-your-personal-password-to-login security is not treated as true multi-factor authentication, because in the usual case, more than one person is permitted by the first type authentication (any employee can get in the door), whereas the second type of authentication is specific to a particular person (only the individual employee knows their personal password). In small businesses, the line becomes even fuzzier: getting in the door is usually governed by whether the secretary lets you pass (rather than by possession of a magstripe card), and computers may use a single company-wide password (or have the password written on a sticky-note in plain sight). This article deals with the traditional academic subject of multi-factor authentication, where access to a particular device is governed by logically simultaneous multi-factor authentication to the device by a single person (rather than logically distinct actions that are significantly separated both temporally and spatially). In plain terms, if in order to login to a computer the employee must swipe an employee-specific magstripe card through a cardreader affixed to the keyboard, and then enter their passphrase via that keyboard, then the computer in question requires multi-factor authentication. If instead, the employee swipes a company-wide magstripe to get into the door of the building, goes up the unsecured elevator, goes through the unlocked door to their office, and enters their employee-specific password to login, then the computer is traditionally said not to have multi-factor authentication, in terms of analyzing the computer's security. Analyzing overall security is a fuzzier question; in particular, if the employee has a private office, with a locked door to which only they have the key, and inside their computer requires a password only they know, a security analysis of the computer's overall defenses might consider it to be a multi-factor security system, or might not, depending on the analyst.
Magnetic stripe cards
Magnetic stripe cards (credit cards, debit cards, ATM cards, loyalty cards, gift cards, etc.) are easily cloned and so are being or have been replaced in various regions by smart cards, particularly in banking. However, even though the data on the magnetic stripe is easily copied, researchers at Washington University in St. Louis have found that the random and unique disposition of the billions of individual magnetic particles on each magnetic stripe can be used to derive a "magnetic fingerprint" which is difficult, but not impossible to clone. This is an example of a physically unclonable function. Special magnetic card readers have been developed and commercialised under the name "Magneprint", which can digitise this fingerprint in order to positively identify an individual card.
An advantage of this system is that a magnetic fingerprint already exists on every magnetic stripe card, being an intrinsic characteristic, and so no cards would need to be re-issued in order to upgrade an existing system. Each swipe of the card provides a correlative number called a dynamic digital identifier that can be scored and "matched" to the originating value to determine the cards authenticity. Since the number changes each time, it cannot be re-used as long as all processing is authenticated. It does require a special reader that can read the magnetic fingerprint value, but these readers can be swapped out incrementally as old readers wear down. So the actual investment could be incorporated as an incremental increase (due to licensing, increased equipment complexity, etc.) of current business cost expectations.
Smart cards are the same size as a credit card. Some vendors offer smart cards that perform both the function of a proximity card physical access device and network authentication. Users can authenticate into the building via proximity detection and then insert the card into their PC to produce network logon credentials. In fact, they can be multi-purposed to hold several sets of credentials, as well as electronic purse functionality, for example for use in a staff canteen. They can also serve as ID badges.
In some countries, notably in Europe and Asia, banks and financial institutions have implemented Chip Authentication Program technology which pairs a banking smart card with an independent, unconnected card reader. Using the card, reader and ATM PIN as factors, a one-time password is generated that can then be used in place of passwords. The technology offers some support against transaction alteration by facilitating Transaction Data Signing, where information from the transaction is included in the calculation of the one-time password, but it does not prevent man-in-the-middle attacks or man-in-the-browser (MitB) attacks because a fraudster who is in control of the user's internet or is redirecting the user to the legitimate website via a hostile proxy may alter the transaction data "in-line" before it arrives at the web-server for processing, resulting in an otherwise valid transaction signature being generated for fraudulent data.
There are two kinds of smart card: contact smart cards with a pattern of gold plated contacts, and contactless or proximity cards, with an RFID chip embedded within the plastic. The former are more often used in banking and as a 2nd factor, and can be conveniently carried with other credit/debit/loyalty cards in a wallet. They are normally loaded with an X.509 certificate. However, they do need a special reader. Some laptops and thin client terminals have a smart card reader built in, and PCCard smart card readers are available which can be kept permanently within the shell of the laptop. Alternatively, USB smart card readers are available which are no more expensive than many display tokens, in fact, some smart cards have an interface which is electrically (but not mechanically) USB, so that the reader needs no intelligence whatsoever and consequently can be very cheap. Even so, it is less convenient than a built-in or PCCard reader, but is a good option for a desktop computer.
MS Windows has smart card authentication functionality built in, allowing authentication against a password and a smart card with no additional software apart from the smart card device driver (if needed). This can be configured to screen-lock the computer if the smart card is withdrawn. If the card also has a contactless chip used for physical access control, the user will be forced to lock his screen by withdrawing his smart card each time he leaves the office.
There have also been smart cards released over the last five years which employ a combination of an embedded 2FA token inside a credit card form factor. These "powered" smart cards typically consist of:
- An ISO compliant credit card (ID-1) size
- A flexible display
- A switch-on button.
- An embedded non rechargeable battery.
When the button is pressed, the card displays an OTP value, which is then typed by the user on his PC keyboard. On the remote application side, the OTP number is checked using the authentication server. The OTP number is calculated according to the OATH industry standard and using some secret data securely stored in the device.
Another concern when deploying smart cards, USB tokens, or other TFA systems is the security of the software loaded on to users' computers. A token may store a user's credentials securely, but the potential for breaking the system is then shifted to the software interface between the hardware token and the OS, potentially rendering the added security of the TFA system useless.
The downsides of smart cards include that they are not the smallest form factor (although they do fit conveniently in a wallet) and that the card reader is an extra expense. Another disadvantage is that they are less robust than most other forms of token. Repeated flexing can damage both contact and contactless smart cards, and adverse climatic conditions can reduce the reliability of contact smart cards.
RFID-based tokens exist in wide variation of products, mainly designed as identity tags According to ISO/IEC 18000-x standards. Bluetooth-based tokens exist as a non ISO-standardised token since the version 4.0 (low energy) of the Bluetooth standard and offering respective chip designs. Contactless tokens similar to smart cards exist according to the ISO NFC standards (ISO 14443, ISO 15693, ISO 18000-3 and ISO 18092) and other standards created by the NFC forum.
A USB port is standard equipment on today's computers, and USB tokens generally have a large storage capacity for logon credentials, and perhaps user data as well. However, they may be relatively costly to deploy and support, are vulnerable to theft and fraud, and have met user resistance. Any USB memory device can be used as a token simply by storing a secret (possibly an X.509 certificate) on it, but then there is nothing to stop it from being copied. This can be prevented if the device is designed to present itself as an authentication device responding to a challenge/response protocol rather than as a storage device. The downside is that a special device driver may then be required.
Audio port tokens
Audio port tokens are usually used to provide authentication service for mobile terminals, because many different mobile manufacturers have various own interface, such as idock, micro USB, and mini USB. In contrast the audio port is the most standard port on today's smart mobile terminals, and the audio port can be used for data transfer between authentication tokens and mobile terminals instead of USB port. An audio port token usually has a built-in batteries as a power supply for the tokens. It has almost same function as the USB tokens except mobile terminal support, which is a digital certificate container with on-board encrypt/decrypt and sign/verify function.
Other form factors
Although not commonly used as a second factor in general purpose computer systems, iButtons are offered as an option on the highest security versions of the Eclypt self encrypting hard disk. The Dallas iButton resembles a rather large button cell, with a very robust stainless steel case. It uses the Dallas 1-wire interface in which both power and bidirectional signalling utilise a single connection (together with a ground connection). It only has to be touched momentarily on a receptacle for the host device to read or interrogate it and so has found use particularly in conjunction with retail cash registers, allowing a sales assistant to instantly identify him/herself to the cash register.
CASQUE is an unusual hybrid connected token with a display. It incorporates a secure chip rated at EAL5+. It has an LCD display on the front and several photodiodes on the back, which are held up against several flashing squares displayed on the log-in screen. A challenge is communicated to the token by the pattern of flashing. This is then combined with a shared secret stored within the token to produce a pass code which is shown on the LCD display, for the user to type in. An advantage is that the challenge is based neither on a time nor a sequence, and so synchronisation is not an issue. The challenge/response protocol also allows the Token's keys to be changed so resisting Token cloning attempts. The system also allows the User to ask for a specified phrase to be echoed on the Token allowing the User to authenticate the Host and so deny Phishing attempts. CASQUE token's keys are distributed and are dynamically created so denying successful insider attacks. The latest version is "CASQUE SNR" and it has a version, CASQUE SNR HMG, certified for UK Government use by CESG, the UK Government National Authority for Information Assurance. CASQUE SNR is also a NATO approved product. CASQUE SNR has recently produced a token in the form of a smart card that communicates NFC to a mobile phone. This combination can use the mobile phone as the client itself or use a third party Laptop or Tablet as the client.
The functionality of any disconnected token can be emulated as a soft token on a PC or smartphone using deployed software, whereupon that device itself becomes the possession factor. This saves on deployment costs, but against that, the secret is vulnerable to any attacker or malware that can gain full access to the device. The Zeus Trojan, which can now infect mobile devices running Android or BlackBerry OS, specifically targets banking credentials and may forward them to the attacker at a website set up for the purpose, or by SMS messaging.
The secret may comprise an SSL client certificate which can be used to authenticate the device (PC or smartphone) on which it is stored, and may be used directly to authenticate the client in an SSL connection. Whilst stored on the device, even if held in a password protected certificate store, it is still potentially vulnerable to theft by malware as the certificate store has to be unlocked to be used. Indeed, the malware might trick the user into revealing the password or steal it by keystroke logging.
Such client certificates can be stored more securely in the Trusted Platform Module (TPM) chip, fitted to many modern laptops. This is tamper-resistant and requires a password or passphrase to unlock it, and contains a cryptographic processor capable of challenge/response processing without divulging the secret.
SMS one-time password
In the SMS password method, the user receives a random, one-time password ("OTP") over SMS or automated voice call to a number previously registered with the service. The OTP can be used instead of or in addition to the static password and in most services it is composed of 6 random digits for better accessibility. Some banks would require the OTP just before executing security-critical steps, such as ordering a money transfer.
SMS one-time password (OTP) methods may be vulnerable to Man-in-the-mobile or Man-in-the-middle attacks. In the first case, malware infects user's mobile and captures the one-time passwords for the use by attacker. In the latter case user is tricked into entering the one-time code on a fake website, which captures the code for the same purpose. The first malware to actually implement the Man-in-the-mobile attacks against OTP in 2010 was Zeus botnet.
An alternative approach to OTP used primarily in Finland, is to assign a pseudo-random reply number from a pool of numbers to the communication and authenticate the user entirely out of band using that reply address along with the originating customer number and reply options within the body of the message to authenticate the user. This approach minimizes vulnerability to MITM attacks by asking the user to verify the transaction details within the body of the text message as well as on-line: if they don't match, the user can see plainly that there is a MITM attack in progress and reject the transaction. It's important to note that any SMS solution may be vulnerable to mobile number porting attacks. In this scenario, an attacker tricks a mobile provider into transferring a victim's mobile number to a new account under the attacker's control. Any SMS messages or calls sent to the victim's mobile number will instead be sent only to the attacker. The victim may be unaware of the attack until the victim notices their cell phone is no longer working, or is no longer assigned the same mobile number.
There is presently only limited discussion on using wired phones for authentication; most applications focus on use of mobile phones instead.
A new category of TFA tools transforms the PC user's mobile phone into a token device using SMS messaging, an interactive telephone call, or via downloadable application to a smartphone. Since the user now communicates over two channels, the mobile phone becomes a two-factor, two-channel authentication mechanism. Newer solutions making use of secret photographs to block phishing introduce a third layer of security, two-way (e.g.: mutual) authentication, or later still is the ability to use a QR code scanned by a smartphone as your two-factor authentication, such as the HOTPin system.
Another new category of TFA method is using missed calls as One time Password. The user's device will receive a missed call from a random number where the last five digits of the number from where the user receives the missed call is treated as the One Time Password(OTP).This method is usually used in mobile application development where the operating system automatically read the incoming call and treat the last five digits as One time password [OTP]. Example for the missed calls based 2FA is Cognalys services
Assignment to the bearer
One basic limitation associated with relying exclusively on mobile phones for secondary authentication is the fact that the respective user must have access to a mobile phone during authentication. The user may have registered a mobile phone number, for example, and when attempting to authenticate from home, must have access to that registered mobile phone. That converts the mobile phone from an office appliance to a personal appliance for usage out of the premises. However, as soon as the mobile phone gets lost, the bearer loses physical control over the mobile authentication factors.
The push notification services offered by modern mobile platforms, such as iPhone's APNS and Android's C2DM/GCM, can be used to provide a real-time challenge/response mechanism on a mobile device. Upon performing a sensitive transaction or login, the user will instantly receive a challenge pushed to their mobile phone, be prompted with the full details of that transaction, and be able to respond to approve or deny that transaction by simply pressing a button on their mobile phone. Smartphone push two-factor authentication has the capability to not only be more user-friendly, but also more secure as a mutually-authenticated connection can be established to the phone over the data network.
Additional phone token
There is a newer method of using the mobile phone as the processor and having the Security Token reside on the mobile as a Java ME client. This method does not include data latency or incur hidden costs for the end user. While this method can simplify deployment, reduce logistical costs, and remove the need for a separate hardware token devices, there are numerous trade-offs.
Users incur fees for text/data services or cellular calling minutes. In addition, there is a variable latency involved with SMS services, especially during peak SMS usage periods like holidays. Finally, as with telephone-based processes, these processes are also vulnerable to MITM attacks, such as a victim unwittingly supplying login credentials to a counterfeit website. The counterfeit website passes these to the legitimate website using scripts or other protocols. The legitimate website then initiates an SMS text message delivery of a one-time-password to the victim's mobile device or simply waits for the Java token value to be generated. The victim enters the one-time-password onto the counterfeit website, which then forwards this to the legitimate website, where the waiting fraudster uses it to complete the fraudulent access.
Mobile signatures are digital signatures created on a SIM card securely on a mobile device by a user's private key. In such a system text to be signed is securely sent to the SIM card on a mobile phone. The SIM then displays the text to the end-user who checks it before entering a PIN code to create a signature which is then sent back to the service provider. The signature can be verified using standard PKI systems.
Mobile Signature systems have been in use for several years. However, as with magnetic card and client digital certificate solutions, they are vulnerable to malware, are costly to deploy and support, and are strongly resisted by consumers.
Smart phones and tablets can use a dedicated mobile device application for secure access to online services. The mobile device application uses the Web browser or Web service capabilities of the device for authentication and subsequent access to the service. This approach allows a cryptographic key to be used to authenticate the user, which protects against a man-in-the-middle attack. Examples of this are Google Authenticator and Authy.
Inherence factors are "something only the user is".
Biometric authentication also satisfies the regulatory definition of true multi-factor authentication. Users may biometrically authenticate via their fingerprint, voiceprint, or iris scan using provided hardware and then enter a PIN or password in order to open the credential vault. However, while this type of authentication is suitable in limited applications, this solution may become unacceptably slow and comparatively expensive when a large number of users are involved. In addition, it is extremely vulnerable to a replay attack: once the biometric information is compromised, it may easily be replayed unless the reader is completely secure and guarded. Voice biometrics has the distinct advantage that it can ask the user to say random phrases, and thereby significantly reduce the risk of a successful replay attack. Finally, there is great user resistance to biometric authentication. Users resist having their personal physical characteristics captured and recorded for authentication purposes. In short, selection and successful deployment of a biometric authentication system needs careful consideration of many factors.
For many biometric identifiers, the actual biometric information is rendered into string or mathematical information. The device scans the physical characteristic, extracts critical information, and then stores the result as a string of data. Comparison is therefore made between two data strings, and if there is sufficient commonality a pass is achieved. It may be appreciated that choice of how much data to match, and to what degree of accuracy, governs the accuracy/speed ratio of the biometric device. All biometric devices, therefore, do not provide unambiguous guarantees of identity, but rather probabilities, and all may provide false positive and negative outputs. If a biometric system is applied to a large number of users (perhaps all of the customers of a bank) the error rate may make the system impractical to use.
Biometric information may be mechanically copied and cannot be easily changed. This is perceived as a key disadvantage since, if discovered, the compromised data cannot be changed. A user can easily change his/her password, however, a user cannot change their fingerprint. A bio-identifier can also be faked. For example, fingerprints can be captured on sticky tape and false gelatine copies made, or simple photos of eye retinas can be presented. More expensive biometric sensors should be capable to distinguish between live original and dead replicas, but such devices are not practical for mass distribution. It is likely that, as biometric identifiers become widespread, more sophisticated compromise techniques will also be developed.
Historically, fingerprints have been used as the most authoritative method of authentication. Other biometric methods such as retinal scans are promising, but have shown themselves to be easily spoofable in practice. Hybrid or multi-tiered authentication methods offer a compelling solution, such as private keys encrypted by fingerprint inside of a USB device.
A criticism of biometrics for authentication is that whereas it is relatively easy to calculate the strength of a password from its length and composition and hence the time to brute force it, the strength of a biometric is difficult to quantify. There can be no guarantee that a simple attack could not be devised tomorrow, for example by using household chemicals to make an artificial finger from a fingerprint, good enough to be accepted by a fingerprint reader. This is a concern to certain government security authorities where knowing the strength of a security mechanism is considered more important than having a mechanism which might be stronger but whose absolute strength is not quantifiable.
International travelers to many countries are now routinely required to provide fingerprint and/or iris scans to pass. This stockpile of records reduces the strength of biometric-protected resources.
||The examples and perspective in this section deal primarily with the United States and do not represent a worldwide view of the subject. (October 2014)|
Details for authentication in the USA are defined with the Homeland Security Presidential Directive 12 (HSPD-12).
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.
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 and when accessing any computer using a privileged login.
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. 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 guidelines—which 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.
On June 22, 2011, the FFIEC published additional guidance recommending the use of "complex device identification". As described by the FFIEC in this guidance, complex device identification employs methods that do not easily permit the fraudster to "impersonate the legitimate customer". The FFIEC guidelines describe "one time" cookies based on the customer's underlying device fingerprint elements, as the preferred method of deploying "complex device identification".
- "Simple device identification as described above can be distinguished from a more sophisticated form of this technique which uses "one-time" cookies and creates a more complex digital "fingerprint" by looking at a number of characteristics including PC configuration, Internet protocol address, geo-location, and other factors." (Supplement to Authentication in an Internet Banking Environment, Page 6)
As explained by the FFIEC, there is a fundamental difference between "simple device identification" and "complex device identification". Simple device identification utilizes elements that can be easily replicated by the fraudster, such as device information such as the victim's IP address or geo-location. Identifying the IP, browser, and operating system elements does not constitute complex device identification because these elements can, and are, easily detected and "impersonated" by fraudsters. However, when these elements are incorporated into a one-time use cookie, the authentication of this "one time" cookie against these fingerprint elements constitutes a "complex device identification" process not easily impersonated by fraudsters.
Following the U.S. Federal Financial Institutions Examination Council's (FFIEC) publication advising the use of multi-factor authentication, numerous vendors began offering authentication solutions that are not compliant with the FFIEC's definition of "true multifactor authentication". Most notable of these approaches is the challenge/response approach, often coupled with a shared secret image. Soliciting personal information in response to challenge questions simply solicits more of "something the user knows", similar to a login, a password, or a PIN. All are multiple solutions from the same authentication category. Unless these are combined with one of the other two factors, i.e., "something the user has" or "something the user is," it does not constitute multi-factor authentication.
Regulators have repeatedly cautioned against the use of approaches that operate through the solicitation of personal information. On June 17, 2005, the U.S. Federal Deposit Insurance Corporation (FDIC) published supplement guidelines in which it strongly cautioned financial organizations against adopting authentication methods that use personal information for authentication purposes:
"Although consumers are worried about phishing and the trustworthiness of e-mail messages from their banks, they are also concerned about the security of their personal information more generally....When banks consider authentication methods for retail customers, they should be aware that these customers value security and the protection of confidential information... Consumers will require a clear explanation of any security mechanism and the use of any personal information required to implement that security mechanism....limitations on the use of personal information and the existence of privacy safeguards are important elements of consumer acceptance....Consumers are also concerned about the risk associated with large databases of personal information and the potential for the information that is used by authentication methods to be compromised, copied, or imitated. - FDIC"
The FFIEC clarified their position in their August 15, 2006 FAQ Supplement, rejecting such approaches outright:
"By definition true multifactor authentication requires the use of solutions from two or more of the three categories of factors. Using multiple solutions from the same category ... would not constitute multifactor authentication. - FFIEC"
In September 2009, an Illinois district court issued a ruling allowing a couple to sue Citizens Financial Bank alleging that the bank failed to sufficiently secure their account with adequate multi-factor authentication security. (see Wired article) The judge in the case pointed to the FFIEC's guidelines and ruled,
"In light of Citizens’ apparent delay in complying with FFIEC security standards, a reasonable finder of fact could conclude that the bank breached its duty to protect Plaintiffs’ account against fraudulent access."
According to proponents, MFA 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 MFA approaches remain vulnerable to Phishing, man-in-the-browser and man-in-the-middle attacks.
In addition to such direct attacks, three aspects must be considered for each of the factors in order to fully realize the potential increase in confidence of authentication:
- The inherent strength of the mechanism, i.e. the entropy of a secret, the resistance of a token to cloning, or the uniqueness and reliability of a biometric.
- Quality of provision and management. This has many aspects, such as the confidence one can have that a token or password has been securely delivered to the correct user and not an imposter, or that the correct individual has been biometrically enrolled, as well as secure storage and transmission of shared secrets, procedures for password reset, disabling a lost token, re-enrollment of a biometric, and prompt withdrawal of credentials when access is no longer required.
- Proactive fraud detection, e.g. monitoring of failed authentication attempts or unusual patterns of behavior which may indicate that an attack is under way, and suitable follow-up action.
Any authentication process which utilizes an Out-of-band method is inherently vulnerable to classic man-in-the-middle (MITM) attacks. Traditional hardware tokens, SMS, and telephone-based methods are vulnerable to MITM attacks because they are physically disconnected from the authenticating entity. In such an attack a fraudster impersonates a bank or similar authenticating entity to the customer, prompting the victim to divulge to them the value generated by their token or other authentication process. The fraudster then passes this (valid) authentication factor to the genuine bank or similar authenticating entity instead of the user. The fraudster does not need to be in physical possession of the hardware token, SMS device, or telephone to compromise the victim's account. They only need to solicit the authentication information and then pass it on to the genuine website within the appropriate time frame. Citibank made headline news in 2006 when its hardware token-equipped business customers were targeted by just such an attack from fraudsters based in the Ukraine. Such an attack may be used to gain information about the victim’s accounts, or to get them to authorize a transfer of a different sum to a different recipient than intended.
MITM terminology can apply to scenarios where the adversary is merely an eavesdropper on the data being transferred (sending a password over unencrypted IM ... or sending a credit card through the mail with the PIN in the same envelope ... are modern examples of this scenario, but the classic example is unencrypted radio communications between military units which are spied on by the enemy. In a common modern variation on the classic man-in-the-middle attack pattern, a fraudster is actually interacting with the legitimate website, and the victim is interacting with the fraudster's counterfeit website. A victim who is lured to a fraudulent website then triggers the attack by entering the normal login credentials on the counterfeit website. The counterfeit website then transmits these stolen credentials to the legitimate website using scripts or other protocols and the legitimate website then initiates a telephone call to the victim. Believing the website to be legitimate, the victim pushes the appropriate buttons on the phone, or transmits the telephoned codes to the fraudster, not realizing that doing so permits the fraudster to complete entry into the victim's account for complete access.
Many TF-A products require users to deploy client software to make TFA 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 TF-A solutions, such as "virtual" tokens and some hardware token products, no software must be installed by end users.
Multi-factor authentication is not standardized. There are various implementations of it. Therefore, interoperability is an issue. There exist many processes and facets to consider in choosing, developing, testing, implementing and maintaining an end-to-end secure identity management system, inclusive of all relevant authentication mechanisms and their technologies: this context is considered the "Identity Lifecycle".
There are drawbacks to multi-factor authentication that are keeping many approaches from becoming widespread. Some consumers have difficulty keeping track of a hardware token or USB plug. Many consumers 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 even 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 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.
Market segments in regards to multi-factor authentication are:
As a result of challenges with integration and user acceptance, true multi-factor authentication is not yet widespread, although it can be found in certain sectors requiring additional security (e.g. banking, military). Faced with regulatory multi-factor authentication guidelines in 2005, numerous U.S. financial institutions instead deployed additional knowledge-based authentication methods, such as shared secrets or challenge questions, only to discover later that such methods do not satisfy the regulatory definition of "true multifactor authentication". Supplemental regulatory guidelines and stricter enforcement are now beginning to force the abandonment of knowledge-based methods in favor of "true multifactor authentication".
A 2007 study sponsored by BearingPoint reported 94% of the authentication solutions implemented by U.S. financial institutions fail to meet the regulatory definition of true multi-factor authentication.
Several popular web services employ multi-factor authentication, usually as an optional feature that is deactivated by default.
Some Web services using multi-factor authentication include:
- "Frequently Asked Questions on FFIEC Guidance on Authentication in an Internet Banking Environment", August 15, 2006
- Mostarda, Leonardo; Dulay, Naranker; Dong, Changyu. "Place and Time Authentication of Cultural Assets". Retrieved 13 June 2014.
- "Fundamentals of Information Systems Security/Access Control Systems". Wikibooks. Retrieved 13 June 2014.
- "Information technology -- Identification cards -- Financial transaction cards". ISO/IEC 7813:2006.
- RSA SecurID Breach Is a Lesson in APTs (Fahmida Y. Rashid, March 29, 2011)
- Lockpicking and the Internet (Bruce Schneier, August 10, 2009)
- Citibank Phish Spoofs 2-Factor Authentication (Brian Krebs, July 10, 2006)
- "Magneprint technology licensed to TRAX Systems, Inc. | Washington University in St. Louis". News.wustl.edu. 2004-11-11. Retrieved 2012-11-07.
- [dead link]
- Angela Moscaritolo (2011-07-12). "Zeus for Android steals one-time banking passwords". SC Magazine. Retrieved 2012-11-07.
- Safa Hamdare, Varsha Nagpurkar, Jayashri Mittal (2014). "Securing SMS Based One Time Password Technique from Man in the Middle Attack". International Journal of Engineering Trends and Technology. Retrieved 2014-11-06.
- David Barroso (2010). "ZeuS Mitmo: Man-in-the-mobile". S21sec. Retrieved 2014-11-06.
- US Patent Office US7406429
- "Microsoft Case Study: Payment provider increases security and cuts costs with text message confirmation Solution" http://www.microsoft.com/casestudies/Microsoft-Dynamics-CRM/Luottokunta/Payments-Provider-Increases-Security-and-Cuts-Costs-with-Text-Confirmation-Solution/4000009316[dead link]
- Winterford, Brett (December 6, 2011). "$45k stolen in phone porting scam". SC Magazine.
- "CryptoPhoto Authentication". The Australian. December 3, 2011. Retrieved 8 March 2012.
- SafeSigner. "SafeSigner, transaction verification and Signing". SafeSigner. Retrieved 10 June 2014.
- Biometrics for Identification and Authentication - Advice on Product Selection
- US Security Directive as issued on August 12, 2007
- "SANS Institute, Critical Control 10: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches".
- "SANS Institute, Critical Control 12: Controlled Use of Administrative Privileges".
- "Electronic Authentication Guide". Special Publication 800-63-2. NIST. 2013. Retrieved 2014-11-06.
- FFIEC (2006-08-15). "Frequently Asked Questions on FFIEC Guidance on Authentication in an Internet Banking Environment". Retrieved 2012-01-14.
- The Failure of Two-Factor Authentication (Bruce Schneier, March 2005)
- The Identity Lifecycle, Part 1 (Brent Williams, 2010)
- Walsh, Conal (September 4, 2006). "New data theft scandal rocks subcontinent's call centres". The Guardian (London).
- "U.K. seeks Interpol's help in data-theft scandal". MSNBC. 2005-06-24. Retrieved 2012-11-07.
- de Quetteville, Harry (August 20, 2008). "Germany outraged by data theft scandal". The Daily Telegraph (London).
- "Mobile Telephones and Data Theft". Aboutidentitytheft.co.uk. 2012-10-18. Retrieved 2012-11-07.
- GORDON, WHITSON (3 September 2012). "Two-Factor Authentication: The Big List Of Everywhere You Should Enable It Right Now". LifeHacker (Australia). Retrieved 1 November 2012.
- "AWS Multi-Factor Authentication FAQs". Amazon Web Services. Retrieved 1 November 2012.
- DAVID GALLOWAY; ANGUS KIDMAN (27 August 2012). "How To Use Dropbox Two-Step Verification". LifeHacker (Australia). Retrieved 1 November 2012.
- "What are login approvals? How do I turn this setting on?". Facebook. 2012. Retrieved 1 November 2012.
- "Protect your Facebook Account with Two Factor Authentication". AuthShield. 2014-02-18. Retrieved 2014-09-12.
- "How it works". Google. Retrieved 1 November 2012.
- "Google Authenticator". Google. Retrieved 1 November 2012.
- Cliff_N. "Two Factor Authentication (TFA): What is a Microsoft account Security Code?". Microsoft account, Hotmail, SkyDrive. Microsoft. Retrieved 1 November 2012.
- "PayPal Security Key". Paypal. Retrieved 1 November 2012.
- Jason Petkov (22 May 2013). "Locking down Twitter, 2 Step Authentication". W3Reports (United States). Retrieved 22 May 2013.
- "Twitter Updated Its Two Factor Authentication for Android and iOS". AuthShield. 2014-02-18. Retrieved 2014-09-12.
- Attackers breached the servers of RSA and stole information that could be used to compromise the security of two-factor authentication tokens used by 40 million employees (register.com, 18 Mar 2011)
- Banks to Use Two-factor Authentication by End of 2006, (slashdot.org, 20 Oct 2005)
- List of commonly used websites and whether or not they support Two-Factor Authentication
- Microsoft to abandon passwords, Microsoft preparing to dump passwords in favour of two-factor authentication in forthcoming versions of Windows (vnunet.com, 14 Mar 2005)
- Why is two factor authentication needed for your corporate assets