Как создать безопасные пароли для новых пользователей?

Question

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

Мне нужно, чтобыбыть видимым, чтобы администратор мог распечатать пароли и раздать их родителям.Но я также хочу, чтобы они были в безопасности в случае взлома базы данных.Есть идеи?

Answer 1

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

Вам может быть интересно ознакомиться со следующими сообщениями переполнения стека для дальнейшего чтения:

• Разница между хэшированием пароля и его шифрованием
• Как мне этически подходить к хранению пароля пользователя для последующего получения открытого текста?

Answer 2

Вы не должны этого делать.

Создайте одноразовый пароль, который можно использовать (и также можно сохранить в виде открытого текста) для установки нового пароля через Интернет.

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

Answer 3

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

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

Удачи.

Answer 4

Хранить пароли в 2 формах:

1) Хэш MF5 / SHA1 для безопасной проверки

2) AES с мастер-паролем. То есть для просмотра паролей вы вводите мастер-пароль и бинго. В случае кражи злоумышленник не получит пароли так просто (но может перебор).

Answer 5

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

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

Чтобы получить пароль, используйте закрытый ключ (защищенный, то есть на другом изолированном компьютере), чтобы расшифровать пароль + соль и выбросить соль.

Минусы: асимметричное шифрование может быть дорогим в вычислительном отношении, но пароли, как правило, короткие.

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

Answer 6

Вы можете иметь один XOR другой.

• Если пароли должны быть безопасными, вы не должны хранить их в базе данных (хранить some_hash(per_user_salt + password) и сравнивать их при входе в систему (как говорит @ Даниэль Вассалло )

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