По просьбам читателей продолжаю цикл заметок с тезисным обзором хороших практик по удобной аутентификации в сервисах, изложенных в рекомендации NIST Special Publication 800-63B. Digital Identity Guidelines. Authentication and Lifecycle Management . Предыдущая заметка была про пароли , сегодня - про мультифакторную аутентификацию (MFA). Часть 1. Как было верно подмечено коллегами, лучшая практика обезопасить пароли - это не использовать их. Точнее, добавить второй и/или третий фактор, который необходимо будет предъявить пользователю при входе помимо логина/пароля. В классической многофакторной модели подтверждение личности достигается благодаря указанию комбинации из трех параметров:
- То, что я знаю (помню)
- То, что у меня есть (физически)
- То, кто я (что-то неотъемлемое от меня)
В обозреваемом документе NIST приводятся рекомендации относительно реализации 7 видов аутентификации, которые можно отнести к MFA:
- Отдельный канал связи до выделенного устройства (Out-of-Band Devices)
- Простой генератор одноразовых паролей (Single-Factor OTP Device)
- Мультифакторный генератор одноразовых паролей (Multi-Factor OTP Device)
- Ключ, хранимый в софте/на диске (Single-Factor Cryptographic Software)
- Ключ, хранимый на подключаемом устройстве (Single-Factor Cryptographic Devices)
- Ключ, хранимый в софте/на диске + другой фактор Multi-Factor Cryptographic Software
- Ключ, хранимый на подключаемом устройстве + другой фактор (Multi-Factor Cryptographic Device)
Безусловно, для сервиса, который предлагает подобные усиленные методы аутентификации весь процесс обходится дороже (даже в самом простом случае - приложение на телефоне или СМС). Однако, это куда более надежно, чем простой пароль и обеспечит дополнительную защиту как для клиента, так и для самого сервиса. Для каждого из типов приведем наиболее интересные советы и рекомендации, которые помогут сервисам сделать безопасность удобной для пользователей. В данной заметке рассмотрим типы 1-3, остальное - оставим на Часть 2.
Отдельный канал связи до выделенного устройства (Out-of-Band Devices)
Предполагает использование физического устройства (самое простое - телефона), верификация с помощью которого осуществляется по иному каналу, нежели ввод логина-пароля в браузере для доступа к сервису. Реализует принцип "то, что у меня есть". Такой метод может быть реализован отправкой смс (или push-уведомления) или необходимостью действий в специальном приложении на телефоне (нажать подтверждение, отсканировать QR-код и т.п.). Методы передачи и получения второго фактора могут быть совершенно разными, чаще всего одни из трех (передача на устройство и последующий ввод в сервисе, отображение в сервисе и последующий ввод на устройстве, отображение и передача одного и того же секрета с необходимостью подтверждения да/нет на устройстве). Не зависимо от них необходимо следовать следующим рекомендациям:
- Канал передачи второго фактора должен быть независим от первого (однако, допускается реализовывать их на одном устройстве)
- Устройство должно однозначно адресоваться, а аутентификационная информация - шифроваться при передаче
- Устройство должно однозначно аутентифицировать себя: либо с помощью зашитого ключа (TPM, TEE и т.п.), либо уникального ID SIM-карты (например, IMSI)
- Секреты не должны отображаться на заблокированном телефоне
- При обратной передаче сервису подтверждения второго фактора необходимо проверять целостность (консистентность) транзакции, чтобы исключить подмену
- Устройство не должно хранить секрет подтверждения второго фактора в открытом виде, для передачи его сервису необходимо применять хэширование
- Ждать подтверждения необходимо не более 10 минут в рамках одной сессии, потом нужно повторить операцию
- Случайные генерируемые секреты должны иметь энтропию как минимум 20 бит, а если она меньше 64 бит, то потребуется дополнительно внедрить защиту от перебора (впрочем, она никогда не бывает лишней)
- Передавать второй фактор через публичные телефонные сети (PSTN) крайне не рекомендуется, но если сервис это делает, то необходимо учитывать риски подмены SIM, перехвата сообщений, подмены портов и т.п.
Простой генератор одноразовых паролей (Single-Factor OTP Device)
Могут быть как отдельными устройствами, так и приложением на телефоне. Реализует принцип "то, что у меня есть". Алгоритм генерации паролей вместе с секретным ключом зашиты в устройство (о них, конечно, знает и сам сервис) и может быть основан на времени, счетчике, специальных словах и т.п. При использовании такого типа аутентификации необходимо придерживаться следующих рекомендации:
- Алгоритм, секретное слово должны удовлетворять минимальным требованиям безопасности (быть по крайней мере 112 бит)
- Алгоритм, секретное слово и другие определяющие одноразовый пароль инструменты должны гарантировать его (пароля) постоянную уникальность
- Устройства должны препятствовать возможности скопировать (клонировать) одноразовый пароль
- Отображаемый на устройстве после всех вычислений одноразовый пароль может быть в итоге сокращен до 6 числовых значений (энтропия примерно 20 бит)
- Пароли, очевидно, не должны повторяться
- Если в качестве входных данных для вычисления одноразового пароля используется текущее время, то оно должно меняться не реже чем раз в 2 минуты
- Симметричные ключи, используемые для генерации одноразовых паролей, необходимо защищать от компрометации как на стороне устройства, так и на стороне сервиса, поскольку очевидно, что они - одни и теже
- При вводе пароля на стороне сервиса должна применяться надежная защита (об этом можно почитать в предыдущей статье про пароли) от компрометации и MitM атак
- OTP устройства должны выдаваться (привязываться) однократно одному пользователю на весь период действия
- При генерации одноразовых паролей энтропию должна составлять как минимум 20 бит, а если она меньше 64 бит, то потребуется дополнительно внедрить защиту от перебора (впрочем, она никогда не бывает лишней)
Мультифакторный генератор одноразовых паролей (Multi-Factor OTP Device)
- Если для активации OTP используется пин-пад, то пин должен состоять из не менее чем 6 цифр
- Если для активации OTP устройства используется биометрия, то должно быть ограничено число попыток и другие меры безопасности (их подробнее рассмотрим в Части 2)
- Ключ, образец биометрии, иной секрет в случае успешной активации OTP должны быть затерты сразу же после завершения второго шага (использование OTP непосредственно по назначению)
- Если сервис заподозрил попытки многократного использования одного и того же значения OTP, он может предупредить пользователя о таких попытках
В целом, рассмотренные сегодня рекомендации касаются больше безопасносности, чем удобства (как было в заметке про пароли). Однако, современные методы применения второго фактора для аутентификации на сервисах уже по-умолчанию предлагают удобство, по сути, даже в некотором роде снижая требования (и риски) использования простых паролей.
Оставайтесь на светлой стороне. R.Z.
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:
- Something you know
- Something you have
- Something you are
In the observed document NIST serves recommendations for 7 the most popular types of MFA:
- Out-of-Band Devices
- Single-Factor OTP Device
- Multi-Factor OTP Device
- Single-Factor Cryptographic Software
- Single-Factor Cryptographic Devices
- Multi-Factor Cryptographic Software
- 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:
- 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)
- 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)
- 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
- The device should not display the authentication secret while it is locked by the owner
- 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
- The verifier shall not store the identifying key itself, but shall use a verification method (e.g., an approved hash function)
- In all cases, the authentication shall be considered invalid if not completed within 10 minutes, then it's allowed to try again
- 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 =) )
- 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:
- The secret key and its algorithm shall provide at least the minimum security strength (112 bits)
- The nonce shall be of sufficient length to ensure that it is unique for each operation of the device over its lifetime
- OTP authenticators — particularly software-based OTP generators — should discourage and shall not facilitate the cloning of the secret key onto multiple devices
- The authenticator output may be truncated to as few as 6 decimal digits (approximately 20 bits of entropy)
- Passwords should obviously not be repeated
- 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
- 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)
- 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
- In order to provide replay resistance, verifiers shall accept a given time-based OTP only once during the validity period
- 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
- Any memorized secret used by the authenticator for activation shall be a randomly-chosen numeric secret at least 6 decimal digits in length
- 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)
- 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
- 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.
Stay on the light side. R.Z.
