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

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

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

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

Для паролей используйте алгоритм хеширования ключей, такой как 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 не рекомендует использовать эти простые хэш-функции для безопасного хранения паролей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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