Я не уверен, как работает хеширование паролей (будет выполняться позже), но теперь нужно создать схему базы данных.
Я подумываю ограничить пароли 4-20 символами, но, как я понимаю, после того, как шифрование хэш-строки будет иметь разную длину.
Итак, как хранить эти пароли в базе данных?
Обновление: просто использование хэш-функции недостаточно для хранения паролей. Вы должны прочитать ответ от Жиля в этой теме для более подробного объяснения.
Для паролей используйте алгоритм хеширования ключей, такой как Bcrypt или Argon2i. Например, в PHP используйте функцию password_hash(), которая по умолчанию использует Bcrypt.
$hash = password_hash("rasmuslerdorf", PASSWORD_DEFAULT);
В результате получается строка из 60 символов, похожая на следующую (но цифры могут отличаться, поскольку она генерирует уникальную соль).
$2y$10$.vGA1O9wmRjrwAVXD98HNOgsNpDczlqm3Jq7KnEd1rVAGv3Fykk1a
Используйте тип данных SQL CHAR(60) для хранения этой кодировки хэша Bcrypt. Обратите внимание, что эта функция не кодируется как строка шестнадцатеричных цифр, поэтому мы не можем так просто отменить ее, чтобы сохранить в двоичном виде.
Другие хеш-функции все еще используются, но не для хранения паролей, поэтому я оставлю оригинальный ответ ниже, написанный в 2008 году.
Это зависит от алгоритма хеширования, который вы используете. Хеширование всегда дает результат одинаковой длины, независимо от ввода. Типично представлять двоичный результат хеширования в тексте как последовательность шестнадцатеричных цифр. Или вы можете использовать UNHEX() чтобы уменьшить строку шестнадцатеричных цифр вдвое.
Начиная с 2015 года, NIST рекомендует использовать SHA-256 или выше для любых применений хеш-функций, требующих взаимодействия. Но NIST не рекомендует использовать эти простые хеш-функции для безопасного хранения паролей.
Меньшие алгоритмы хеширования имеют свое применение (например, для внутреннего применения, а не для обмена), но известно, что они могут быть взломаны.
Фактически вы можете использовать CHAR (length of hash) для определения вашего типа данных для 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)). Вы также должны солить хеши. Соли могут быть текстовыми или двоичными, и вам понадобится соответствующий столбец.
Вы должны использовать TEXT (сохраняя неограниченное количество символов) для обеспечения прямой совместимости. Хеширующие алгоритмы (необходимость) становятся более прочными с течением времени, и поэтому этому полю базы данных потребуется поддержка большего количества символов с течением времени. Кроме того, в зависимости от вашей стратегии миграции вам может потребоваться сохранить новые и старые хэши в одном поле, поэтому не рекомендуется устанавливать длину одного типа хэшей.
Argon2 выиграл конкурс хэширования паролей в 2015 году. Scrypt, bcrypt и PBKDF2 - более старые алгоритмы, которые в настоящее время считаются менее предпочтительными, но все же являются фундаментально надежными, поэтому, если ваша платформа еще не поддерживает Argon2, сейчас можно использовать другой алгоритм.
Никогда не храните пароль непосредственно в базе данных. Также не шифруйте его: в противном случае, если ваш сайт будет взломан, злоумышленник получит ключ дешифрования и сможет получить все пароли. Пароли ДОЛЖНЫ быть хешированы.
Хэш пароля имеет свойства, отличные от хеш-таблицы или криптографического хэша. Никогда не используйте в качестве пароля обычный криптографический хеш, такой как MD5, SHA-256 или SHA-512. Алгоритм хеширования паролей использует соль, которая является уникальной (не используется ни для какого другого пользователя или в чьей-либо другой базе данных). Соль необходима для того, чтобы злоумышленники не могли просто предварительно вычислить хэши общих паролей: с солью они должны перезапустить расчет для каждой учетной записи. Алгоритм хеширования паролей по сути медленный - настолько медленный, насколько вы можете себе позволить. Медлительность причиняет злоумышленнику гораздо больше вреда, чем вам, потому что злоумышленнику приходится использовать много разных паролей. Для получения дополнительной информации см. Как безопасно хэшировать пароли.
Хэш пароля кодирует четыре фрагмента информации:
Многие библиотеки включают в себя пару функций, которые удобно упаковывают эту информацию в одну строку: одну, которая берет индикатор алгоритма, индикатор твердости и пароль, генерирует случайную соль и возвращает полную строку хеша; и тот, который принимает пароль и полную строку хеша в качестве входных данных и возвращает логическое значение, указывающее, был ли пароль правильным. Там нет универсального стандарта, но общая кодировка
$algorithm$parameters$salt$output
где algorithm - это число или короткая буквенно-цифровая строка, кодирующая выбор алгоритма, parameters - это печатаемая строка, а salt и output данные кодируются в Base64 без завершения =.
16 байт достаточно для соли и вывода. (См., Например, рекомендации для Argon2.) Закодировано в Base64, каждый из 21 символа. Две другие части зависят от алгоритма и параметров, но 20-40 символов являются типичными. Это в общей сложности около 82 символов ASCII (CHAR(82), и нет необходимости в Юникоде), к которым вы должны добавить запас прочности, если вы считаете, что будет сложно увеличить поле позже.
Если вы закодируете хэш в двоичном формате, вы можете уменьшить его до 1 байта для алгоритма, от 1 до 4 байтов для твердости (если вы жестко кодируете некоторые параметры) и до 16 байтов для соли и выходных данных., в общей сложности 37 байтов. Скажите 40 байтов (BINARY(40)), чтобы иметь как минимум пару свободных байтов. Обратите внимание, что это 8-битные байты, а не печатаемые символы, в частности, поле может содержать нулевые байты.
Обратите внимание, что длина хеша совершенно не связана с длиной пароля.
Я всегда тестировал, чтобы найти длину строки MAX зашифрованной строки и установить ее как длину символа типа VARCHAR. В зависимости от того, сколько записей у вас будет, это может реально помочь размеру базы данных.
для md5 vARCHAR (32) является подходящим. Для тех, кто использует AES лучше использовать varbinary.