Mike Wills - The Official (ISC)2 SSCP CBK Reference

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.

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.

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.

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.

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.

NOTEIn 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 error requiring 15 cards to be canceled immediately. After further investigation, the Estonian software was rewritten to compensate for the problem. (For more information, see, for example, https://news.postimees.ee/4236857/id-card-tip-from-czech-scientists.) While the fundamental technology appears sound and the cards practical, you can expect many more vulnerabilities and alarms in the future as these hardware-based devices, impossible to perfect and resistant (in their current forms) to patching, proliferate in number and increase in importance in our careers and in our everyday life.

Security tokens such as key fobs are small electronic devices that can be used as part of physical facilities access control or as part of a user login and authentication process. The simplest form of such a token or key fob uses NFC readers to detect the presence of the fob and validate its use as part of granting access through external or internal doors. The provisioning process can tailor the access privileges for each fob for the individual user—for example, allowing guests to freely enter or exit through some doors, but not through others, and only during business hours plus or minus a small margin.