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

Question

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

Я думаю об ограничении паролей 4-20 символами, но, как я понимаю, после шифрования хеш-строка будет иметь другую длину.

Итак, как хранить эти пароли в базе данных?

Answer 1

Обновление: просто использование хэш-функции недостаточно для хранения паролей. Вы должны прочитать ответ Жиля в этой теме для более подробного объяснения.

Для паролей используйте алгоритм хеширования ключей, такой как Bcrypt или Argon2i. Например, в PHP используйте функцию password_hash () , которая по умолчанию использует Bcrypt.

$hash = password_hash("rasmuslerdorf", PASSWORD_DEFAULT);

В результате получается строка из 60 символов, похожая на следующую (но цифры могут отличаться, поскольку она генерирует уникальную соль).

$2y$10$.vGA1O9wmRjrwAVXD98HNOgsNpDczlqm3Jq7KnEd1rVAGv3Fykk1a

Используйте тип данных SQL CHAR(60) для хранения этой кодировки хэша Bcrypt. Обратите внимание, что эта функция не кодируется как строка шестнадцатеричных цифр, поэтому мы не можем так просто отменить ее, чтобы сохранить в двоичном формате.

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

---

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

• MD5 генерирует 128-битное хеш-значение. Вы можете использовать CHAR (32) или BINARY (16)
• SHA-1 генерирует 160-битное хеш-значение. Вы можете использовать CHAR (40) или BINARY (20)
• SHA-224 генерирует 224-битное хеш-значение. Вы можете использовать CHAR (56) или BINARY (28)
• SHA-256 генерирует 256-битное хеш-значение. Вы можете использовать CHAR (64) или BINARY (32)
• SHA-384 генерирует 384-битное хеш-значение. Вы можете использовать CHAR (96) или BINARY (48)
• SHA-512 генерирует 512-битное хеш-значение. Вы можете использовать CHAR (128) или BINARY (64)
• BCrypt генерирует зависящее от реализации 448-битное хеш-значение. Вам может понадобиться CHAR (56), CHAR (60), CHAR (76), BINARY (56) или BINARY (60)

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

Меньшие алгоритмы хеширования имеют свое применение (например, для внутреннего применения, а не для обмена), но они известны как взломанные .

Answer 2

На самом деле вы можете использовать CHAR (длину хеша), чтобы определить свой тип данных для MySQL, потому что каждый алгоритм хеширования всегда будет иметь одинаковое количество символов. Например, SHA1 всегда возвращает 40-значное шестнадцатеричное число.

Answer 3

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

Answer 4

Как строка фиксированной длины (VARCHAR (n) или как бы MySQL ее не называл). Хеш всегда имеет фиксированную длину, например, 12 символов (в зависимости от используемого вами алгоритма хеширования). Таким образом, пароль из 20 символов будет уменьшен до 12 символов, а пароль из 4 символов также даст 12 символов.

Answer 5

Всегда используйте алгоритм хэширования пароля: Argon2 , scrypt , bcrypt или PBKDF2 .

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

Никогда не храните пароль непосредственно в базе данных. Также не шифруйте его: в противном случае, если ваш сайт будет взломан, злоумышленник получит ключ дешифрования и сможет получить все пароли. Пароли ДОЛЖНЫ быть хешированными .

A хеш пароля имеет свойства, отличные от хеша хеш-таблицы или криптографического хэша. Никогда не используйте в качестве пароля обычный криптографический хеш, такой как MD5, SHA-256 или SHA-512. Алгоритм хеширования пароля использует salt , который является уникальным (не используется ни для какого другого пользователя или в чьей-либо другой базе данных). Соль необходима для того, чтобы злоумышленники не могли просто предварительно вычислить хэши общих паролей: с солью они должны перезапустить расчет для каждой учетной записи. Алгоритм хеширования пароля по сути медленный - настолько медленный, насколько вы можете себе позволить. Медлительность причиняет злоумышленнику гораздо больше вреда, чем вам, потому что злоумышленнику приходится использовать много разных паролей. Для получения дополнительной информации см. Как безопасно хэшировать пароли .

Хэш пароля кодирует четыре фрагмента информации:

• Индикатор того, какой алгоритм используется. Это необходимо для agility : криптографические рекомендации меняются со временем. Вы должны иметь возможность перейти на новый алгоритм.
• Индикатор сложности или твердости. Чем выше это значение, тем больше вычислений требуется для вычисления хэша. Это должно быть постоянное или глобальное значение конфигурации в функции смены пароля, но оно должно увеличиваться со временем, поскольку компьютеры работают быстрее, поэтому вам нужно запомнить значение для каждой учетной записи. Некоторые алгоритмы имеют одно числовое значение, другие имеют больше параметров (например, для индивидуальной настройки использования ЦП и ОЗУ).
• Соль. Поскольку соль должна быть уникальной во всем мире, она должна храниться для каждой учетной записи. Соль должна генерироваться случайным образом при каждой смене пароля.
• Собственно хеш, то есть вывод математического вычисления в алгоритме хеширования.

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

$<em>algorithm</em>$<em>parameters</em>$<em>salt</em>$<em>output</em>

где <em>algorithm</em> - число или короткая буквенно-цифровая строка, кодирующая выбор алгоритма, <em>parameters</em> - строка для печати, а <em>salt</em> и <em>output</em> кодируются в Base64 без завершения =.

16 байт достаточно для соли и вывода. (См., Например, рекомендации для Argon2 .) Кодированный в Base64, это 21 символ каждый. Две другие части зависят от алгоритма и параметров, но 20-40 символов являются типичными. Это в общей сложности около 82 символов ASCII (CHAR(82), и не требуется Unicode), к которым вы должны добавить запас прочности, если вы считаете, что будет сложно увеличить поле позже.

Если вы закодируете хеш в двоичном формате, вы можете уменьшить его до 1 байта для алгоритма, от 1 до 4 байтов для твердости (если вы жестко закодировали некоторые параметры) и до 16 байтов для соли и вывод, в общей сложности 37 байтов. Скажите 40 байтов (BINARY(40)), чтобы иметь хотя бы пару свободных байтов. Обратите внимание, что это 8-битные байты, а не печатаемые символы, в частности, поле может содержать нулевые байты.

Обратите внимание, что длина хэша совершенно не связана с длиной пароля.

Answer 6

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

Answer 7

Хэши - это последовательность битов (128 бит, 160 бит, 256 бит и т. Д., В зависимости от алгоритма). Ваш столбец должен быть двоичным, а не текстовым / символьным, если MySQL это позволяет (тип данных SQL Server binary(n) или varbinary(n)). Вы должны также посолить хэш. Соли могут быть текстовыми или двоичными, и вам потребуется соответствующий столбец.

Answer 8

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

Answer 9

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

Answer 10

для md5 vARCHAR (32) подходит. Для тех, кто использует AES, лучше использовать varbinary.