Because of this, NIST has dropped security questions from its list of policy recommendations for user authentication. It might be argued that security questions can be used as part of a password reset dialog process; this might make life for your users easier at the risk of making it easier for an attacker to gain access.
NOTE Intelligence information also comes directly from humans (HUMINT), technical sources (TECHINT) such as your own network, and of course rumors (RUMINT). All of these, and more, should play valuable roles in your threat-hunting reconnaissance efforts.
Personal Identification Numbers or Memorable Information
Personal identification numbers are another example of a “what you know” factor in use. Frequently, you see PINs used as a second authentication factor when using a credit card, debit card, or other form of automated teller machine (ATM) card to access banking and financial services. PINs typically are from four to eight digits in length, and as with all factors depending upon human memory, they may be easily deduced using publicly available knowledge about the PIN's legitimate user. It also doesn't take that much machine time to crack a four-digit PIN, or even an eight-digit PIN; the search space is just too small. However, most ATMs and other systems using PINs will set limits on how many times the wrong PIN can be entered before locking the card out of that device.
A variation on the PIN is the use of a user-specified string of memorable information; the access control system then asks the user to provide a few individual characters from this string, rather than the whole value itself. Again, this has all the risks of presenting a very small search space to an attacker and might not actually make things easier for your legitimate users in the process.
Recent Access History
Another technique, often used by banks and financial institutions, is to prompt the user for additional information pertaining to recent activities associated with their user ID or account. Banks might ask about the last five deposits, for example, while an insurance provider might ask for particular information regarding a recent claim that the (purported) user had submitted. Some secure systems also have displayed information regarding the last access attempt (failed or successful) made by the user and then asked for additional information as part of confirmation of the user's authenticity.
Conceptually, this is asking for information that the legitimate user should know, but in practice, it often ends up with the user having to access the systems themselves or their off-board (paper) records of system activity in order to answer the questions correctly.
In any event, use of such information only establishes that the person trying to access the system now already has enjoyed access to it previously, which does not help separate legitimate user access attempts from an attempted identity theft.
Escrow, Recovery, and Reset
Let's face it: Every choice of Type I factor is at risk of being forgotten by a user, and this includes the master password or passphrase for a password manager! There are basically two options available that you as a systems security administrator need to consider as you plan ahead to deal with this human forgetfulness. Both require procedures that ensure that the user asking for recovery of a password in escrow is in fact the user whose identity was proofed and is part of your identity management record-keeping systems.
Password reset: This is merely an immediate action taken by the administrator to require a new password or passphrase at the next user login attempt. Most of us have had far too many experiences with using password reset functions, because of either forgetfulness or system policies about period reset.
Password escrow: This option provides for the storage of an encrypted (not hashed) form of the password in a physically and logically separate space. You also have to pay attention to the choice of encryption used, so as to protect against that key being compromised or lost. Regardless of whether your organization manages this escrow activity or has contracted it out to a password manager and recovery service, password escrow requires a level of trust and confidence at least as great as the most sensitive or confidential information in your systems.
Users will ask about having their password “recovered,” which is tantamount to running your own password cracker on it for them. You'll probably have to explain to them that if the password system is going to do its job of keeping the systems secure, it therefore shouldn't be something that can be easily cracked.
Type II: Something You Have
The second type of authentication factor is “something you have,” meaning a physical object of some kind. Physical keys, passes, and tokens have been used throughout history for this, with each form of pass becoming obsolete, impractical, or both over time. Consider how many hotels have replaced the nonelectronic locks on the doors to guest rooms with electronic locks that read the key cards generated by the front desk when a guest checks in. Physical access control factors provide additional information during the authentication process, information that you would not normally know. For example, a smart card or electronic ID card contains a chip, which contains firmware and data that interact with the authentication process.
Smart Cards
Machine-readable smart cards or digital ID cards have been becoming more commonplace during the last two decades. Much of this was spurred on by the U.S. government, and this drove the creation of NIST guidelines and standards for physical access control systems (PACSs). Standards describing two different cards, the common access card (CAC) and the personal identity verification (PIV), have been developed for their use, and they support high-volume mass production of the blank cards that are then initialized as part of the identity provisioning process by the using organizations. Each card type uses an embedded chip to store digital certificates and information about the identity of the person the card has been issued to, which is then used as part of the access authentication. These cards are not foolproof and can be prone to radio frequency crosstalk that in some cases can render the card inoperable. Within many U.S. government organizations, for example, CACs are used not only for face-to-face verification of identity but as part of access control to computer and communications systems and for entry to restricted or controlled areas. Many private companies use one or the other card as part of their physical access control for data centers or other high-value assets. CAC and PIV cards may be used with magnetic stripe readers, with OCR readers, or in some cases with near-field communications (NFC) RF readers.
NOTE In the United States, Federal Information Processing Standard Publication 201 (FIPS 201, Parts I and II), developed by the National Institute of Standards and Technology, provides current standards and technical details related to using physical access control systems (PACSs) and the associated CAC or PIV cards as part of an authentication system. See https://csrc.nist.gov/publications/detail/fips/201/2/final.
Note that in the European Union's Genera Data Protection Regulation (GDPR), which went into effect in 2018, there are additional requirements about how data can be collected from humans during the identity verification process, how that data can be compared to data in other sources, and what if any of that data can be retained by the data processor without explicit consent of the user.
Because electronic ID cards like the CAC and PIV are intended for mass production and because millions of mass-produced cards make an alluring target for attackers, it is critical for researchers and practitioners alike to keep abreast of vulnerability concerns with these and similar devices. For example, an alarming report by two Czech scientists in 2014 about a “highly theoretical” vulnerability in Estonian CAC ID cards led to an investigation identifying a manufacturing