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

StackOverflow https://stackoverflow.com/questions/247304

Вопрос

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

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

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

Это было полезно?

Решение

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

Для паролей используйте алгоритм хеширования усиления ключей, такой как Bcrypt или Argon2i.Например, в PHP используйте функция пароль_хэш(), который по умолчанию использует 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 год НИСТ рекомендует использовать SHA-256 или выше для любых приложений хэш-функций, требующих совместимости.Но NIST не рекомендует использовать эти простые хэш-функции для безопасного хранения паролей.

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

Другие советы

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

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

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

Всегда используйте алгоритм хеширования пароля: Аргон2, сценарий, bcrypt или ПБКДФ2.

Аргон2 выиграл конкурс по хешированию паролей 2015 года. Скрипт, bcrypt и ПБКДФ2 — это старые алгоритмы, которые сейчас считаются менее предпочтительными, но по-прежнему фундаментально надежны, поэтому, если ваша платформа еще не поддерживает Argon2, сейчас можно использовать другой алгоритм.

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

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

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

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

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

$алгоритм$параметры$соль$выход

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

16 байт достаточно для соли и вывода.(См., например, рекомендации для Аргона2.) Закодировано в Base64, по 21 символу каждый.Остальные две части зависят от алгоритма и параметров, но обычно это 20–40 символов.Это всего около 82 символов ASCII (CHAR(82), и нет необходимости в Юникоде), к которому следует добавить запас прочности, если вы считаете, что позже будет сложно расширить это поле.

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top