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

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

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

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

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

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

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

6
encryption passwords security

3 ответов

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

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

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

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

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

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

2

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

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

EDIT:

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

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

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

1

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

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

0