Скачать книгу

be used to deduce both correct and incorrect answers to traditional security questions. Users can, of course, establish incorrect answers for these questions when the account is being provisioned, but those wrong answers still have to be memorable.

      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.

       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

       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

      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

Скачать книгу