Прямо не связано, но возникло в связи с Pwned Passwords Validator, так как мы в последнее время рассматриваем усиление валидации паролей.
Похоже, Discourse не блокирует пароли вроде myusername123 или 4myusername для имени пользователя myusername.
Я не нашёл предыдущих обсуждений именно такого типа слабых паролей. Это уже рассматривалось ранее?
Я не против добавить проверку, чтобы при выборе пароля «пароль не должен содержать username_lower» — это кажется мне разумным.
Мы уже проверяем случай password = username, но я не очень люблю проверки на подстроку, особенно для коротких имён пользователей. Что, если ваше имя пользователя — «Ed», а пароль — случайная строка, которая случайно содержит «ed»..
Использовать метрику сходства, например, расстояние Левенштейна (Levenshtein distance), и отклонять запрос, если levenshtein(username, password) < 6? Или даже добавить проверку на перестановки, например:
levenshtein(sort_by_chars(username), sort_by_chars(password)) < 6
Кажется, это покроет самые грубые нарушения, не запрещая пользователю с именем «Ed» зарегистрироваться с длинным и надёжным паролем. К тому же это легко объяснить: «имя пользователя и пароль слишком похожи». Я не искал нежелательные крайние случаи, но в данный момент не могу придумать ни одного.
Связанный твит от сегодня:
Обратная сторона «всё более и более» строгих правил заключается в том, что подбор паролей методом грубой силы становится проще.
Очевидно, что в пароле длиной 15 символов или меньше буква z не должна повторяться 10 раз.
Очевидно, что слово password не должно встречаться в пароле, если его длина меньше 12 символов.
Два слова из словаря подряд — это явно неправильно…
И так далее. Таким образом, пространство для перебора паролей сокращается.
Это кроличья нора: после размышлений я изменил своё мнение относительно вчерашнего. Я согласен с @codinghorror: я не думаю, что нам нужно что-то делать в данном случае.
«Сложно создать хорошие правила, поэтому мы не должны создавать правила»?
Это уже второй раз за два дня, когда я вижу, что высокопоставленные члены команды Discourse распространяют серьёзные заблуждения о безопасности. Мне кажется, есть несколько общих моментов, которые вам стоит пересмотреть, и я надеюсь, что вы воспримете это как конструктивную критику.
Кроме того, это конкретное предложение возникло не на пустом месте: недавно у нас был взломан аккаунт пользователя, потому что имя пользователя было myusername, а пароль имел вид myusername46.
Конечно, это был сайт ClassicPress (та же структура входа, что и в WordPress), поэтому он гораздо более «лёгкая добыча» для ботов и т. п. Однако именно такие пароли ищут боты.
Правила паролей не могут предотвратить все виды слабых паролей, но они могут значительно помочь.
Технически мы следуем руководящим принципам NIST 800-63-B:
При обработке запросов на создание и изменение запоминаемых секретов верификаторы ДОЛЖНЫ сравнивать предполагаемые секреты со списком, содержащим значения, которые, как известно, часто используются, ожидаемы или скомпрометированы. Например, этот список МОЖЕТ включать, но не ограничивается:
- Пароли, полученные из предыдущих корпусов утечек данных.
- Слова из словаря.
- Повторяющиеся или последовательные символы (например, «aaaaaa», «1234abcd»).
- Контекстно-зависимые слова, такие как название сервиса, имя пользователя и их производные.
В документе явно используется слово МОЖЕТ, а не ДОЛЖНО. Следовательно, это остаётся на наше усмотрение. Здесь нет рекомендации по расстоянию Левенштейна. Возможно, стоит добавить правило: «если имя пользователя длиннее 6 символов, оно не должно входить в пароль», либо реализовать проверку энтропии поверх списка из миллиона паролей. Не знаю точно.
Я полагаю, если вы крайне заинтересованы в собственных правилах, вы можете развернуть SSO и установить любые правила на своей стороне. Либо написать плагин.
Вероятно, именно это мы и сделаем. Здесь ещё многое отсутствует, но пока что ответы не дают повода считать, что поднимать эту тему особенно целесообразно.
Пожалуйста, поделитесь созданным вами плагином с сообществом здесь, в категории #plugin. Не все согласны с каждым нашим решением, и я полностью уважаю разнообразие мнений и вариантов. Возможно, кому-то будут интересны более строгие правила паролей.