Проверка сложности пароля: отличается от последних паролей X - PullRequest
6 голосов
/ 01 сентября 2011

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

"Новый пароль должен содержать Y символовиз последних X паролей. "

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

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

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

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

Ответы [ 3 ]

2 голосов
/ 01 сентября 2011

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

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

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

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

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

На самом деле это довольно умная идея.

1 голос
/ 01 сентября 2011

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

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

РЕДАКТИРОВАТЬ:

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

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

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

0 голосов
/ 01 сентября 2011

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...