Как правильно хранить hash-значения в SQL Server: HASHBYTES

Быстрый ответ

Для хэшей SHA-256 наиболее подходящим будет тип данных BINARY(32), обеспечивающий экономное расходование пространства благодаря его 256-битной длине. Пример стандартного описания столбца в SQL выглядит следующим образом:

CREATE TABLE user_hashes (
    hash BINARY(32) NOT NULL
);

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

Соответствие хеша и типа данных

Выбор типа данных для хэша определяется размером его хеш-суммы. Давайте разберём наиболее распространённые алгоритмы хеширования:

• для MD5: используйте BINARY(16);
• для SHA1: подойдёт BINARY(20);
• для SHA2_256: выбирайте BINARY(32);
• для SHA2_512: наиболее оптимальным будет BINARY(64).

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

Фиксированность против изменчивости: слово предостережения

Использование типов VARCHAR и VARBINARY для хранения хэшей с фиксированной длиной не оправдано, ведь BINARY обеспечивает лучшие показатели производительности. Это связано с фиксированной длиной данных, которую SQL Server способен эффективнее обрабатывать и хранить.

Визуализация

Тип данных в SQL можно символически представить как замок:

Простой хэш реализуется при помощи CHAR(32) или CHAR(64), а для обеспечения усиленной защиты используются BINARY(16) для MD5 и BINARY(32) для SHA-256. Подбирайте соответствующий "ключ" для работы с SQL!

Оптимизация по хранению и производительности

При работе с хешами паролей или секретными данными особое внимание стоит уделить безопасности и скорости выполнения запросов. Вот что важно:

• Полагаться на хеширование, выполненное встроенными в вашу СУБД функциями, например, HASHBYTES в SQL Server;
• Выбирать двоичные размеры, соответствующие наиболее часто встречающимся хешам;
• Учитывать, что большой размер данных может отразиться на объёме резервных копий и скорости работы. Размер важен!

Управление большими хешами

Для приложений, требующих максимальной безопасности, например, при использовании SHA3-512 или Whirlpool, которые формируют длинные хеш-ключи:

• Используйте BINARY(64) для SHA3-512;
• Для Whirlpool, формирующего также 512-битные хеши, подойдет BINARY(64).

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

Исключение подтверждает правило

В некоторых случаях может быть нужен другой тип данных:

• Если хеш-ключ входит в состав бóльшего составного ключа, могут быть иные требования.
• Для временного хранения или в промежуточных таблицах может подойти например VARBINARY.
• В системах, где требуется обратная совместимость, придется оставить CHAR или VARCHAR.

Полезные материалы

1. PostgreSQL: Документация: Типы данных — подробное описание типов данных PostgreSQL.
2. Руководство по MySQL 8.0: Требования к хранению данных — требования к хранению данных в MySQL.
3. Типы данных (Transact-SQL) – SQL Server | Microsoft Learn — информация о типах данных SQL Server для хеширования и хранения.
4. Типы данных в Oracle — описание типов данных Oracle, полезное при выборе подходящего для хэша.
5. Типы данных в SQLite — разъяснение типов данных в SQLite, включая использование TEXT для хранения хэшей.
6. Какой тип данных использовать для поля хешированного пароля и какой длины? – Stack Overflow — обсуждение выбора типа данных для хранения хэшей.
7. Хэш-функция – Википедия — общая информация о хэш-функциях, влияющих на хранение данных.