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

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

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

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

9 ответов


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

  • MD5 генерирует 128-битное хэш-значение. Вы можете использовать CHAR(32) или BINARY (16)
  • SHA-1 генерирует 160-битное хэш-значение. Вы можете использовать CHAR (40) или двоичный (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)

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

вы должны соль ваши пароли перед применением функции хэширования. Соление пароля не влияет на длину хэш-результата.


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


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


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


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


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


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


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


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