- Two-factor authentication
Two-factor authentication (TFA, T-FA or 2FA) is an approach to authentication which requires the presentation of two different kinds of evidence that someone is who they say they are. It is a part of the broader family of multi-factor authentication, which is a defense in depth approach to security. From a security perspective, the idea is to use evidences which have separate range of attack vectors (e.g. logical, physical) leading to more complex attack scenario and consequently, lower risk.
Two-factor authentication is commonly found in electronic computer authentication, where basic authentication is the process of a requesting entity presenting some evidence of its identity to a second entity. Two-factor authentication seeks to decrease the probability that the requestor is presenting false evidence of its identity. The number of factors is important as it implies a higher probability that the bearer of the identity evidence indeed holds that identity in another realm (i.e.: computer system vs real life). In reality 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 implies the use of two independent means of evidence to assert an entity, rather than two iterations of the same means. "Something one knows", "something one has", and "something one is" are useful simple summaries of three independent factors. In detail, these factors are:
- what the requestor individually knows as a secret, such as a password or a Personal Identification Number (PIN)
- what the requesting owner uniquely has, such as a passport, physical token, or ID-card
- what the requesting bearer individually is, such as biometric data, like a fingerprint or face geometry
It is generally accepted that any independent two of these authentication methods (e.g. password + value from a physical token) is two-factor authentication. The accepting identity may use these facts (among other criteria) as a truth upon which to grant or deny the requestor's access to a sensitive data set or physical area. The requestor may be a person or computer system agent acting on behalf of a person.
Another independent means that is starting to be used more frequently in computer systems is "how one behaves", although it is more often used as a decision point for transactions or to de-authenticate an entity than to establish initial truth of identity as behaviour can vary for many different valid reasons. A common example is where an out of character credit card transaction is taken as an indication of possible fraudulent use, casting doubt on the validity of the authentication (by PIN or whatever). Limitations on valid logon times could be regarded as another example; a logon attempt at 8pm by a 9am - 5pm worker is not the expected behaviour and can be rejected on that basis. A quite different type of "how one behaves" is how one writes one's signature (a very old form of authentication), or possibly even how one types on a keyboard in terms of subtle inter-character timings which might be characteristic of a particular user. However, these are much more akin to a biometric and should properly be classed, like biometrics, as "something one is".
Particularly when incorporating behavioural, and to a lesser extent biometric factors, the authentication process is best viewed not so much as a go/no-go decision point, but as a process whereby confidence is built in the supplicant's assertion of his identity. This should take evidence into account both for and against that assertion, and conclude only when the evidence reaches a predetermined confidence level, either for or against the assertion.
Improvement with two factor authentication
Two-factor authentication is not a new concept. Two-factor authentication has been used throughout history by having a known person utter a password. The first factor is the password, and the second would often be the presentation and demeanour of the requestor as reasonable given the circumstances of his arrival. When a bank customer visits a local ATM, one authentication factor is the physical ATM card the customer slides into the machine. The second factor is the PIN they enter. Without one of these, authentication cannot take place. This scenario illustrates the basic parts of most two-factor authentication systems; the "something you have" + "something you know" concept.
Qualified authentication factors
An authentication factor is a piece of information and synonymic for the process used to authenticate or verify the identity of a person or other entity requesting access under security constraints. Two-factor authentication (TFA) or (2FA) is a system wherein two different factors are used in conjunction to authentication. Using two factors as opposed to one factor generally delivers a higher level of authentication assurance. Two-factor authentication typically is a signing-on process where a person proves his or her identity with two of the three methods: "something you know" (e.g., password or PIN), "something you have" (e.g., smartcard or token), or "something you are" (e.g., fingerprint or iris scan).
Using more than one factor is sometimes called "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 you have' or 'something you are', it would not be considered multi-factor. The FFIEC 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."
Details for authentication in 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.
According to proponents, TFA 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 TFA approaches remain vulnerable to trojan controlled websites and man in the middle attacks.
Something you Have
"Something you have" has 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 "something you have" authentication in computer systems.
There are 4 ways of attacking such a system:
- You could attack the authenticator or a management system to try to determine the secret. In the case of a lock and key, the lock is normally designed to make this difficult. In a computer system, it might in principle be possible, for example through SQL injection.
- You could steal the "something you have"; in the case of a lock and key, you could steal the key. Hopefully, the rightful owner will notice the loss and promptly change the lock.
- Given the opportunity, you may be able to copy the "something you have", and return it before the owner notices its loss. An attacker may be able to take an impression of a physical key to make a duplicate, and in the case of computer systems, he may be able to copy the "something you have".
- A man-in-the-middle attack may be possible if the attacker can insert himself in the communication channel and masquerade as the authenticator and the party seeking authentication and vice versa.
The security of the system therefore relies on the integrity of the authenticator and physical protection of the "something you have". Copy protection of the "something you have" is a bonus. This may comprise some form of physical tamper resistance or tamper-proofing, may use a challenge/response to prove knowledge of the shared secret to avoid disclosure, and 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. A challenge/response will not defeat a man-in-the-middle attack on the current authentication session but will prevent the attacker from successfully reusing or replaying credentials on his own.
Many commercial and a few non-commercial solutions are available for providing the "something you have" as described in the following sections. The system designer must consider various trade-offs, such as between costs of deployment and support, usability and user acceptance, and hardware and software requirements. Physical tokens may authenticate themselves by electronic means (e.g. a USB port) or may 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 may be required which the system designer may or may not be able to rely on if he has 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 "something you have".
Tokens with a display (Disconnected Tokens)
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 3 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, the most well known being the RSA SecurID token, widely used in the government and financial sectors, and Vasco tokens of various sorts, used by Paypal and various banks 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 (.79mm to .84mm) 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.
In a corporate or enterprise environment where the user access device and its capabilities are known, a token with an electronic interface may be more convenient as there is no need to read and type a pass code from the device. The form factor of the electronic interface sets a minimum size, however much the electronics can be miniaturised, and end user resistance is not uncommon. Some types require a device reader and maybe special device drivers, whereas others use an interface which is almost universally available such as USB. Even USB, however, may not be available on highly locked-down terminals such as thin clients, pads or kiosk systems.
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 have at least some level of copy protection.
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.
The need for device drivers is sidestepped in the case of the YubiKey, manufactured by Yubico, a device that acts as a USB keyboard and provides secure authentication by a one-time password that is encrypted using the AES encryption algorithm with a 128-bit key. The Yubikey has several modes of operation, and is activated by pressing a button. The device is hardly larger than the USB plug and the button.
Smart cards are about the same size as a credit card. Some vendors offer smart cards that perform both the function of a proximity card 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 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.
As has already been indicated, there are two kinds of smartcard: contact smartcards 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 smartcard reader built in, and PCCard smartcard readers are available which can be kept permanently within the shell of the laptop. Alternatively, USB smartcard readers are available which are no more expensive than many display tokens, in fact, some smartcards 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.
Windows has smartcard authentication functionality built in, allowing authentication against a password and a smartcard with no additional software apart from the smartcard device driver (if needed). This can be configured to screen-lock the computer if the smartcard 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 smartcard each time he leaves the office.
The downside of smart cards is that they are not the smallest form factor although they do fit conveniently in a wallet, and 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 smartcards, and adverse climactic conditions can reduce the reliability of contact smartcards.
Contactless smartcards as described above can be used as a second factor. Other forms of RFID token can be used, as well as Bluetooth.
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.
Although not commonly used as a 2nd factor in general purpose computer systems, it is offered as an option on the highest security versions of the Eclypt  self encrypting hard disk.
Casque  is an unusual hybrid connected token with a display. 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.
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 smartcards. 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 virtually 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. 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.
The functionality of any token that utilizes additional deployed software can be described as a "soft token" on a PC or smartphone, whereupon that device itself becomes the "something you have". 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 most mobile platforms, specifically targets  banking credentials and may forward them to the attacker at a website set up for the purpose, or by SMS messaging. It would be simple for the authors of Zeus or some other malware to target any virtual token which achieved widespread deployment.
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 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.
Virtual tokens are a new concept in multi-factor authentication first introduced in 2005 by the security company Sestus. Virtual tokens transmit one-time-use digitally-signed key and token information using internet-standard http/https delivery methods, reducing the costs normally associated with implementation and maintenance of multi-factor solutions. Virtual tokens utilize the user's existing internet device as the "something the user has" factor and, since the user's internet device is communicating directly with the authenticating website, the solution does not suffer from man-in-the-middle attacks and other forms of online fraud. Virtual tokens are fundamentally different than 'soft (software) tokens'. Unlike soft tokens, virtual tokens deploy no software to the user, thus reducing support requirements and interoperability issues.
Perfect Paper Passwords (PPP)
PPP is an authentication mechanism devised by Steve Gibson and based on a type of one time pad, unencumbered by patents or licence fees. The user is given a printed card (which can be conveniently formatted into a wallet-friendly credit card size) containing an array of pseudo-random numbers generated from a secret seed. To authenticate him/herself, the user is challenged with a row and column from the current sheet of the pad and has to respond with the corresponding pseudo-random number.
The secret seed is protected by a cryptographic process which is used to generate the pseudo-random numbers, but there is nothing to stop a card being stolen or copied. Should this occur, it can be invalidated at the authentication screen and a new (hopefully, uncompromised) card can be used. New cards can be printed out by the user at any time.
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.
A Recent example is Google's 2-step verification option.
Vulnerability to Attacking
Any authentication process which utilizes an out-of-band method such as email data link or phone voice or data link is inherently vulnerable to man-in-the-middle (MITM) attacks. In such MITM attack, 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 would transmit these stolen credentials to the legitimate website using scripts or other protocols and the legitimate website then would initiate a telephone call to the victim. Believing he would be communicating with the legitimate website, the victim would push the appropriate buttons on the phone, not realizing that he would have just permitted the fraudster to complete entry into the victim's account for complete access.
Assignment to the bearer
One basic limitation associated with relying exclusively on mobile phones for authentication is the fact that the respective user must have access to a mobile phone when he wishes to authenticate. The user may have registered the mobile phone number, for example, and when attempting to authenticate from home, there has to be the very same 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.
SMS One Time Password
SMS One time password uses information sent in an SMS to the user as part of the login process. One scenario is where a user either registers (or updates) their contact information on a website. During this time the user is also asked to enter his or her regularly used telephone numbers (home, mobile, work, etc.). The next time the user logs in to the website, they must enter their username and password; if they enter the correct information, the user then chooses the phone number at which they can be contacted immediately from their previously registered phone numbers. The user will be instantly called or receive an SMS text message with a unique, temporary PIN code. The user then enters this code into the website to prove their identity, and if the PIN code entered is correct, the user will be granted access to their account. This process provides an extra layer of online security beyond merely a username and password. These solutions can be used with any telephone, not just mobile devices. As with any out-of-band authentication method, SMS one time password methods are also vulnerable to man-in-the-middle attacks.
The push notification services offered by modern mobile platforms, such as iPhone's APNS and Android's C2DM, 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-authentication 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 such method can simplify deployment, reduce logistical costs, and remove the need for a separate hardware token devices, there are numerous trade-offs.
Users will 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 the holidays. Finally, as with telephone-based processes, these processes are also vulnerable to MITM attacks, such as a victim visiting a counterfeit website where he/she supplies login credentials. The counterfeit website would pass these to the legitimate website using scripts or other protocols. The legitimate website then would initiate an SMS text message delivery of a one-time-password to the victim's mobile device or would simply wait for the Java token value to be generated. The victim would enter the one-time-password onto the counterfeit website, which then could forward this to the legitimate website, where the waiting fraudster may use it to complete their 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.
Something you Are
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 becomes 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. 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 mathematic 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 they 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 biometrics 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 two-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.
Other 2nd Factors
The following methods do not meet the FFIEC's definition of "true multi-factor authentication" as written in published guidelines, and are offered here for explanation only. Organizations or individuals seeking complaint two-factor authentication should follow the FFIEC's definition, which defines multi-factor authentication as combining two or more of the three approved factors, namely: "something the user knows", "something the user has", or "something the user is".
A way you behave
Human behaviour is linked to biometrics but cannot normally be measured in the same way. The way you write a signature is an example which has been used for authentication for centuries, although automatic signature analysis is possible. For a number of years, banks have used patterns of spending as a secondary method of authentication: an unusual purchase may be used to trigger further authentication, fraud investigation, or refusal of the transaction. The rhythm of typing a password has also been suggested, although this may be affected by the type of keyboard or by a sore finger. Generally, then, behaviour is useful for confirming or detracting from confidence in the result of a previous authentication method, rather than as a primary method in itself.
Someone you know
Devising a password reset mechanism for users who have forgotten their passwords is non-trivial. Common methods such as secret questions often considerably weaken the overall authentication system as the answers may be discoverable from public sources or have low entropy. Getting a friend or colleague who knows you and has already been authenticated to the system has been suggested as a solution .
A variation on "something you know" that is resistant to keystroke logging and shoulder surfing, is the ability to use a mask to extract a One Time Password or Code. This is claimed as a second factor but strictly does not of itself qualify under the definition given in the introduction as it is not a second independent typed of factor but rather "something else you know". The method was patented by Swivel Secure Limited in 2000. One implementation of this is PINsafe. Masking can be used in conjunction with "something else you know" or in combination with a token - thus negating the security risk associated with device theft or borrowing typically associated with token devices or SMS delivered passwords or codes.
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 are 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.
Regulators have repeatedly cautioned against the use of approaches that operate through the solicitation of personal information. On Jun 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."
There are drawbacks to two-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.
As a result, adding a second factor to the authentication process typically leads to increase in costs for implementation and maintenance. Most hardware token-based systems are proprietary and charge an annual fee per user in the $50–100 USD range. 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, two-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. Virtual tokens and geo-locations were reported to have the lowest support costs.
As a result of challenges with integration and user acceptance, true two-factor authentication is not yet widespread, although it can be found in certain sectors requiring additional security (e.g. banking, military). Faced with regulatory two-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 published by the Credit Union Journal and co-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.
An increasing count of recent undesired disclosure of governmentally protected data   or private data   is likely to contribute to new TF-A requirements, especially in the European Union.
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.
User password management
Users have natural problems retaining a single authentication factor like a password. It is not uncommon for users to be expected to remember dozens of unique passwords. TFA where one factor is a password or PIN code, does not eliminate this problem. One possible solution is to have the second factor be a biometric or a virtual token number that the user does not need to remember, instead of an entity that the user needs to memorize.
Interoperability of authentication mechanisms
Two-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 is a further argument that purports that there is nothing to stop a user (or intruder) from manually providing logon credentials that are stored on a token or smart card. For example to show all passwords stored in Internet Explorer, all an intruder has to do is to boot the Microsoft Windows OS into safe mode (with network support) and to scan the hard drive (using certain freely available utilities). However, making it necessary for the physical token to be in place at all times during a session can negate this.
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.
Traditional hardware tokens, SMS, and telephone-based methods are vulnerable to a type of attack known as the man-in-the-middle, or MITM attack (see above). In such an attack the fraudster impersonates the bank to the customer and vice versa, prompting the victim to divulge to them the value generated by their token. This means they do not need to be in physical possession of the hardware token or telephone device to compromise the victim's account, but only have to pass the disclosed value on to the genuine website within the time limit. 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 authorise a transfer of a different sum to a different recipient than intended.
Market segments in regards to two-factor authentication are:
- Common authentication
- Identity management
- Mobile Signatures
- Mutual authentication
- One-time password
- Security token
- ^ a b "Frequently Asked Questions on FFIEC Guidance on Authentication in an Internet Banking Environment", August 15, 2006
- ^ US Security Directive as issued on August 12, 2007
- ^ The Failure of Two-Factor Authentication (Bruce Schneier, March 2005)
- ^ Google. "2-step verification". google. http://www.google.com/support/accounts/bin/topic.py?hl=en&topic=28786. Retrieved 3 June 2011.
- ^ Espacenet patent search: Embedded synchronous random disposable code identification method and system, September 7, 2000
- ^ PINsafe review by PCPro
- ^ Combining masking with tokenised mobile phones
- ^ The Identity Lifecycle, Part 1 (Brent Williams, 2010)
- 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)
- 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)
- PHP full implementation (LGPL) of a token grid authentication, including generation and authentication.
- Banks to Use Two-factor Authentication by End of 2006, (slashdot.org, 20 Oct 2005)
- How to add two-factor authentication to Freeradius
- An informative website produced by Xiring explaining how TFA with smart cards works in the banking industry
- Article on authenticating users in a cloud environment
- Recent Patent conferred for strong, multifactor authentication in conjunction with device registration capability
Wikimedia Foundation. 2010.