[Информационная безопасность] Новая версия ЧАВО для выбора паролей и правил создания систем аутентификации от NIST
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Перевод наиболее интересных пунктов из FAQ для документа Digital Identity Guidelines от NIST (The National Institute of Standards and Technology) от 8 января 2020 года.
Кому это может быть интересно?
Всем пользователям компьютерных систем, кто хочет понимать причины по которым создаются те или иные требования систем безопасности. И может быть даже даст понимание как измененить собственное поведение, чтобы следовать более безопасным практикам.
Разработчики и особенно специалисты по системам безопасности определённо должны ознакомится с этой информацией, так как в сегодняшней разработке, принцип «security first», актуален как никогда.
Почему должны ориентироваться именно на информацию из NIST?
NIST устанавливает стандарты, которые обязательны для следования правительственным учреждениям США, а также компаниям которые работают как подрядчики правительства. Т.е. довольно значительная часть компаний из США и крупные международные корпорации подпадают под эти правила. Многие страны и местные органы управления также создают стандарты политики безопасности базируясь на требования устанавливаемые NIST. Не удивлюсь тому что и Россия принимает их во внимание при создании национальных стандартов.
Почему переведён FAQ, а не оригинальный документ?
Потому что оригинальный документ написан в достаточно сухом, канцелярском стиле, а FAQ поживее и содержит объяснения лежащие в основе принятия тех или иных решений.
Почему только часть FAQ?
Потому что TL;DR. Каюсь, сам грешен, слишком длинные статьи сложно читать (и что гораздо важнее понимать), если статья не относится непосредственно к твоей области деятельности.
Поэтому переведены только самые важные и интересные (на мой субъективный взгляд) пункты. Если у сообщества возникнет желание, то я думаю профессиональные переводчики от одного из корпоративных блогов, легко переведут полную версию.
Небольшой disclaimer перед началом. Я не являюсь профессиональным переводчиком (и даже любителем), это второй перевод в моей жизни, на первый (сделанный лет 20-ть назад) мне пришла рецензия – «не присылайте переводов сделанных Prompt-ом», хотя всё было сделано используя исключительно толковый словарь. Это будет попытка номер два (надеюсь что получше), но не удивлюсь комментариям где prompt, будет заменен на google (тем более в этот раз это будет частично правдой), а остальное останется как есть.
На данный момент, в качестве разработчика, я занимаюсь интеграцией одного из провайдеров аутентификации и мне показалось что некоторые пункты из FAQ, идущие вразрез с сегодняшними общепринятыми практиками будут очень интересны для русскоязычного сегмента сети.
Через год-два, будет заметно как эти правила начнут реализовывать во многих корпоративных системах.
Выброчные пункты из NIST Special Publication 800-63: Digital Identity Guidelines, Frequently Asked Questions
Почему более не рекомендуется ограничивать срок действия пароля?
От пользователей системы НЕ СЛЕДУЕТ требовать изменения паролей на основе некоторых правил (например периодически, раз в три месяца и т.п.). Однако владельцы системы ДОЛЖНЫ начать процедуру принудительной смены паролей, если существует подозрение что система аутентификации была скомпроментированна.
Пользователи склонны выбирать более слабые пароли, если они знают, что в ближайшем будущем их потребуют снова сменить. И когда пароли будут поменяны, зачастую пользователи выберут пароль, который будет очень похож на их старый пароль, просто применив некоторое преобразование, например увеличение значения числа в пароле. Подобное поведение дает ложное ощущение безопасности, поскольку если какой-либо из предыдущих паролей был скомпрометирован, хакер может угадать предыдущий пароль применив подобные правила.
Но если есть подозрение того, что система аутентификации была скомпрометирована, например, в результате взлома базы данных паролей, то следует потребовать принудительное изменение паролей от ваших пользователей.
Оригинал B05
SPL
Q-B05:
Is password expiration no longer recommended?
A-B05:
SP 800-63B Section 5.1.1.2 paragraph 9 states:
“Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.”
Users tend to choose weaker memorized secrets when they know that they will have to change them in the near future. When those changes do occur, they often select a secret that is similar to their old memorized secret by applying a set of common transformations such as increasing a number in the password. This practice provides a false sense of security if any of the previous secrets has been compromised since attackers can apply these same common transformations.
But if there is evidence that the memorized secret has been compromised, such as by a breach of the verifier’s hashed password database or observed fraudulent activity, subscribers should be required to change their memorized secrets. However, this event-based change should occur rarely, so that they are less motivated to choose a weak secret with the knowledge that it will only be used for a limited period of time.
Правда ли что больше не стоит заставлять пользователей использовать разные группы символов при выборе пароля?
Мы более не рекомендуем использовать правила композиции при выборе пароля (например, требовать обязательного включения строчных и прописные буквы, цифр и/или специальных символов).
Как показала практика, эти правила дают меньше преимуществ, чем можно было бы от них ожидать, потому что пользователи склонны использовать предсказуемые методы для удовлетворения этих требований (например, добавление ! в конце пароля, когда правила требуют иметь специальный символ в его составе).
Подобные требования зачастую выполняются формально, что не способствует выбору хорошо запоминающегося, но сложного для подбора пароля. Черный список наиболее употребимых паролей решает данную проблему более эффективно, особенно для онлайн-сервисов.
Подобные правила также непреднамеренно побуждают людей использовать один и тот же пароль во множестве различных систем, поскольку они часто приводят к тому, что такие пароли трудно запомнить.
Оригинал B06
SPL
Q-B06:
Are password composition rules no longer recommended?
A-B06:
SP 800-63B Section 5.1.1.2 paragraph 9 recommends against the use of composition rules (e.g., requiring lower-case, upper-case, digits, and/or special characters) for memorized secrets.
These rules provide less benefit than might be expected because users tend to use predictable methods for satisfying these requirements when imposed (e.g., appending a! to a memorized secret when required to use a special character). The frustration they often face may also cause them to focus on minimally satisfying the requirements rather than devising a memorable but complex secret. Instead, a blacklist of common passwords prevents subscribers from choosing very common values that would be particularly vulnerable, especially to an online attack.
Composition rules also inadvertently encourage people to use the same password across multiple systems since they often result in passwords that are difficult for people to memorize.
Можно ли использовать ОГРАНИЧЕННО НАДЁЖНЫЕ факторы аутентификации и какие дополнительные усилия должны быть предприняты, если ваша система их использует?
По мере развития угроз, некоторые факторы аутентификации становятся менее надежными, поэтому было решено использовать термин «ОГРАНИЧЕННО НАДЁЖНЫЙ», чтобы обозначить факторы аутентификации которые не реализуют надёжный уровнь защиты. Команда криптографии NIST также использует подобное название и мы пытаемся не плодить дополнительные сущности без надобности.
Реализация «ограниченно надёжного» фактора аутентификации требует от владельца системы оценки, понимания и принятия рисков, связанных с использованием этого типа аутентификации.
Необходимо:
- Пользователю системы иметь возможность использовать хотя бы один, альтернативный НАДЁЖНЫЙ аутентификатор.
- Предоставьте пользователю полную информацию о рисках связанных с безопасностью использования «ограниченно надёжного» фактора аутентификации и наличии альтернатив. Пользователь должен осознанно участвовать в процессе принятия решения.
- Включить факт использования подобного типа аутентификации в документ оценки рисков.
- Иметь план миграции на случай, если «ограниченно надёжный» фактора аутентификации в будущем будет признаны НЕНАДЁЖНЫМ.
В настоящее время факторы аутентификации использующие телефонную сеть общего пользования, голосовые одноразовые пароли (OTP) и сообщения SMS, считаются «ограниченно надёжными».
Обратите особое внимание, что при использовании голосовых сообщений и SMS используется телефонная сеть, а не VoIP системы, поскольку они считаются ненадёжной системой и обычно менее защищены.
Оригинал B01
SPL
Q-B01:
What is a RESTRICTED authenticator and what do providers have to do differently if they use one?
A-B01:
As threats evolve, some authenticators become less reliable, so we established the notion of “RESTRICTED” to tag authenticators if they become of concern. We didn’t make this up: the NIST cryptography team has been using this approach for some time, and we like to be consistent with other NIST efforts so we don’t confuse our stakeholders. Implementing a RESTRICTED authenticator requires the agency to assess, understand, and accept the risk associated with that authenticator.
Therefore, the agency needs to:
- Offer subscribers at least one alternate authenticator that is not RESTRICTED.
- Provide subscribers with meaningful information on the security risks of the RESTRICTED authenticator and availability of alternatives. It’s the user’s account and personal information, so we believe the user needs to participate in the risk determination process as well.
- Include in its risk assessment any additional risk to subscribers.
- Develop a migration plan for the possibility that the RESTRICTED authenticator is no longer acceptable at some point in the future.
Currently, authenticators leveraging the public switched telephone network, including phone- and Short Message Service (SMS)-based one-time passwords (OTPs) are restricted. Other authenticator types may be added as additional threats emerge. Note that, among other requirements, even when using phone- and SMS-based OTPs, the agency also has to verify that the OTP is being directed to a phone and not an IP address, such as with VoIP, as these accounts are not typically protected with multi-factor authentication.
Что это такое — намерение начать аутентификацию?
Намерение начать аутентификацию — это физический процесс который демонстрирует, что это реальный человек намеривается аутентифицироваться в самом ближайшем времени. Использование этого факта — например, ввод OTP, вставка смарт-карты или прикосновение карточкой (всё это известно как доказательство присутствия) — может выступать в качестве дополнительной меры противодействия вредоносному ПО, использующему скомпрометированную систему в качестве прокси для аутентификации злоумышленника без участия пользователя. Это затруднит возможность не авторизированного использования системы.
Оригинал B03
SPL
Q-B03:
What is authentication intent?
A-B03:
Authentication intent is the process of demonstrating that an individual intended to authenticate. Establishing authentication intent – like entering an OTP from a device, inserting a smart card, or simply touching the device (known as proof of presence) – can act as a countermeasure against malware using the endpoint as a proxy for authenticating an attacker without the user’s knowledge. This makes it more difficult for the authenticator to be used for nefarious purposes outside the control of the legitimate user.
Настоятельно рекомендую всем прочитать оригинальную версию документа и FAQ.
This comic pictures were originally published by xkcd.com, and are licensed under a Creative Commons Attribution-NonCommercial 2.5 License.
===========
Источник:
habr.com
===========
Похожие новости:
- [Информационная безопасность, Исследования и прогнозы в IT] Битва за роутеры: как ботнеты делят сферы влияния
- [Информационная безопасность, IT-инфраструктура, Реверс-инжиниринг, Исследования и прогнозы в IT] Тайны файла подкачки pagefile.sys: полезные артефакты для компьютерного криминалиста
- [Информационная безопасность, Виртуализация, Финансы в IT] Как подружить ГОСТ Р 57580 и контейнерную виртуализацию. Ответ Центробанка (и наши соображения на этот счет)
- [Информационная безопасность, Криптография, Алгоритмы, Математика] Отношения. Часть II
- [Информационная безопасность, Антивирусная защита, Восстановление данных, Резервное копирование] Новый релиз Acronis True Image 2021 — комплексная киберзащита и новые возможности
- [Информационная безопасность, PostgreSQL, Администрирование баз данных] Реализация ролевой модели доступа с использованием Row Level Security в PostgreSQL
- [Информационная безопасность, Социальные сети и сообщества, IT-компании] Вновь утечка: в сети оказались данные 235 миллионов пользователей Instagram, YouTube и TikTok
- [Информационная безопасность] «КОМРАД 4.0»: кросс-платформенная отечественная SIEM-система с дружественным интерфейсом и высокой производительностью
- [Информационная безопасность, Хакатоны, CTF] Реверс-инжиниринг программ, поиск веб-уязвимостей и две недели в Сочи: чего ждать студентам от «Кибервызова»
- [Информационная безопасность] Непрерывное тестирование безопасности и автоматическая оценка кибер-рисков с помощью платформы Cymulate
Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_passwords_security_nist_faq, #_informatsionnaja_bezopasnost (
Информационная безопасность
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 09:37
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Перевод наиболее интересных пунктов из FAQ для документа Digital Identity Guidelines от NIST (The National Institute of Standards and Technology) от 8 января 2020 года. Кому это может быть интересно? Всем пользователям компьютерных систем, кто хочет понимать причины по которым создаются те или иные требования систем безопасности. И может быть даже даст понимание как измененить собственное поведение, чтобы следовать более безопасным практикам. Разработчики и особенно специалисты по системам безопасности определённо должны ознакомится с этой информацией, так как в сегодняшней разработке, принцип «security first», актуален как никогда. Почему должны ориентироваться именно на информацию из NIST? NIST устанавливает стандарты, которые обязательны для следования правительственным учреждениям США, а также компаниям которые работают как подрядчики правительства. Т.е. довольно значительная часть компаний из США и крупные международные корпорации подпадают под эти правила. Многие страны и местные органы управления также создают стандарты политики безопасности базируясь на требования устанавливаемые NIST. Не удивлюсь тому что и Россия принимает их во внимание при создании национальных стандартов. Почему переведён FAQ, а не оригинальный документ? Потому что оригинальный документ написан в достаточно сухом, канцелярском стиле, а FAQ поживее и содержит объяснения лежащие в основе принятия тех или иных решений. Почему только часть FAQ? Потому что TL;DR. Каюсь, сам грешен, слишком длинные статьи сложно читать (и что гораздо важнее понимать), если статья не относится непосредственно к твоей области деятельности. Поэтому переведены только самые важные и интересные (на мой субъективный взгляд) пункты. Если у сообщества возникнет желание, то я думаю профессиональные переводчики от одного из корпоративных блогов, легко переведут полную версию. Небольшой disclaimer перед началом. Я не являюсь профессиональным переводчиком (и даже любителем), это второй перевод в моей жизни, на первый (сделанный лет 20-ть назад) мне пришла рецензия – «не присылайте переводов сделанных Prompt-ом», хотя всё было сделано используя исключительно толковый словарь. Это будет попытка номер два (надеюсь что получше), но не удивлюсь комментариям где prompt, будет заменен на google (тем более в этот раз это будет частично правдой), а остальное останется как есть. На данный момент, в качестве разработчика, я занимаюсь интеграцией одного из провайдеров аутентификации и мне показалось что некоторые пункты из FAQ, идущие вразрез с сегодняшними общепринятыми практиками будут очень интересны для русскоязычного сегмента сети. Через год-два, будет заметно как эти правила начнут реализовывать во многих корпоративных системах. Выброчные пункты из NIST Special Publication 800-63: Digital Identity Guidelines, Frequently Asked Questions Почему более не рекомендуется ограничивать срок действия пароля? От пользователей системы НЕ СЛЕДУЕТ требовать изменения паролей на основе некоторых правил (например периодически, раз в три месяца и т.п.). Однако владельцы системы ДОЛЖНЫ начать процедуру принудительной смены паролей, если существует подозрение что система аутентификации была скомпроментированна. Пользователи склонны выбирать более слабые пароли, если они знают, что в ближайшем будущем их потребуют снова сменить. И когда пароли будут поменяны, зачастую пользователи выберут пароль, который будет очень похож на их старый пароль, просто применив некоторое преобразование, например увеличение значения числа в пароле. Подобное поведение дает ложное ощущение безопасности, поскольку если какой-либо из предыдущих паролей был скомпрометирован, хакер может угадать предыдущий пароль применив подобные правила. Но если есть подозрение того, что система аутентификации была скомпрометирована, например, в результате взлома базы данных паролей, то следует потребовать принудительное изменение паролей от ваших пользователей.  Оригинал B05SPLQ-B05:
Is password expiration no longer recommended? A-B05: SP 800-63B Section 5.1.1.2 paragraph 9 states: “Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.” Users tend to choose weaker memorized secrets when they know that they will have to change them in the near future. When those changes do occur, they often select a secret that is similar to their old memorized secret by applying a set of common transformations such as increasing a number in the password. This practice provides a false sense of security if any of the previous secrets has been compromised since attackers can apply these same common transformations. But if there is evidence that the memorized secret has been compromised, such as by a breach of the verifier’s hashed password database or observed fraudulent activity, subscribers should be required to change their memorized secrets. However, this event-based change should occur rarely, so that they are less motivated to choose a weak secret with the knowledge that it will only be used for a limited period of time. Правда ли что больше не стоит заставлять пользователей использовать разные группы символов при выборе пароля? Мы более не рекомендуем использовать правила композиции при выборе пароля (например, требовать обязательного включения строчных и прописные буквы, цифр и/или специальных символов). Как показала практика, эти правила дают меньше преимуществ, чем можно было бы от них ожидать, потому что пользователи склонны использовать предсказуемые методы для удовлетворения этих требований (например, добавление ! в конце пароля, когда правила требуют иметь специальный символ в его составе). Подобные требования зачастую выполняются формально, что не способствует выбору хорошо запоминающегося, но сложного для подбора пароля. Черный список наиболее употребимых паролей решает данную проблему более эффективно, особенно для онлайн-сервисов. Подобные правила также непреднамеренно побуждают людей использовать один и тот же пароль во множестве различных систем, поскольку они часто приводят к тому, что такие пароли трудно запомнить.  Оригинал B06SPLQ-B06:
Are password composition rules no longer recommended? A-B06: SP 800-63B Section 5.1.1.2 paragraph 9 recommends against the use of composition rules (e.g., requiring lower-case, upper-case, digits, and/or special characters) for memorized secrets. These rules provide less benefit than might be expected because users tend to use predictable methods for satisfying these requirements when imposed (e.g., appending a! to a memorized secret when required to use a special character). The frustration they often face may also cause them to focus on minimally satisfying the requirements rather than devising a memorable but complex secret. Instead, a blacklist of common passwords prevents subscribers from choosing very common values that would be particularly vulnerable, especially to an online attack. Composition rules also inadvertently encourage people to use the same password across multiple systems since they often result in passwords that are difficult for people to memorize. Можно ли использовать ОГРАНИЧЕННО НАДЁЖНЫЕ факторы аутентификации и какие дополнительные усилия должны быть предприняты, если ваша система их использует? По мере развития угроз, некоторые факторы аутентификации становятся менее надежными, поэтому было решено использовать термин «ОГРАНИЧЕННО НАДЁЖНЫЙ», чтобы обозначить факторы аутентификации которые не реализуют надёжный уровнь защиты. Команда криптографии NIST также использует подобное название и мы пытаемся не плодить дополнительные сущности без надобности. Реализация «ограниченно надёжного» фактора аутентификации требует от владельца системы оценки, понимания и принятия рисков, связанных с использованием этого типа аутентификации. Необходимо:
В настоящее время факторы аутентификации использующие телефонную сеть общего пользования, голосовые одноразовые пароли (OTP) и сообщения SMS, считаются «ограниченно надёжными». Обратите особое внимание, что при использовании голосовых сообщений и SMS используется телефонная сеть, а не VoIP системы, поскольку они считаются ненадёжной системой и обычно менее защищены. Оригинал B01SPLQ-B01:
What is a RESTRICTED authenticator and what do providers have to do differently if they use one? A-B01: As threats evolve, some authenticators become less reliable, so we established the notion of “RESTRICTED” to tag authenticators if they become of concern. We didn’t make this up: the NIST cryptography team has been using this approach for some time, and we like to be consistent with other NIST efforts so we don’t confuse our stakeholders. Implementing a RESTRICTED authenticator requires the agency to assess, understand, and accept the risk associated with that authenticator. Therefore, the agency needs to:
Currently, authenticators leveraging the public switched telephone network, including phone- and Short Message Service (SMS)-based one-time passwords (OTPs) are restricted. Other authenticator types may be added as additional threats emerge. Note that, among other requirements, even when using phone- and SMS-based OTPs, the agency also has to verify that the OTP is being directed to a phone and not an IP address, such as with VoIP, as these accounts are not typically protected with multi-factor authentication. Что это такое — намерение начать аутентификацию? Намерение начать аутентификацию — это физический процесс который демонстрирует, что это реальный человек намеривается аутентифицироваться в самом ближайшем времени. Использование этого факта — например, ввод OTP, вставка смарт-карты или прикосновение карточкой (всё это известно как доказательство присутствия) — может выступать в качестве дополнительной меры противодействия вредоносному ПО, использующему скомпрометированную систему в качестве прокси для аутентификации злоумышленника без участия пользователя. Это затруднит возможность не авторизированного использования системы. Оригинал B03SPLQ-B03:
What is authentication intent? A-B03: Authentication intent is the process of demonstrating that an individual intended to authenticate. Establishing authentication intent – like entering an OTP from a device, inserting a smart card, or simply touching the device (known as proof of presence) – can act as a countermeasure against malware using the endpoint as a proxy for authenticating an attacker without the user’s knowledge. This makes it more difficult for the authenticator to be used for nefarious purposes outside the control of the legitimate user. Настоятельно рекомендую всем прочитать оригинальную версию документа и FAQ. This comic pictures were originally published by xkcd.com, and are licensed under a Creative Commons Attribution-NonCommercial 2.5 License. =========== Источник: habr.com =========== Похожие новости:
Информационная безопасность ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 09:37
Часовой пояс: UTC + 5