Security Testing. NIST SP 800-115 overview.

    

Hi, Dear Reader, it's been a while, I know. Will try to do my best and write more often. ;)

Introduction

Often the case (I believe every time, actually) Software developers need to test and verify a product prior to release. I'm convinced Validation team has really sophisticated checks and tools to do quality assurance stuff. However, when Security shows up it's not always obvious how to perform Security validation and what is the right place in the Validation plan for it. Today in this short write-up I'd like to remind you about quite useful guide NIST SP 800-115 Technical Guide to Information Security Testing and Assessment, first time issued in 2008 but still could be useful. Let's highlight the most essential takeaways.

Overview

The document provides practical recommendations for designing, implementing, and maintaining technical information security test and examination processes and procedures. It is organized into 7 chapters and 7 Appendixes.

What I really like is defining benefits:

• Provide consistency and structure to security testing, which can minimize testing risks.
• Expedite the transition of new assessment staff.
• Address resource constraints associated with security assessments.

This allows you to convey not only Security purposes yet to give the Product team the ability

to reuse pre-established resources such as trained staff and standardized testing platforms; decreases time required to conduct the assessment and the need to purchase testing equipment and software; and reduces overall assessment costs. The overall process includes 3 major stages (as usual).

"How-to-do" part is divided into 3 parts.

Short summary

Actually, you may not really read the whole document, because each section is ended up with the short summary. It does make sense to take a look at them and compare with your own practice. 

Moreover, the guide provides us with useful tools just embedded in specific Linux distro. Even though some of them seems outdated and weird (i.e. Application Security Testing), your Validation engineers could use this list as a starting point.

Conclusion

As a result, please do not consider this document as a guide for experienced Pentesters or Read team. It is designed to help your product team figure out what is Security validation process, why it is beneficial and necessary. The most important takeaway is a structured process and practical examples, describing how you can adopt Security validation keeping in mind already established development pipeline.

Stay on the light side. R.Z.

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

   

Наконец, финальная заметка с тезисным обзором хороших практик по удобной аутентификации в сервисах, изложенных в рекомендации NIST Special Publication 800-63B. Digital Identity Guidelines. Authentication and Lifecycle Management. Предыдущая заметка была про пароли, сегодня - про мультифакторную аутентификацию (MFA). Часть 2. В самом начале я рассказал о том, Как сервисам сделать использование паролей удобным. В Части 1 про MFA мы рассматривали 3 типа рекомендаций для сервисов по удобной и безопасной мультафакторной аутентификации: Отдельный канал связи до выделенного устройства (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).

Ключ, хранимый в софте/на диске (Single-Factor Cryptographic Software)

Предполагает использование для второго фактора аутентификации некоего ключа, который хранится на устройстве пользователя прямо на диске (файл), либо внутри специального софта (суть - та же). Может инкапсулировать в себе один или несколько секретных ключей. Реализует принцип "то, что у меня есть". Фактически, это и есть принцип электронной подписи. По идее, любой, у кого появился доступ на устройство пользователя, может воспользоваться ей для подтверждения аутентификации. Очевидно, что хранить ключ просто файлом на диске - не лучшее решение с точки зрения безопасности, однако, если такое применяется, то следуйте следующим советам:

1. Ключ должен содержаться в безопасном хранилище (Keychain, TPM, TEE и т.п.)
2. Ключ должен быть защищен от несанкционированного доступа, а права обращения к нему - назначены только необходимому приложению (-ям)
3. Нельзя допускать клонирование ключа и возможности его переиспользования на другом устройстве
4. Поскольку для проверки ключа на стороне сервиса хранится ассиметричный или симметричный ключ, они должны быть защищены от модификации, а симметричный - еще и от раскрытия
5. Посылаемое со стороны сервиса на устройство (или в приложение) в момент аутентификации "секретное сообщение" должно быть уникальным (не повторяться) и длиной не менее 64 бит   

Ключ, хранимый на подключаемом устройстве (Single-Factor Cryptographic Devices)

В отличие от предыдущего способа, здесь секретный ключ хранится на отчуждаемом носителе. Чтобы использовать его, как второй фактор, необходимо каждый раз при аутентификации на сервисе подключать его к устройству, а после завершения работы с сервисом - отключать. Реализует принцип "то, что у меня есть". Удостоверение (подписание) с помощью ключа происходит путем прямого подключения к интерфейсу клиентского устройства (например, USB-порт или более современные - по bluetooth). Главное отличие от софтового вариант в том, что здесь управление доступом к ключам происходит на подключаемом устройстве. Вот - рекомендации по безопасности:

1. Главный принцип - ключи должны быть не клонируемыми и не удаляемыми (исключение - "заводское" обнуление)
2. Хорошо, если подключаемое устройство может иметь собственный криптографический процессор
3. Алгоритм, секретный ключ должны удовлетворять минимальным требованиям безопасности (быть по крайней мере 112 бит)
4. Секретный ключ должен быть длиной не менее 64 бит
5. Хорошей практикой в момент использования ключа является наличие на устройстве "физического активатора" вроде кнопки, чтобы предотвратить его злоумышленное использование
6. Поскольку для проверки ключа на стороне сервиса хранится ассиметричный или симметричный ключ, они должны быть защищены от модификации, а симметричный - еще и от раскрытия
7. Посылаемое со стороны сервиса в момент аутентификации "секретное сообщение" должно быть уникальным (не повторяться) и длиной не менее 64 бит

Ключ, хранимый в софте/на диске + другой фактор (Multi-Factor Cryptographic Software)

Основное отличие от простого софтового хранилища - дополнительный второй фактор, требуемый для обращения к секрету (подписи, сертификату). В качестве него может выступать пин-код, пароль или биометрические данные. Для самого сервиса нет при проверке ключа никакой разницы по сравнению с обычным "софтовым" хранением, усиление происходит только на стороне клиента. Реализует сразу два принципа: "то, что у меня есть" совместно с "тем, что я знаю"/"тем, кто я". Все рекомендации из раздела "Ключ, хранимый в софте/на диске" справедливы и для текущего. Однако, вот, на что стоит обратить внимание сервисам и клиентам:

1. Ключ должен содержаться в безопасном хранилище (Keychain, TPM, TEE и т.п.)
2. Ключ должен быть защищен от неавторизованного доступа путем создания такой модели, при которой обращение к нему происходит только от определенного списком клиентского софта
3. Нельзя допускать клонирование ключа и возможности его переиспользования на другом устройстве
4. Каждая без исключений операция обращения к ключу должна сопровождаться требованием предъявления второго фактора
5. Если для обращения к ключу используется числовой код, то он должен состоять из не менее чем 6 цифр, количество попыток ввода должно быть ограничено
6. Если для активации OTP устройства используется биометрия, то должно быть ограничено число попыток и другие меры безопасности (подробнее - ниже в Бонусе 2)
7. Ключ, образец биометрии, иной секрет в случае успешного обращения к ключу должны быть затерты сразу же после завершения второго шага (использование ключа непосредственно по назначению)

Ключ, хранимый на подключаемом устройстве + другой фактор (Multi-Factor Cryptographic Device)

При таком способе хранение ключа и непосредственно криптографические операции осуществляются на отдельном устройстве, для активация которого требуется  дополнительный второй фактор (пин-код, пароль, биометрия). Для аутентификации на сервисе клиенту необходимо подключить отдельное устройство напрямую к своему основному (компьютер, ноутбук, смартфон). Принцип действия и базовые советы здесь повторяют таковые для "Ключа, хранимого на подключаемом устройстве". По сути, единственное отличие - необходимость предъявить что-то еще. Реализует сразу два принципа: "то, что у меня есть" совместно с "тем, что я знаю"/"тем, кто я". Ниже приведем дополнительные к уже описанным рекомендации по безопасности:

1. Каждая без исключений операция обращения к ключу должна сопровождаться требованием предъявления второго фактора, что можно сделать либо непосредственно на таком отдельном устройстве (ввести пароль, приложить палец), либо с помощью подключения к нему (смарт-карта, USB) 
2. Ключ, образец биометрии, иной секрет в случае успешного обращения к ключу должны быть затерты сразу же после завершения второго шага (использование ключа непосредственно по назначению)

Бонус 1. Дополнительные рекомендации по ограничению попыток доступа

Хорошей практикой является внедрение по-умолчанию механизмов ограничения попыток неправильного ввода пароля, предъявления второго фактора (защита от угадывания и брутфорс атак). В качестве базового требования для задач любого сервиса предлагается установить ограничение в 100 попыток (для одного аккаунта). Но не так все просто. Необходимо принимать следующие меры, чтобы минимизировать вероятность блокировки легитимных пользователей злоумышленниками:

1. Использование сервисом капчи непосредственно перед процедурой аутентификации
2. Задание временного промежутка (от 30 до 60 мин.) невозможности очередного ввода после нескольких попыток неудачной аутентификации
3. Отслеживание сервисом IP-адресов, с которых подключаются клиенты, и, как минимум, предупреждать (или блокировать) попытки доступа с незнакомых
4. Внедрение сервисом продвинутых техник поведенческой аналитики пользователей (и их устройств) и детектирование отклонений (IP-адреса, геолокация, временные промежутки, метаданные браузера и т.п.)
5. При успешной аутентификации сервис должен игнорировать все предыдущие неуспешные попытки этого пользователя с этого IP-адреса 

Бонус 2. Дополнительные рекомендации по использованию биометрии

Использование биометрии в качестве второго фактора (реализует принцип "тот, кто я") включает как физиологические характеристики (палец, глаз, лицо, ладонь и т.п.), так и поведенческие (например, стиль клавиатурного ввода). В обозреваемом документе NIST приводится некий скепсис (ограничения) по использованию биометрии:

1. Существует так называемый биометрический Коэффициент ложного совпадения (False Match Rate - FMR), который в общем случае не гарантирует точность процедуры (в отличие от иных методов). Кроме того, FMR не стоек к спуффинг-атакам
2. Схемы защиты биометрических шаблонов, такие как отзыв биометрических учетных данных вроде бы уже придуманы и схожи с остальными методами (сертификаты PKI, пароль и т.п.), однако на практике они еще сырые, разрабатываются и тестируются
3. Некоторые виды популярной биометрии относительно легко подвержены копированию (вспомните дипфейки или приемы кражи отпечатков пальцев). Разрабатываются методы противодействия подобного рода атакам такие как  Presentation Attack Detection - PAD (например, интеллектуальное определение живого/не живого человека), но главное "слово" все равно остается за сенсором, в котором нужно будет предусматривать дополнительные механизмы доверия

Если вы все же решились использовать биометрию, то придерживайтесь следующих рекомендаций:

1. Биометрия должны использоваться исключительно как часть мультифакторной аутентификации с физическим устройством (т.е. "тем, что я имею")
2. Канал от датчика клиента до сервиса должен быть защищен, а доступ к ключу в самом втором факторе (его активация с помощью биометрии) должен быть открыт только после успешной биометрической аутентификации на нем 
3. False Match Rate (FMR) должен удовлетворять требованиям "1 из 1000" стандарта ISO/IEC 2382-37
4. Биометрическая система должна реализовывать Presentation Attack Detection (PAD) на выбор: либо на стороне сервиса, либо на стороне клиента. Тестирование такого механизма должно показывать как минимум 90% стойкость к presentation атакам каждого из типов 
5. Биометрическая система должна допускать не более 5 неудачных попыток аутентификации или не более 10 (в случае реализации PAD). При превышении порога допускаются следующие сценарии (на выбор сервиса):
1. принудительная задержка перед следующей попыткой сначала 30 секунд, потом 1 минута, потом 2 минуты
2. блокировка биометрии, как второго фактора и предложение альтернативного метода (если он предусмотрен)
6. Сервис должен каким-либо способом установить доверие к биометрическому датчику путем: его (или устройства пользователя) дополнительной аутентификации, сертификации независимым органом, внедрение неких метаданных в качестве подписи прямо на лету
7. Проверка биометрии может осуществляться локально на устройстве пользователя (предпочтительный и более безопасный вариант) или централизованно сервисом. Во втором случае сервису необходимо внедрить:
1. использование биометрии должно быть ограничено на конкретных устройствах, которые сервис способен идентифицировать (например, с помощью отдельного ключа, отличного от основного)
2. механизм отзыва биометрии согласно ISO/IEC 24745
3.  любая передача биометрии должна осуществляться по защищенному каналу
8. С согласия пользователя биометрические образцы можно агрегировать с целью обучения (тюнинга) алгоритмов проверки, они должны быть удалены после достижения таких целей
9. Биометрия также может быть использована сервисами для обеспечения неотказуемости на всех этапах регистрации пользователя и работы в сервисе, подробнее об этом - в публикации NIST SP800-63A 

Как мы видим, внедрение даже самых современных методов многофакторной аутентификации уже можно осуществлять согласно лучшим практикам (спасибо коллегам из NIST), которые довольно подробно описывают базовые требования по безопасности. Когда есть куда "подсмотреть" - это всегда полезно.

Основной целью данного цикла заметок было рассказать, что существуют не только строгие нормативные требования по организации аутентификации в сервисах, но и рекомендации, учитывающие как лучшие практики по безопасности, так и вопросы удобства. Последнее является обязательным, ведь, как мы знаем, пользователи - самый первый и едва ли не самый важный рубеж обороны в противостоянии со злоумышленниками. Удобная безопасность всегда будет наиболее эффективна.

Читайте также: MFA. Часть 1, Удобные пароли

Оставайтесь на светлой стороне. R.Z. 

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:

1. The key shall be stored in suitably secure storage available to the user's application (e.g., keychain storage, TPM, or TEE if available)
2. 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
3. Single-factor cryptographic software authenticators should discourage and shall not facilitate the cloning of the secret key onto multiple devices
4. 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
5. 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:

1. 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)
2. Alternatively, the authenticator could be a suitably secure processor integrated with the user endpoint itself (e.g., a hardware TPM)
3. The secret key and its algorithm shall provide at least the minimum security length 112 bits
4. The challenge nonce shall be at least 64 bits in length
5. 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
6. 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
7. 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:

1. The key should be stored in suitably secure storage available to the user's application (e.g., keychain storage, TPM, TEE)
2. 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
3. Multi-factor cryptographic software authenticators should discourage and shall not facilitate the cloning of the secret key onto multiple devices
4. Ключ должен содержаться в безопасном хранилище (Keychain, TPM, TEE и т.п.)
5. Each authentication operation using the authenticator shall require the input of both factor, whitout exceptions
6. 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
7. 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. 
8. 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:

1. 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) 
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 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:

1. Requiring the claimant (user) to complete a CAPTCHA before attempting authentication
2. 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)
3. Accepting only authentication requests that come from a white list of IP addresses from which the subscriber has been successfully authenticated before
4. 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
5. 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:

1. 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
2. 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
3. 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:

1. Biometrics shall be used only as part of multi-factor authentication with a physical authenticator (something you have)
2. 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)
3. The biometric system shall operate with an FMR (ISO/IEC 2382-37) of 1 in 1000 or better
4. 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)
5. 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):
1. 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
2. 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
6. 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
7. 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:
1. 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
2. biometric revocation, referred to as biometric template protection in ISO/IEC 24745, shall be implemented
3. all transmission of biometrics shall be over the authenticated protected channel
8. Канал от датчика клиента до сервиса должен быть защищен, а доступ к ключу в самом втором факторе (его активация с помощью биометрии) должен быть открыт только после успешной биометрической аутентификации на нем 
9. False Match Rate (FMR) должен удовлетворять требованиям "1 из 1000" стандарта ISO/IEC 2382-37
10. 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
11. 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.

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

  

По просьбам читателей продолжаю цикл заметок с тезисным обзором хороших практик по удобной аутентификации в сервисах, изложенных в рекомендации NIST Special Publication 800-63B. Digital Identity Guidelines. Authentication and Lifecycle Management. Предыдущая заметка была про пароли, сегодня - про мультифакторную аутентификацию (MFA). Часть 1. Как было верно подмечено коллегами, лучшая практика обезопасить пароли - это не использовать их. Точнее, добавить второй и/или третий фактор, который необходимо будет предъявить пользователю при входе помимо логина/пароля. В классической многофакторной модели подтверждение личности достигается благодаря указанию комбинации из трех параметров:

1. То, что я знаю (помню)
2. То, что у меня есть (физически)
3. То, кто я (что-то неотъемлемое от меня)

В обозреваемом документе NIST приводятся рекомендации относительно реализации 7 видов аутентификации, которые можно отнести к 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)

Безусловно, для сервиса, который предлагает подобные усиленные методы аутентификации весь процесс обходится дороже (даже в самом простом случае - приложение на телефоне или СМС). Однако, это куда более надежно, чем простой пароль и обеспечит дополнительную защиту как для клиента, так и для самого сервиса. Для каждого из типов приведем наиболее интересные советы и рекомендации, которые помогут сервисам сделать безопасность удобной для пользователей. В данной заметке рассмотрим типы 1-3, остальное - оставим на Часть 2.

Отдельный канал связи до выделенного устройства (Out-of-Band Devices)

Предполагает использование физического устройства (самое простое - телефона), верификация с помощью которого осуществляется по иному каналу, нежели ввод логина-пароля в браузере для доступа к сервису. Реализует принцип "то, что у меня есть". Такой метод может быть реализован отправкой смс (или push-уведомления) или необходимостью действий в специальном приложении на телефоне (нажать подтверждение, отсканировать QR-код и т.п.). Методы передачи и получения второго фактора могут быть совершенно разными, чаще всего одни из трех (передача на устройство и последующий ввод в сервисе, отображение в сервисе и последующий ввод на устройстве, отображение и передача одного и того же секрета с необходимостью подтверждения да/нет на устройстве). Не зависимо от них необходимо следовать следующим рекомендациям:

1. Канал передачи второго фактора должен быть независим от первого (однако, допускается реализовывать их на одном устройстве) 
2. Устройство должно однозначно адресоваться, а аутентификационная информация - шифроваться при передаче
3. Устройство должно однозначно аутентифицировать себя: либо с помощью зашитого ключа (TPM, TEE и т.п.), либо уникального ID SIM-карты (например, IMSI)
4. Секреты не должны отображаться на заблокированном телефоне
5. При обратной передаче сервису подтверждения второго фактора необходимо проверять целостность (консистентность) транзакции, чтобы исключить подмену
6. Устройство не должно хранить секрет подтверждения второго фактора в открытом виде, для передачи его сервису необходимо применять хэширование
7. Ждать подтверждения необходимо не более 10 минут в рамках одной сессии, потом нужно повторить операцию
8. Случайные генерируемые секреты должны иметь энтропию как минимум 20 бит, а если она меньше 64 бит, то потребуется дополнительно внедрить защиту от перебора (впрочем, она никогда не бывает лишней)
9. Передавать второй фактор через публичные телефонные сети (PSTN) крайне не рекомендуется, но если сервис это делает, то необходимо учитывать риски подмены SIM, перехвата сообщений, подмены портов и т.п. 

Простой генератор одноразовых паролей (Single-Factor OTP Device)

Могут быть как отдельными устройствами, так и приложением на телефоне. Реализует принцип "то, что у меня есть". Алгоритм генерации паролей вместе с секретным ключом зашиты в устройство (о них, конечно, знает и сам сервис) и может быть основан на времени, счетчике, специальных словах и т.п. При использовании такого типа аутентификации необходимо придерживаться следующих рекомендации:

1. Алгоритм, секретное слово должны удовлетворять минимальным требованиям безопасности (быть по крайней мере 112 бит)
2. Алгоритм, секретное слово и другие определяющие одноразовый пароль инструменты должны гарантировать его (пароля) постоянную уникальность
3. Устройства должны препятствовать возможности скопировать (клонировать) одноразовый пароль
4. Отображаемый на устройстве после всех вычислений одноразовый пароль может быть в итоге сокращен до 6 числовых значений (энтропия примерно 20 бит)
5. Пароли, очевидно, не должны повторяться
6. Если в качестве входных данных для вычисления одноразового пароля используется текущее время, то оно должно меняться не реже чем раз в 2 минуты
7. Симметричные ключи, используемые для генерации одноразовых паролей, необходимо защищать от компрометации как на стороне устройства, так и на стороне сервиса, поскольку очевидно, что они - одни и теже
8. При вводе пароля на стороне сервиса должна применяться надежная защита (об этом можно почитать в предыдущей статье про пароли) от компрометации и MitM атак
9. OTP устройства должны выдаваться (привязываться) однократно одному пользователю на весь период действия 
10. При генерации одноразовых паролей энтропию должна составлять как минимум 20 бит, а если она меньше 64 бит, то потребуется дополнительно внедрить защиту от перебора (впрочем, она никогда не бывает лишней)

Мультифакторный генератор одноразовых паролей (Multi-Factor OTP Device)

Основное отличие от простого генератора - дополнительный второй фактор, усиливающий операцию генерации одноразового пароля. Таким фактором может быть подключенный считыватель биометрии, устройство для ввода пин-кода или просто порт (например USB). Реализует сразу два принципа: "то, что у меня есть" совместно с "тем, что я знаю"/"тем, кто я". Таким образом, вся процедура делится на 2 шага: активация самого OTP и получение с помощью OTP второго фактора для аутентификации на сервисе. Для самого сервиса в итоге такой тип устройства выглядит как обычный однофакторный. Очевидно, все рекомендации из предыдущих разделов (простые пароли и простой генератор одноразовых паролей) справедливы и для текущего. Однако, вот, на что дополнительно (кроме уже упомянутого) стоит обратить внимание:

1. Если для активации OTP используется пин-пад, то пин должен состоять из не менее чем 6 цифр
2. Если для активации OTP устройства используется биометрия, то должно быть ограничено число попыток и другие меры безопасности (их подробнее рассмотрим в Части 2)
3. Ключ, образец биометрии, иной секрет в случае успешной активации OTP должны быть затерты сразу же после завершения второго шага (использование OTP непосредственно по назначению)
4. Если сервис заподозрил попытки многократного использования одного и того же значения OTP, он может предупредить пользователя о таких попытках

В целом, рассмотренные сегодня рекомендации касаются больше безопасносности, чем удобства (как было в заметке про пароли). Однако, современные методы применения второго фактора для аутентификации на сервисах уже по-умолчанию предлагают удобство, по сути, даже в некотором роде снижая требования (и риски) использования простых паролей.  

В Части 2 будем рассматривать применение ключей для второго фактора в разных вариациях.

Читайте также: MFA. Часть 1, Удобные пароли

Оставайтесь на светлой стороне. 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:

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.

See also: MFA. Part 2, Convenient passwords

Stay on the light side. R.Z.

How services can make using passwords convenient || Как сервисам сделать использование паролей удобным

 

Тема создания безопасных, надежных, но в тоже время "запоминабельных" паролей, пожалуй, стара, как мир. Шутка ли, до сих пор встречаешь в реальной жизни те самые стикеры на мониторах, записки в блокноте на столе, а так же... пароли и пин-коды открытым текстом в адресной книге или в заметках на телефоне, да еще и выведенные виджетом на главный экран. Знакомо? Значит, заметка имеет шанс оказаться полезной. Но что, если немного подумать о пользователях и не "вешать" всю ответственность только лишь на них? Рекомендации NIST Special Publication 800-63B. Digital Identity Guidelines. Authentication and Lifecycle Management, о выдержках из которых сегодня пойдет речь, также не новые, однако, регулярно обновляются (последняя редакция от 2020 года). Кроме того, в последнее время я фиксирую повышенное внимание к этой теме со стороны СМИ и в целом людей вокруг.

 

Безопасность должны быть удобной - я это повторяю постоянно. Коллеги из NIST выпустили рекомендации главным образом для порталов, приложений и сервисов, которыми мы с вами пользуемся. Следуя им, пользователям будет выгоднее и легче использовать надежные пароля, при этом не нужно требовать от них постоянного усложнения, лишних действий и длиннющих инструкций. За некоторые положения реально хочется пожать руку, ведь они развенчивают кучу мифов.

На самом деле, публикация NIST большая и охватывает все возможные аспекты жизненного цикла "секретов", а также 9 типов аутентификации. Мы же сегодня - исключительно про пароли (Memorized Secret Authenticators).

1. Пароли должны быть не менее 8 символов, если придумываются пользователем сервиса и не менее 6, если создаются генератором (например, встроенным в сам сервис), они могут состоять только из цифр.
2. Сервису рекомендуется автоматически проверять, не "засветились" ли пароли в слитых базах
3. Сервис не должен разрешать использовать "словарные" и очень уж простых простые пароли, благо сравнение с таким справочником сделать несложно, они есть в открытом доступе
4. Сервис должен запрещать пароли, содержащие имя пользователя или его часть
5. Отдельно оговаривается то, что для нашего уха (профдеформированного разного рода РД и НПА) может показаться странным: никаких дополнительных требований, кроме длины, к паролю предъявлять не стоит (разные наборы символов и т.п.). 
6. Сервис должен технически предоставить пользователю возможности придумать пароль длиной 64 символа (или больше)
7. В паролях должны поддерживаться все символы ASCII [RFC 20], включая пробелы
8. Unicode [ISO/ISC 10646] кодировка также должна поддерживаться (эмодзи в том числе), включая такую нормализацию, при которой 1 введенный символ в UNICODE эквивалентен 1 в ASCII
9. Запрещаются всякого рода всплывающие подсказки (помните, в прошлых версиях Windows были такие?) на формах ввода логина/пароля
10. Напротив, сервис должен объяснить пользователю, чтобы тот не использовал подсказки вида "имя питомца, фамилия матери и т.п." и не мог используя лишь только их сбросить пароль
11. Сервису необходимо приводить примеры пользователю и объяснять, почему выбранный им пароль вдруг не безопасен
12. Количество неверных попыток ввода пароля должно быть лимитировано. Приводится конкретное довольно большое число - 100, с оговоркой, что лучше использовать дополнительные механизмы (капча, лимит времени между попытками и т.п.)
13. Еще одно разрушение мифов: сервисы не должны требовать принудительной смена пароля периодически (раз в месяц, год и т.п.). Вместо этого необходимо мониторить утечки паролей и своевременно предупреждать пользователя о возможной компрометации.
14. Вопреки расхожему мнению, сервисы должны разрешать функцию "вставить" при вводе пароля. Иначе пользователи вместо сложного пароля из менеджера паролей будут придумывать и использовать менее сложные.
15. Сервис должен позволять посмотреть введенный "звездочками" (*) пароль, чтобы пользователь проверил его корректность. Также актуальным (особенно для мобильных устройств) будет показывать каждый вводимый символ на несколько секунд.
16. К сервису также предъявляются требования по надежному хранению пароля и защите при его запросе (передаче), такие как хэш с "солью", шифрование связи и т.п.

Приведенные рекомендации основаны на практическом опыте и многие особенно крупные сервисы уже внедрили их. Однако, если вы проектируете свой собственный сервис или приложение, то нелишним будет ознакомиться с ним.

Читайте также: MFA. Часть 1, MFA. Часть 2

Оставайтесь на светлой стороне. R.Z.

 

"How to set a strong, unique and memoriaable user password" - this topic has been winning today the first lines in articles about cybersecurity. It often happens that I still see stickers on monitors, notes written on a piece of paper and.... for sure, passwords and PINs written by plain text in the address book, notes app or even home screen widget. However, what if you think a little about the users and don't just give them all the full responsibility? Issued by NIST Special Publication 800-63B. Digital Identity Guidelines. Authentication and Lifecycle Management offers recommendations for service providers, portals and others whether they are cloud based or on-premises. This is not a new document, but it is periodically updated (the latest version is dated 2020) and is still relevant.

Security should be comfortable, I keep saying that. It is gratifying that the guys from NIST worrying about users created best practices for services. Following them, it will be more profitable and easier for users to use well-made passwords, while you do not need to require them to constantly complicate, unnecessary actions and lengthy instructions. For some provisions, I really want to shake hand, because they do debunk a lot of myths.

Actually NIST SP 800-63B contains many aspects of the password management lifecycle and 9 types of authentication. Let me talk today about the only one of them 

(Memorized Secret Authenticators).

1. Passwords must be at least 8 characters long if they are created by the user, and at least 6 characters long if they are generated automatically. Important: Passwords may be entirely numeric
2. The service is recommended to check passwords based on their appearance in the black list of compromised values 
3. The service should not allow the use of "dictionary" or simple passwords (111, aaaa, qwerty, etc.). Fortunately, there are many such lists on the Internet to check.
4. The service sholud prohibit passwords that contain the username or part of it
5. Very important (and sometimes a popular myth): No other complexity requirements for memorized secrets should be imposed (like variety of chars, case, digits). 
6. The service shuold technically support the use of passwords of at least 64 characters in length
7. All printing ASCII [RFC 20] characters should be acceptable, including spaces
8. Unicode [ISO/ISC 10646] characters (including emojis!) should be acceptable, including normalization and equal number of symbols (1 UNICODE = 1 ASCII)
9. The service shall not permit the user to store a “hint” that is accessible to an unauthenticated claimant (Do you remember hints in earlier Windows versions on the login page?)
10. Conversely, the service shall not prompt subscribers to use specific types of information and help them not to use typical phrases (e.g., “What was the name of your first pet?”)
11. The service should show examples and explain to users why his or her password is not secure and refuse to use it if it matches a blacklist or dictionary
12. The service shall implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber’s account (in fact, the number given is quite high - 100, however, it's good practice to use additional mechanisms such as captcha, time limit between attempts, etc.)
13. Ones more myths breaking: the service should not require passwords to be changed arbitrarily (e.g., periodically). Instead the service shall force a change if there is evidence of compromise of the authenticator.
14. The service should permit claimants to use “paste” functionality when entering a memorized secret. This facilitates the use of password managers, which are widely used and in many cases increase the likelihood that users will choose stronger memorized secrets.
15. The service should offer an option to display the secret — rather than a series of dots or asterisks ("*"). It's also useful to permit the user’s device to display individual entered characters for a short time after each character is typed to verify correct entry (particularly applicable on mobile devices).
16. The service also has requirements for reliable password storage and protection when it is requested (transmitted), such as a hash with a "salt", communication encryption, etc.

These recommendations are based on practical experience and many (especially large services) have already implemented them. However, if you are designing your own service or application, it is useful to familiarize yourself with it.

See also: MFA. Part 1, MFA. Part 2

Stay on the light side. R.Z.