магазин хэшированных паролей к Mysql

Question

Я изучал хеширование и хранение паролей в базе данных на PHP.NET. Этот сайт сказал (а):

Если вы, например, храните данные в базе данных MySQL, помните, что поля varchar автоматически сохраняют пробелы во время вставки. Поскольку зашифрованные данные могут заканчиваться в пространстве (ASCII 32), данные будут повреждены при этом удалении. Храните данные в поле tinyblob/tinytext (или больше).

какие из этих предложений лучше? или, может быть, я должен спросить: один из них лучше? и если ответ «да», что? и, наконец, как хранить пароли в db с помощью PDO. Я думал, что могу писать информацию в строку blob точно так же, как файлы, но если я получаю значения от ввода, какой метод или функция должны использоваться? Не могли бы вы объяснить, пожалуйста?

Answer 1

При хранении хеширования паролей, то пробельные удаление не является проблемой:

• Вы никогда не хранить пароли сами, но на выходе хэш-функции вместо.
• Эта хеш-функция производит выходной сигнал фиксированного размера (или вы, вероятно, используете обратимый алгоритм )).
• Выход большинства функций хеширования - это обычный текст фиксированного размера ^[1], который не содержит пробелов. В противном случае вы, вероятно, используете хеш-функцию, не предназначенную для хэширования паролей.
• Соль хранится вместе с хеш-выходом (функции хеширования пароля, которые знают о засолении, обычно выводят соль с хешированным паролем).
• Если вы хотите быть гибким и в будущем сможете перейти на более эффективную функцию хэширования, вам также необходимо запомнить, какая функция хэша была использована. Для этой информации рекомендуется использовать plaintext ^[1], что делает полную запись переменной длины. RFC 2307 описывает такой возможный открытый текст ^[1] схема хранения.

Пароли должны быть хэшированы с использованием современного и проверенного алгоритма key-stretching, но не с криптографическими хеш-функциями, такими как SHA-256 или MD5. Подходящие алгоритмы включают PBKDF2, bcrypt, или scrypt.

Например, хеширования строку «фразу» с Bcrypt и новая соль может производить

$2a$12$PuYHvYwgKeD.hQ1Dv6nLQuxUkv5zP3lYLPHqdMOzgwPVaGGSAs07u 
`-----'`-----------·······     ·········-------' 
algorithm  random salt     password hash 
parameters 

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

Рекомендуемая последовательность действий для проверки попытку входа в систему:

1. Пользователь предоставляет имя пользователя и пароль. Будьте осторожны с нормализацией и кодировкой Unicode.
2. Хешированный пароль извлекается из БД на основе имени пользователя.
3. Анализируется код хеширования для определения используемого алгоритма.
4. Правильный алгоритм вызывается с паролем пользователя как вход с хешированным паролем в виде соли.
5. Если два хэша совпадают, то пользователь предоставил правильный пароль.

Рекомендуемая последовательность действий для установки нового пароля:

1. Если пользователь уже существует, то подлинность его.
2. Получите новый пароль от пользователя. Позаботьтесь о нормализации и кодировании Unicode. Дайте пользователю обратную связь по силе его пароля (но не расстраивайте пользователя с глупыми требованиями, такими как запрещенные символы или ограничительные максимальные длины).
3. Создайте новую соль, которая не должна зависеть от ввода пользователя, такого как пароль или имена пользователей.
4. Выберите надежную функцию хэширования пароля и введите пароль с новой солью.
5. Обновите БД, чтобы сохранить новый пароль вместе с идентификатором хеш-функции.

Дополнительные комментарии:

• Зашифрованные данные двоичные данные, и не должны быть сохранены в виде текста (используйте блоб вместо этого).
• Хеши обычно часто представлены как открытый текст, а не как двоичные данные, потому что текст легче хранить.
• Во многих сценариях вы можете использовать OpenID вместо реализации собственной аутентификации. Например. Stack Exchange предлагает логин с OpenID. Поскольку я использую этот параметр, мне никогда не приходилось раскрывать пароль для SE.
• У меня нет криптографического фона. Information Security часто посещают людьми, которые понимают больше.

---

^{[1] Здесь, «открытый текст» означает печатные символы ASCII. Он не относится к четкому тексту пароля.}