Проверка сложности пароля: отличается от последних X-паролей

Question

Большинство служб, программ и т. Д. Имеют различные проверки сложности пароля. Не углубляясь в efficacy of such checks, я подумал о той, которая могла бы быть интересной, но и потенциально проблематично проверить:

«Новый пароль должен быть Y персонажи отличаются от последних X паролей.»

Это помешает людям использовать пароли, такие как Password1!, Password2! и так далее. Но если это будет сделано, нельзя использовать hash ранее использованный пароль - они были бы в лучшем случае зашифрованы ... Правильно?

Для небольшого Y и довольно короткий пароль, вы, вероятно, по-прежнему хранить хэш и BruteForce все Y письмо вариации нового пароля, но это становится невозможным, как Y и длина пароля растет.

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

Так что если активный пароль всегда хэширован, есть ли лучший способ сделать это? А также имеет ли это на месте увеличить или уменьшить безопасность приложения?

Answer 1

Я попытался поставить это в комментарии, но я думаю, что это достаточно важно, чтобы ответить.

Схема, предложенная ОП, является не обязательно нарушением CWE-257. Предложение не позволяет системному администратору (скажем) восстановить старые пароли.

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

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

Действительно, это не защищает от «атаки» сотрудника, который пишет свою собственную утилиту для смены пароля, чтобы обойти ограничения пароля, поскольку проверка не выполняется на стороне сервера. Но это никоим образом не является нарушением CWE-257, на мой взгляд.

Это на самом деле разумно умная идея.

Answer 2

Шифрование паролей является явным нарушением CWE-257, а за него должно быть никогда не должно быть. Однако в случае истекшего пароля пользователь только что вошел в систему, чтобы сохранить простой текст этого пароля. Затем заставьте пользователя изменить пароль и исчислите hamming distance между ними. Как только пользователь предоставит пароль, который отличается от другого, хеш этот новый пароль и выбросить простой текст.

EDIT: Вы можете сохранить соль + хэш всех старых паролей, чтобы убедиться, что пользователь не выбирает пароль, который у него был в прошлом. Но, соблюдая, что пароль - это N символов, отличных от всех паролей, ослабляет систему в целом и стоит дорого, так как это потребует o (n) сравнений.

Answer 3

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

Я понимаю, что это напрямую не касается требования, как изначально поставленного (отличного от последних X-паролей), но я чувствую, что это фиктивное требование. Для вашего требования потребуются обратимые пароли (механизм не имеет значения), и большинство экспертов согласятся с тем, что это неверно. Я считаю, что вы просто неверно истолковали требования Oracle, если это действительно то, что вызывает этот вопрос.

EDIT:

ОК, я просто подумал, что способ реализации того, что вы просите без обратимых паролей. Я все еще думаю, что вы неправильно интерпретируете требование Oracle, и я бы не стал делать то, что собираюсь описать сам, но он будет отвечать требованиям без обратимых паролей.

1. Выберите зарезервированный символ, который не может отображаться в реальном пароле. Для обсуждения предположим, что это обратная косая черта.
2. Перечислите все возможные способы замены не более Y обратных косых черт в пароле, хэшируя результат каждый раз.
3. Поддерживайте только самые последние Х-множества хэшей, созданных таким образом.
4. Когда пользователь выбирает новый пароль, повторите процедуру на тендерном пароле и сравните его отдельные хэши с отдельными недавними хэшами.

Гуфи, но это должно соответствовать требованию.