Сложность пароля DoD: пользователи не могут повторно использовать любой из своих предыдущих паролей X

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

по данным "безопасность приложений и разработка STIG, V3R2", секция 3.1.24.2 сложность и обслуживание пароля, программное обеспечение предприятия Дод имеет довольно жесткую директиву с пароли:

  • пароли должны быть длиной не менее 15 символов.

  • пароли должны содержать сочетание прописных букв, строчных букв, цифр и специальных символов.

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

  • пароли должны истечь после 60 дни.

  • пользователи не должны иметь возможность повторно использовать любой из своих предыдущих 10 пароли.

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

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

Как говорится в сообщение NullUserException, для разработчика, чтобы на самом деле иметь возможность проверить для последнего x количество паролей (а также убедитесь, что новые пароли отличаются от предыдущего пароля [6]), пароли должны быть зашифрованы с помощью обратимого метода, а не хэширования пароля (что намного больше небезопасно, даже если я использую одобренные АНБ алгоритмы шифрования). Предложенный ответ, казалось, имел смысл, хотя, казалось, были некоторые расхождения и аргументы, как видно из Дэн Винтон-х.

Я думаю, что реальный вопрос здесь,кто-нибудь смог реализовать все эти, казалось бы, общие ограничения сложности пароля без фактического снижения безопасности их системы?

Edit: уязвимость APP3320.7 (пункт 6 маркера) гласит: "убедитесь, что приложение имеет возможность требовать, чтобы новые пароли учетной записи отличались от предыдущего пароля не менее чем на четыре символа при изменении пароля."Это заставляет меня поверить, что мне придется запустить алгоритм подобия строк, такой как Levenshtein, чтобы проверить подобие. Я не могу сделать это на хэш-соли. Пожалуйста, дайте мне знать, если я ошибаюсь?

6
complexity-theory encryption passwords security

3 ответов

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

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

12

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

1

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

ограничение истории паролей до " последнего N "и, следовательно, ограничение частоты изменения пароля до" Один раз в день " имело смысл, когда пространство для хранения было непомерно дорого, но не имеет смысла сегодня, когда хранение очень дешево. Гораздо более разумной политикой является " новые пароли должны не быть таким же, как любые известные старые пароли" и оставить его на этом. Отбросьте" последнее N "и отбросьте правило" max once daily", которое существует только для того, чтобы пользователи не обходили историю.

некоторые системы управления паролями поддерживают эту конфигурацию (и поддерживают ее в течение многих лет). Пример: https://hitachi-id.com/password-manager/features/password-policy-enforcement.html

-1