Национальный институт стандартов и технологий США (NIST) опубликовал второй открытый проект новой версии руководства по цифровой идентификации. В него вошли обновленные правила, касающиеся паролей, которые выглядят вполне разумными.
Пароли доставляют головную боль и разработчикам, и пользователям. Слишком слабые пароли не обеспечивают никакой защиты, слишком сильные - слишком легко запереть личные данные в непроницаемом сейфе. В большинстве случаев я с радостью принимаю сложный пароль, который предлагает мне новое приложение, возможно, сначала усекая его, что, признаюсь, ослабляет его, а затем позволяю Chrome сохранять и извлекать его по мере необходимости. Но пробовали ли вы когда-нибудь набрать на мобильном устройстве один из тех сложных паролей, которые содержат сочетание заглавных и строчных букв, а также цифр и специальных символов? Это просто кошмар. И если раньше можно было обойтись только настольными приложениями, то теперь все больше и больше мобильных приложений навязываются нам для таких жизненно важных задач, как интернет-банкинг.
Поэтому мы с большим облегчением обнаружили, что пересмотренные рекомендации включают:
«5. Верификаторы и CSP НЕ ДОЛЖНЫ устанавливать другие правила составления паролей (например, требовать сочетания различных типов символов)».
Верификатор» в данном контексте - это организация, которая проверяет личность владельца учетной записи, подтверждая его полномочия аутентификации, а CSP означает „credential service provide“, то есть доверенная организация, которая назначает или регистрирует аутентификаторы для владельца учетной записи.
Обратите внимание на использование «SHALL NOT», для которого NIST использует заглавные буквы, чтобы мы не могли пропустить указание. В прошлом рекомендации NIST по паролям выражались в терминах «следует» и «не следует». Теперь в них используются слова «SHALL/SHALL NOT» для правил, которые считаются обязательными, и «SHOULD» для тех, которые, хотя и являются лучшей практикой, имеют некоторую свободу действий.
Правило, занимающее первое место в списке, демонстрирует разницу между SHALL и SHOULD:
«1. Верификаторы и CSP ОБЯЗАНЫ требовать, чтобы длина паролей составляла не менее восьми символов, и ДОЛЖНЫ требовать, чтобы длина паролей составляла не менее 15 символов».
Итак, минимум 8 символов в пароле обязательны, а минимум 15 - предпочтительны.
Должен признаться, что меня смутило следующее правило:
«2 . Верификаторы и CSP ДОЛЖНЫ разрешать максимальную длину пароля не менее 64 символов».
Предположительно, это относится к парольным фразам, но «максимальная» и «не менее» не очень хорошо сочетаются - слава богу, что это просто «следует».
Следующие два правила призывают (SHOULD) разрешить использование в паролях всех печатных символов ASCII, пробела и символов Юникода.
Еще одно изменение, которое приветствуется, - положить конец «устаревшему требованию» регулярно менять пароль, что, как правило, отталкивает пользователей от использования паролей высокой стойкости:
«6. Верификаторы и CSP НЕ ДОЛЖНЫ требовать от пользователей периодической смены паролей. Однако верификаторы ОБЯЗАНЫ принудительно сменить пароль, если есть доказательства компрометации аутентификатора».
Хотя меня уже давно не просили указывать «подсказку» для запоминания пароля, мой самый используемый пароль для входа в компьютер показывает подсказку, которую я задал для него несколько раз в день. Это самый слабый из всех моих паролей. Но мне бы не хотелось менять его через 20, нет, 30, 40 или больше лет. Такое еще случается? Ну, если да, то скоро это будет запрещено обновленным правилом 7:
«7. Верификаторы и CSP НЕ ДОЛЖНЫ разрешать абоненту хранить подсказку, доступную неаутентифицированному претенденту».
Я часто размышлял о том, насколько небезопасны в качестве вопросов безопасности «девичья фамилия матери» и «имя первого домашнего животного», в особенности «город, в котором вы родились». Для большинства людей они вряд ли являются секретами, но если использовать их в качестве вопросов безопасности после того, как вы прошли стадию ввода пароля, их использование не кажется слишком плохим. По крайней мере, у легитимного пользователя есть шанс их запомнить. Однако при выборе паролей пользователям предлагается полагаться на такую аутентификацию, основанную на знаниях:
«8. Верификаторы и CSP НЕ ДОЛЖНЫ предлагать абонентам использовать аутентификацию на основе знаний (KBA) (например, «Как звали вашего первого питомца?») или вопросы безопасности при выборе паролей».
Окончательное правило исключает лень со стороны верификаторов - практика, с которой я и так не сталкивался
«9. Верификаторы ОБЯЗАНЫ проверять весь введенный пароль (т. е. не усекать его)».
В целом эти предложенные лучшие практики выглядят неплохо - и еще есть время высказать свое мнение: NIST приглашает людей отправить комментарии к рекомендациям по адресу dig-comments@nist.gov до 23:59 по восточному времени 7 октября.
32Компания Microsoft объявила об обновлении системы безопасности и конфиденциальности своей функции Windows Recall, работающей на основе искусственного интеллекта, которую теперь можно удалить, а также о более надежной защите пользовательских данных по умолчанию и более жестком контроле доступа.
15Критическая уязвимость в NVIDIA Container Toolkit затрагивает все приложения искусственного интеллекта в облачной или локальной среде, которые используют его для доступа к ресурсам GPU.
16Министерство юстиции США обнародовало обвинительное заключение, в котором три иранских хакера обвиняются в кампании «взлома и утечки», целью которой было повлиять на президентские выборы в США в 2024 году.
23Продолжаем добавлять языки программирования для Вас.
Впереди много интересного!
Только свежие новости программирования и технологий каждый день.
Комментарии