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

Однако обычно у вас есть требование хранить последние n паролей и обеспечивать минимальную сложность и минимальное изменение между различными паролями (чтобы пользователь не мог использовать последовательность, такую ​​как Password_1, Password_2, ..., Password_ n ). Это было бы тривиально с простыми текстовыми паролями, но как вы можете сделать это, сохраняя только хэши?

Другими словами: как можно реализовать механизм безопасной истории паролей?

Сохраняйте хеши и проверяйте введенный пароль на основе этих хеш-кодов, так же, как вы проверяете пароль при входе в систему. Вам потребуется сгенерировать «альтернативные» пароли из тех, которые указаны на основе числовых шаблонов, чтобы обнаружить ваши «минимальные» изменения.

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

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

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

чтобы добавить к ответу @ martijnPieter, минимальное изменение может быть реализовано с помощью короткой грубой силы, основанной на новых и предыдущих паролях (которые вы оба имеете в наличии)

например, вы можете перебрать все пароли с расстоянием Хэмминга 1 или 2 от нового пароля и посмотреть, соответствует ли он старому проходу

но вы можете заметить, что это может снизить уверенность пользователей в том, что вы хэшируете пароли (поскольку вы, по сути, говорите, что вы можете вернуть предыдущий пароль, чтобы отклонить новый пароль)

Это действительно скорее дополнение к умному ответу @ Брайана. Снимаю шляпу перед @Martijn Pieters за добавление подробностей о том, как перебрать старые пароли на основе текущего, и у @ratchet freak за «расстояние Хэмминга». Я не удаляю свой ответ, потому что я думаю, что он обеспечивает интересную основу для их поддержки.

Современное хранилище паролей требует использования нескольких циклов надежного одностороннего криптографического хэша (SHA-512 +) с уникальной солью (128 бит +) для каждого пользователя. Но не поддавайтесь искушению хранить дополнительную информацию о каждом пароле. Чем больше информации вы будете хранить о каждом пароле, тем больше вы подрываете безопасность вашего алгоритма хеширования.

пример

Подумайте, как легко взломать пароль, если вы знаете, что:

• Это 7 символов в длину
• Символы 3-5 в верхнем регистре (4 ниже)
• 1 и 7 числа
• 6 является символом

Американская клавиатура имеет 95 печатаемых символов, поэтому, зная, что пароль длиной 7 символов, получается 95 ^ 7 = 69 833 729 610 000 = 7x10 ^ 13 перестановок. Если бы это было действительно случайно, то на взлом одного процессора 3Ghz потребовался бы год. Но:

• Есть только 26 заглавных и 26 строчных букв
• Есть только 10 цифр, дающих 100 возможностей для этих двух чисел
• Всего 32 символа

Итак (исправлено благодаря @Hellion):

         26^4 (charcters 2-5 are known upper or lower-case)
        x 100 (characters 1 & 7 are digits)
        x  32 (character 6 is a symbol)
         ====
1,462,323,200 possible passwords.

Это в 50000 раз легче взломать! Хранение полезной информации для предотвращения подобных паролей в этом случае заняло у вас время взлома 7-символьного пароля с года до пары часов. Расшифровка всех ваших паролей на мощном многопроцессорном рабочем столе с хорошей видеокартой и небольшим терпением теперь вполне осуществима. Я надеюсь, что этот простой пример демонстрирует, что чем более содержательно вы сможете сравнить похожие пароли, тем менее безопасным будет ваше хеширование.

Важность сильного хеширования

Базы данных с паролями регулярно крадут, с огромными взломами в новостях каждый месяц. Черт, только в прошлом месяце штат SC потерял все номера социального страхования - упс! Сколько еще этих нарушений скрыто?

Заключительная мысль

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

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

Если (для вас) очень важно напрямую сравнить эти два пароля с «n» предыдущими паролями, то вы должны хранить эти пароли (зашифрованные), чтобы иметь возможность восстановить их позже.

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

1. Сохраните каждый пароль (зашифрованный) для последних «n» паролей.
2. Сохраните дату и время, когда был создан самый последний пароль.
3. Сохраните хэш самого последнего пароля.
4. Зашифруйте все пароли, используя хэш (соленый) текущего пароля, а также временную метку создания пароля и, возможно, что-то вроде номера учетной записи или адреса электронной почты.
5. Отключайте шифрование и повторно шифруйте все пароли каждый раз, когда создается новый пароль.

Затем, в любое время, когда вы меняете пароль, вы можете дешифровать все старые пароли и выполнить все свои тесты с минимальными изменениями.

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

Кроме того, для старых паролей их не обязательно хранить в виде простого текста. Они могут храниться каким-то запутанным способом. Или хранится в виде алфавитного списка символов в пароле.

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