Комментарии 8
И значительная часть описанных здесь рекомендаций почему-то противоречит рекомендациям NIST
14 символов
При достаточно медленном хэше достаточно и 8 символов (рекомендация NIST). Если в том же PBKDF2 накрутить итераций побольше, то «100 миллиардов хэшей в секунду» не получится. Ну и и про какой-нибудь Argon2 тоже не забываем
требуется хотя бы 1 неалфавитный символ
Пароль correcthorsebatterystaple считает эту рекомендацию вредной, NIST тоже
срок действия пароля — один год
Крайне вредная рекомендация! Пользователи слишком ленивы, чтобы регулярно придумывать новые и достаточно надёжные пароли, поэтому при принудительной смене они просто будут менять одну букву или цифру в старом пароле (я так в своём Qiwi-кошельке уже несколько лет делаю). Ну а если заставлять пользователя придумывать полностью непохожий пароль, то они вместо запоминания начнут записывать его на стикере на мониторе (и об этом даже написано в посте, лол) и вся безопасность улетит в ноль. С поправкой на лень пользователей оказывается безопаснее придумать одну длинную парольную фразу (снова привет от correcthorsebatterystaple) и использовать её до утечки или пока у пользователей не пройдёт лень
Впрочем, во второй части (ещё не переведённой здесь) упоминается интересный кейс — когда пользователь использует один пароль на двух сайтах, на одном произошла утечка, а про второй сайт пользователь забыл и давно туда не заходит. Возможно, в таком случае действительно имеет смысл затребовать смену пароля на неактивном аккаунте — но только на неактивном!
Задержка до следующие смены пароля: 1 день и более
Кажется, у NIST про это ничего не сказано, но я не очень понял, в чём практической смысл этой рекомендации. Зато вижу потенциальный вред: если вдруг после смены пароля случайно выяснится, что новый пароль оказался скомпрометирован, то пользователю целый день сидеть с небезопасным паролем, что ли?
перманентная блокировка аккаунта [...] после 10 неудачных попыток
Очень удобно для злоумышленника, получившего доступ к форме входа — можно заблокировать любого пользователя, тупо введя неправильный пароль десять раз. Насчёт закрытых систем не знаю, но в открытых системах (например, на интернет-сайтах) так делать точно нельзя. NIST в своих рекомендациях упоминает rate limiting, но про блокировку я там тоже ничего не нашёл
Автоматическая блокировка аккаунта после 45 дней без входа в систему
Возможно, в каких-то супер-критичных к безопасности системах это может иметь смысл, но для «обычных» систем выглядит как чрезмерная паранойя. Например, я на некоторые сайты захожу раз в полгода-год, потому что чаще мне просто не надо
Картинка красивая, трактовка абсолютно неверная... Ибо слов в словаре ну, допустим 10 в 6 степени, да четыре раза - получаем 10 в 10 степени или меньше, чем 2 в 34 степени... Итого: максимум 34 бита может быть, а с уменьшением размера словаря всё намного хуже становится!
Квадратики на картинке — это биты и есть.
Он говорит про атаку по словарю, считая за единицу энтропии не символ, а слово целиком. И если так считать, то стойкость пароля действительно оставляет желать лучшего. Тут правда "есть один нюанс", чтоб проводить подобную атаку нужно быть уверенным, что пользователь использовал именно такую технику для создания пароля. И еще иметь весьма объемный словарь. Возможно национальный. И любой спецсимвол, цифра или ошибка в слове делает подобный перебор бесполезным. В общем техника весьма годная.
Кажется, у NIST про это ничего не сказано, но я не очень понял, в чём практической смысл этой рекомендации. [интервал времени после смены пароля, когда его запрещается менять еще раз]
Смысл очень простой. Была когда-то рекомендация "пароль не должен совпадать с пятью предыдущими". Смена пароля шесть раз подряд без задержек (где шестой пароль совпадает с первоначальным) была способом обхода этой рекомендации. Введением задержки лазейку прикрыли. Иными словами, смысл - предотвратить саботаж политики обязательной смены пароля через год.
Всегда умиляют статьи со вставленными таблицами в виде картинок: или автор (переводчик) не умеет в таблицы в разметке, либо не хочет, чтобы его перевод копипастили :)
Это все конечно хорошо, но как быть среднему ИТаутсорсеру у которого несколько десятков клиентов у каждого из которых по несколько десятков сервисов и по сотне другой устройств. при это штат специалистов исчисляется десятком человек?
Как быть в такой ситуации?
Публикации
Руководство по парольной политике. Часть 1