Switch language: EN|RU

Thursday, January 28, 2021

Guidelines for services: using convenient multi-factor authentication. Part 1 || Рекомендации сервисам по использованию удобной мультифакторной аутентификации. Часть 1

  





Due to requests of my readers, I'm about to continue the notes with a brief overview of the best practices for convenient authentication in services, set out in a NIST Special Publication 800-63B. Digital Identity Guidelines. Authentication and Lifecycle Management. The previous part was about passwords. Today I'd like to discuss multi-factor authentication (MFA). Part 1. As my colleagues mentioned in the comments, the best practice for password security is... don't use them at all =) (better not just them). More precisely, add a second or third factor that the user will be also associated with, except for the single password. In the MFA paradigm stronger authentication is achieved through a mix of three so-called possession-based concepts:
  1. Something you know
  2. Something you have
  3. Something you are
In the observed document NIST serves recommendations for 7 the most popular types of MFA:
  1. Out-of-Band Devices
  2. Single-Factor OTP Device
  3. Multi-Factor OTP Device
  4. Single-Factor Cryptographic Software
  5. Single-Factor Cryptographic Devices
  6. Multi-Factor Cryptographic Software
  7. Multi-Factor Cryptographic Device
Obviously, it's much more expensive to offer MFA technologies for services (even in the simple case - SMS or mobile app). However, this is much more secure than using a single password and provides additional protection for both the client and the service itself. Let's drill into all of these types and highlight the most valuable points that will help services make security reliable and convenient for users. In this post we'll take a look at types from 1 to 3, and leave the rest (from 4 to 7) for Part 2.

Out-of-Band Devices
Assumes the use of a physical device (the simplest - mobile phone) that is uniquely addressable and can communicate securely with the verifier over a distinct communications channel, referred to as the secondary channel. Implements the concept "something you have". This method can be carried out through the special mobile app (press "confirm", scan QR code, etc.) or just by SMS. The out-of-band authenticator can operate in one of the following ways: the claimant transfers a secret received by the out-of-band device via the secondary channel to the verifier using the primary channel (typically a digit code), the claimant transfers a secret received via the primary channel to the out-of-band device for transmission to the verifier via the secondary channel (e.g., QR code), the claimant compares secrets received from the primary channel and the secondary channel and confirms the authentication via the secondary channel (e.g., confirm/decline). Regardless of them, the following recommendations should be followed:
  1. The out-of-band authenticator shall establish a separate channel with the verifier in order to retrieve the out-of-band secret or authentication request (however, it's allowed to perform it on a single device) 
  2. The out-of-band device should be uniquely addressable and communication over the secondary channel shall be encrypted unless sent via the public switched telephone network (PSTN)
  3. The out-of-band authenticator shall uniquely authenticate itself in one of the following ways when communicating with the verifier: Establish an authenticated protected channel to the verifier using approved cryptography using the key, stored in suitably secure storage (e.g., keychain storage, TPM, TEE, secure element) or Authenticate to a public mobile telephone network using a SIM card or equivalent that uniquely identifies the device
  4. The device should not display the authentication secret while it is locked by the owner 
  5. The authenticator shall present a secret received via the secondary channel from the verifier and prompt the claimant to verify the consistency of that secret with the primary channel, prior to accepting a yes/no response 
  6. The verifier shall not store the identifying key itself, but shall use a verification method (e.g., an approved hash function)
  7. In all cases, the authentication shall be considered invalid if not completed within 10 minutes, then it's allowed to try again
  8. The verifier shall generate random authentication secrets with at least 20 bits of entropy and if the authentication secret has less than 64 bits of entropy, the verifier shall implement a rate-limiting mechanism (nevertheless, it's never superfluous =) )
  9. Use of the PSTN for out-of-band verification is undesirably, but if verifiers use it, it should consider risk indicators such as device swap, SIM change, number porting, or other abnormal behavior before using the PSTN to deliver an out-of-band authentication secret
Single-Factor OTP Device
This category includes hardware devices and software-based OTP generators installed on devices such as mobile phones. OTP implements the concept "something you have". Single-factor OTP devices are similar to look-up secret authenticators with the exception that the secrets are cryptographically and independently generated by the authenticator and verifier and compared by the verifier. The secret is computed based on a nonce that may be time-based or from a counter on the authenticator and verifier. Single-factor OTP authenticators contain two persistent values. The first is a symmetric key that persists for the device’s lifetime. The second is a nonce that is either changed each time the authenticator is used or is based on a real-time clock. When using this type of authentication, the following recommendations should be followed:
  1. The secret key and its algorithm shall provide at least the minimum security strength (112 bits)
  2. The nonce shall be of sufficient length to ensure that it is unique for each operation of the device over its lifetime
  3. OTP authenticators — particularly software-based OTP generators — should discourage and shall not facilitate the cloning of the secret key onto multiple devices
  4. The authenticator output may be truncated to as few as 6 decimal digits (approximately 20 bits of entropy)
  5. Passwords should obviously not be repeated
  6. If the nonce used to generate the authenticator output is based on a real-time clock, the nonce shall be changed at least once every 2 minutes
  7. The symmetric keys used by authenticators are also present in the verifier, and shall be strongly protected against compromise (on both sides - device and verifier) 
  8. The verifier shall use approved encryption and an authenticated protected channel when collecting the OTP in order to provide resistance to eavesdropping and MitM attacks
  9. In order to provide replay resistance, verifiers shall accept a given time-based OTP only once during the validity period
  10. If the authenticator output has less than 64 bits of entropy, the verifier shall implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber’s account
Multi-Factor OTP Device
The main difference from the simple OTP - additional factor, which augments the one-time password generation. The second factor of authentication may be achieved through some kind of integral entry pad, an integral biometric (e.g., fingerprint) reader, or a direct computer interface (e.g., USB port). Implements two concepts at once: "something you have" with "something you know or something you are". The OTP is displayed on the device and manually input for transmission to the verifier. Multi-factor OTP authenticators operate in a similar manner to single-factor OTP authenticators, except that they require the entry of either a memorized secret or the use of a biometric to obtain the OTP from the authenticator. Each use of the authenticator require the input of the additional factor. Certainly for the service this type of MFA looks like an single-factor OTP. All the previous recommendation (Memorized passwords пароли, single-factor OTP) works for multi-factor OTPs. Yet there is a few more pieces of advice:
  1. Any memorized secret used by the authenticator for activation shall be a randomly-chosen numeric secret at least 6 decimal digits in length
  2. A biometric activation factor shall meet the requirements of limits on the number of consecutive authentication failures and other tips (more detailed - in the Part 2)
  3. 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 OTP has been generated
  4. In the event a claimant’s authentication is denied due to duplicate use of an OTP, verifiers may warn the claimant in case an attacker has been able to authenticate in advance
Generally, the analyzed today's recommendations are primarily concerned with security, not really the convenience of the user (as you could see in my post about passwords). Nevertheless, the modern MFA use cases provided by services offer comfort by default. This  essentially reduces several requirements (and thus the risks) of using the strongest, but unmemorable passwords.  

In the MFA. Part 2 I'm going to talk about using secret keys as a MFA in various forms.


Stay on the light side. R.Z.
Posted by at No comments:
Subscribe to: Posts (Atom)