Finally, I bring to your attention the latest article with a brief review of the best practices of secure and convenient authentication in services according to NIST Special Publication 800-63B. Digital Identity Guidelines. Authentication and Lifecycle Management. Today I'm going to talk about Multi-factoк authentication (MFA). Part 2. At the very beginnig of this series of articles I told you about How services can make using passwords convenient. In the MFA. Part 1 we discussed the recommendations related to three (out of 7) types of secure and convenient MFAs: Out-of-Band Devices, Single-Factor OTP Device and Multi-Factor OTP Device. Now let's move on to the remaining ones: Single-Factor Cryptographic Software, Single-Factor Cryptographic Devices, Multi-Factor Cryptographic Software and Multi-Factor Cryptographic Device.
Single-Factor Cryptographic Software
Means using a cryptographic key stored on a disk (e.g. file) or some other special "soft" media (the essence is the same). Single-factor software cryptographic authenticators encapsulate one or more secret keys unique to the service. Implements the concept "something you have". It is like a digital signature. In fact anyone who has direct access to the user's device can use it to confirm authentication. Obviously, the key stored on disk as a simple file is not the best solution. However, if this works for you, please follow these guidelines:
- The key shall be stored in suitably secure storage available to the user's application (e.g., keychain storage, TPM, or TEE if available)
- The key shall be strongly protected against unauthorized disclosure by the use of access controls that limit access to the key to only those software components on the device requiring access
- Single-factor cryptographic software authenticators should discourage and shall not facilitate the cloning of the secret key onto multiple devices
- The service has either symmetric or asymmetric cryptographic keys corresponding to each users. While both types of keys shall be protected against modification, symmetric keys shall additionally be protected against unauthorized disclosure
- The challenge nonce shall be at least 64 bits in length, and shall either be unique over the authenticator’s lifetime or statistically unique
Single-Factor Cryptographic Devices
Unlike the previous method, this one means using a hardware device that performs cryptographic operations using protected cryptographic key(s) and provides the user output via direct connection to the user endpoint. The device uses embedded symmetric or asymmetric cryptographic keys, and does not require activation through a second factor of authentication. The authenticator output is provided by direct connection to the user endpoint and operates by signing a challenge nonce presented through a direct computer interface (USB port or something modern like bluetooth). Implements the concept "something you have". The main difference is that the keys are accessed directly on that device. Follow these guidelines:
- Single-factor cryptographic device authenticators encapsulate one or more secret keys unique to the device that shall not be exportable (i.e., cannot be removed from the device)
- Alternatively, the authenticator could be a suitably secure processor integrated with the user endpoint itself (e.g., a hardware TPM)
- The secret key and its algorithm shall provide at least the minimum security length 112 bits
- The challenge nonce shall be at least 64 bits in length
- It's a good practice to use a physical input (e.g., the pressing of a button) in order to operate. This provides defense against unintended operation of the device, which might occur if the endpoint to which it is connected is compromised
- The service has either symmetric or asymmetric cryptographic keys corresponding to each user. While both types of keys shall be protected against modification, symmetric keys shall additionally be protected against unauthorized disclosure
- The challenge nonce shall be at least 64 bits in length, and shall either be unique over the authenticator’s lifetime or statistically unique
Multi-Factor Cryptographic Software
The key difference from simple single-factor cryptographic software is a cryptographic key stored on disk or some other "soft" mediathat requires activation through a second factor of authentication. It can be a PIN, password or biometric data. Authentication is accomplished by proving possession and control of the key. Implements two concepts at once: "something you have" with "something you know or something you are". For the service, there is no difference from simple single-factor cryptographic software, hardening is performed on the user's side. In this case, all the previous recommendations are works, however, here are a few more noteworthy ones:
- The key should be stored in suitably secure storage available to the user's application (e.g., keychain storage, TPM, TEE)
- The key shall be strongly protected against unauthorized disclosure by the use of access controls that limit access to the key to only those software components on the device requiring access
- Multi-factor cryptographic software authenticators should discourage and shall not facilitate the cloning of the secret key onto multiple devices
- Ключ должен содержаться в безопасном хранилище (Keychain, TPM, TEE и т.п.)
- Each authentication operation using the authenticator shall require the input of both factor, whitout exceptions
- Any memorized secret used by the user for activation shall be a randomly-chosen numeric value at least 6 decimal digits in length and the number of attempts shall be rate limited
- A biometric activation factor (in case of its use) shall includes limits on the number of consecutive authentication failures. For more information about biometric guildelines, see Appendix B.
- The unencrypted key and activation secret or biometric sample — and any biometric data derived from the biometric sample such as a probe produced through signal processing — shall be zeroized immediately after an authentication transaction has taken place
Multi-Factor Cryptographic Device
In this case, both key storage and cryptographic operations are performed directly inside the device. These operations use one or more protected cryptographic keys and requires activation through a second authentication factor (e.g. PIN, password, biometrics). Authentication is accomplished by proving possession of the device and control of the key, the authenticator output is provided by direct connection to the user endpoint (laptop, phone, PC). Implements two concepts at once: "something you have" with "something you know or something you are". The basic principles and guidelines are the same as for single-factor cryptographic devices. In fact, the only difference is the need to present something else. Below you'll find additional recommendations:
- Each authentication operation using the authenticator should require the input of the additional factor. Input of the additional factor may be accomplished via either direct input on the device or via a hardware connection (e.g., USB, smartcard)
- The unencrypted key and activation secret or biometric sample — and any biometric data derived from the biometric sample such as a probe produced through signal processing — shall be zeroized immediately after an authentication transaction has taken place
Appendix A. Guidelines for Rate Limiting (Throttling)
It is a good practice for services to implement mechanisms to limit the unseccessful MFA attempts (against guessing attacks and brute force) by default. The main recommendations are to set limit consecutive failed authentication attempts on a single account to no more than 100. Not everything is as simple as it seems. On the other hand, services should reduce the likelihood that an attacker will lock the legitimate claimant out as a result of rate limiting. Such measures may include:
- Requiring the claimant (user) to complete a CAPTCHA before attempting authentication
- Requiring the claimant (user) to wait following a failed attempt for a period of time that increases as the account approaches its maximum allowance for consecutive failed attempts (e.g., 30 seconds up to an hour)
- Accepting only authentication requests that come from a white list of IP addresses from which the subscriber has been successfully authenticated before
- Leveraging other risk-based or adaptive authentication techniques to identify user behavior that falls within, or out of, typical norms. These might, for example, include use of IP address, geolocation, timing of request patterns, or browser metadata
- When the subscriber (user) successfully authenticates, the service should disregard any previous failed attempts for that user from the same IP address
Appendex B. Guidelines for Use of Biometrics
Using biometrics as a second factor (concept "something you are") in authentication includes both measurement of physical characteristics (e.g., fingerprint, iris, facial characteristics) and behavioral characteristics (e.g., typing cadence). The NIST's document provides some concern on the use of biometrics:
- The biometric False Match Rate (FMR) does not provide confidence in the authentication of the subscriber by itself. Biometric comparison is probabilistic, whereas the other authentication factors are deterministic. In addition, FMR does not account for spoofing attacks
- Biometric template protection schemes provide a method for revoking biometric credentials that is comparable to other authentication factors (e.g., PKI certificates and passwords). However, the availability of such solutions is limited, and standards for testing these methods are under development
- Biometric characteristics do not constitute secrets. They can be obtained online or by taking a picture of someone with a camera phone (e.g., facial images) with or without their knowledge, lifted from objects someone touches (e.g., latent fingerprints), or captured with high resolution images (e.g., iris patterns). While presentation attack detection (PAD) technologies (e.g., liveness detection) can mitigate the risk of these types of attacks
If you still decide to use biometrics, then follow these recommendations:
- Biometrics shall be used only as part of multi-factor authentication with a physical authenticator (something you have)
- An authenticated protected channel between sensor (or an endpoint containing a sensor that resists sensor replacement) and verifier shall be established and the sensor or endpoint shall be authenticated prior to capturing the biometric sample from the claimant (user)
- The biometric system shall operate with an FMR (ISO/IEC 2382-37) of 1 in 1000 or better
- The biometric system should implement presentation attack detection (PAD). Testing of the biometric system to be deployed should demonstrate at least 90% resistance to presentation attacks for each relevant attack type (i.e., species)
- The biometric system shall allow no more than 5 consecutive failed authentication attempts or 10 consecutive failed attempts if PAD meeting the above requirements is implemented. Once that limit has been reached, the biometric authenticator shall either (the choice is left to the service):
- impose a delay of at least 30 seconds before the next attempt, increasing exponentially with each successive attempt (e.g., 1 minute before the following failed attempt, 2 minutes before the second following attempt) or
- disable the biometric user authentication and offer another factor (e.g., a different biometric modality or a PIN/Passcode if it is not already a required factor) if such an alternative method is already available
- The service shall make a determination of sensor and endpoint performance, integrity, and authenticity. Acceptable methods for making this determination include, but are not limited to: Authentication of the sensor or endpoin, Certification by an approved accreditation authority and Runtime interrogation of signed metadata
- Biometric comparison can be performed locally on claimant’s device or at a central verifier. Since the potential for attacks on a larger scale is greater at central verifiers, local comparison is preferred. Yet if the comparison performs centrally:
- use of the biometric as an authentication factor shall be limited to one or more specific devices that are identified using approved cryptography. Since the biometric has not yet unlocked the main authentication key, a separate key shall be used for identifying the device
- biometric revocation, referred to as biometric template protection in ISO/IEC 24745, shall be implemented
- all transmission of biometrics shall be over the authenticated protected channel
- Канал от датчика клиента до сервиса должен быть защищен, а доступ к ключу в самом втором факторе (его активация с помощью биометрии) должен быть открыт только после успешной биометрической аутентификации на нем
- False Match Rate (FMR) должен удовлетворять требованиям "1 из 1000" стандарта ISO/IEC 2382-37
- Biometric samples collected in the authentication process may be used to train comparison algorithms or — with user consent — for other research purposes. Biometric samples and any biometric data derived from the biometric sample such as a probe produced through signal processing shall be zeroized immediately after any training or research data has been derived
- Biometrics are also used in some cases to prevent repudiation of enrollment and to verify that the same individual participates in all phases of the enrollment process as described in SP 800-63
To sum up, we can say that the implementation of even modern methods of Multi-Factor authentication has a "right to live" and can be used in the wild to meet the need of both services and users. Following of already issued best practices (thanks to colleagues from NIST), they help to ensure that the basic security controls step-by-step and not to forget essencial features. It's very useful to have that cheat sheet.
The main purpose of this series of posts was to highlight that there are not only strict regulatory security requirements, but also guidelines and best practices for addressing convenience issues. This is important because, as we know, users are the most valuable fort in the struggle against attackers. Convenient security will always be the most effective.
See also: MFA. Part 1, Convenient passwords
Stay on the light side. R.Z.
