Хеширование

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

Результат такого преобразования называют хешем, хеш-значением или digest. Один и тот же вход при использовании одной и той же хеш-функции должен давать одинаковый результат.

Хеширование широко используется в информационной безопасности, базах данных, системах хранения файлов, цифровых подписях, контроле целостности, дедупликации и аутентификации пользователей.

Хеширование обычно является односторонним преобразованием: по хешу не предполагается возможность восстановить исходные данные так же, как при обычном расшифровании.

Что такое хеширование простыми словами

Представим текст:

Hello

Хеш-функция обрабатывает его и возвращает значение фиксированного размера:

Input data
↓
Hash function
↓
Hash value

Если изменить хотя бы один символ исходных данных, результат обычно значительно изменится.

Что такое хеш

Хеш — результат работы хеш-функции.

Он может записываться как последовательность шестнадцатеричных символов:

2cf24dba5fb0a30e...

Длина строки зависит от используемого алгоритма и формата представления.

Что такое хеш-функция

Хеш-функция принимает данные и вычисляет значение фиксированной длины.

Для криптографической хеш-функции важны несколько свойств:

• детерминированность;
• сложность восстановления исходных данных;
• сложность поиска двух входов с одинаковым хешем;
• сильное изменение результата при небольшом изменении входа.

Детерминированность

Одинаковые входные данные должны давать одинаковый хеш.

hash("document") → X
hash("document") → X

Это позволяет использовать хеши для сравнения данных.

Avalanche Effect

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

document1 → A7F...
document2 → 91C...

Даже если два файла отличаются одним байтом, их хеши должны выглядеть несвязанными.

Хеширование и шифрование

Хеширование и шифрование решают разные задачи.

Если приложению необходимо позже получить исходный Password, хеширование не подходит. Но безопасная система обычно и не должна уметь восстанавливать пользовательский пароль.

Хеширование и кодирование

Base64 и подобные механизмы являются кодированием, а не хешированием.

Закодированные данные можно вернуть к исходному виду без Secret Key.

Хеш предназначен для другого класса задач.

Криптографические и некриптографические хеш-функции

Не все хеш-функции предназначены для информационной безопасности.

Коллизия

Коллизия возникает, когда разные входные данные имеют одинаковый хеш.

Input A → HASH123
Input B → HASH123

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

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

Collision Resistance

Collision Resistance означает устойчивость к поиску двух различных сообщений с одинаковым хешем.

Это особенно важно для цифровых подписей и контроля целостности.

Preimage Resistance

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

Second Preimage Resistance

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

Это свойство важно, когда злоумышленник пытается незаметно заменить исходный документ.

Хеширование файлов

Хеш часто используется для проверки целостности файлов.

Например, разработчик публикует дистрибутив и его контрольную сумму.

software.zip
↓ SHA-256
expected hash

Пользователь скачивает файл, вычисляет его хеш и сравнивает значения.

Контрольная сумма

Термин checksum используется шире хеширования.

Некоторые контрольные суммы предназначены для обнаружения случайных ошибок, но не для защиты от намеренной подмены.

Для Security-sensitive проверки применяют криптографические хеш-функции и, при необходимости, цифровые подписи.

Почему хеш файла не всегда доказывает его подлинность

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

Для подтверждения источника дополнительно используются Digital Signature, доверенный канал или другой механизм Authentication.

Хеширование паролей

Одна из наиболее важных областей применения — хранение Password.

Server не должен хранить пароль пользователя в открытом виде.

Вместо этого хранится результат специализированной Password Hashing Function.

Password
↓ password hashing
Stored hash

Как проверяется пароль

При Login пользователь снова вводит Password.

Система применяет к нему тот же механизм и сравнивает результат с сохраненным значением.

User password
↓ hash with parameters
Calculated value
↓ compare
Stored value

Исходный Password для проверки восстанавливать не требуется.

Почему нельзя хранить пароль в открытом виде

Если Database с Passwords будет украдена, злоумышленник сразу получит Credentials всех пользователей.

При правильном Password Hashing ему придется отдельно пытаться подобрать каждый Password.

Почему обычный быстрый хеш плохо подходит для паролей

Алгоритмы общего назначения разработаны для быстрого вычисления.

Это полезно для проверки файлов, но помогает атакующему проверять огромное количество Password Candidates.

Для хранения паролей нужны специализированные медленные и настраиваемые Password Hashing Algorithms.

Salt

Salt — случайное значение, которое добавляется к Password перед вычислением хеша.

Password + Salt
↓
Password hash

Salt не обязан быть секретным. Его основная задача — сделать одинаковые Passwords разными на уровне сохраненных хешей.

Зачем нужен Salt

Допустим, два пользователя выбрали один Password.

Без Salt:

user1 password → ABC
user2 password → ABC

С разными Salt:

user1 password + salt1 → 81F
user2 password + salt2 → C93

Из Database уже нельзя сразу определить, что Password одинаковы.

Rainbow Table

Rainbow Table — заранее рассчитанный набор соответствий между потенциальными Passwords и их хешами.

Уникальный случайный Salt делает массовое применение подобных предварительно вычисленных таблиц значительно менее эффективным.

Salt не является Password

Salt можно хранить рядом с хешем.

Безопасность не должна зависеть от сокрытия Salt.

Критичнее качество алгоритма, стоимость вычисления и сила самого Password.

Pepper

Pepper — дополнительный Secret, который может использоваться при Password Hashing и храниться отдельно от Database.

В отличие от Salt, Pepper должен оставаться секретным.

Его использование усложняет архитектуру управления Secrets и не заменяет правильный Password Hashing Algorithm.

Password Hashing Function

Для хранения Password применяются алгоритмы, специально разработанные для замедления перебора и управления стоимостью вычислений.

Они могут использовать:

• настраиваемое число вычислений;
• Memory Cost;
• Salt;
• параметры сложности.

Почему медленное хеширование полезно

Пользователь вводит Password несколько раз в день, поэтому несколько дополнительных миллисекунд или подходящее время вычисления обычно приемлемы.

Атакующий, проверяющий миллионы вариантов, сталкивается с гораздо большей суммарной стоимостью.

Brute Force

Brute Force — перебор большого количества возможных значений.

Само хеширование не предотвращает подбор слабого Password.

Если пользователь выбрал:

123456

атакующий может быстро включить его в список кандидатов.

Dictionary Attack

При Dictionary Attack проверяются не все комбинации подряд, а наиболее вероятные Passwords, слова и известные шаблоны.

Именно поэтому уникальность и длина Password остаются важными даже при хорошем хешировании.

Credential Database Leak

После кражи Password Database атакующий может выполнять Offline Attack.

Он не обращается к Login Form и поэтому Rate Limiting веб-приложения уже не помогает.

Качество Password Hashing становится критичным последним рубежом.

Хеш и секретность

Нельзя считать хеш абсолютно безопасным только потому, что он необратим напрямую.

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

Хеширование Email и телефонов

Иногда разработчики хешируют Email или Phone Number и считают данные полностью анонимными.

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

Хеширование не всегда равно анонимизации.

Хеширование и персональные данные

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

Оценивать такие данные необходимо с учетом реальной Threat Model.

Хеширование в цифровой подписи

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

Document
↓ hash
Digest
↓ digital signature
Signature

Получатель вычисляет хеш документа и проверяет Signature.

Почему хеш удобен для подписи

Документ может занимать гигабайты, а Digest имеет фиксированный размер.

Это делает криптографические операции эффективнее.

Хеширование и TLS

Криптографические хеш-функции используются внутри различных механизмов TLS для обеспечения Integrity, Authentication и производных криптографических операций.

Конкретная роль зависит от выбранного Cipher Suite и версии протокола.

Хеширование и сертификаты

Цифровая подпись Certificate также использует криптографические хеш-механизмы.

Это помогает проверить, что Certificate не был изменен после подписания доверенным Issuer.

Хеширование и Git

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

Commit может ссылаться на другие объекты через их Hash IDs.

Почему хеш удобен как идентификатор

Он зависит от содержимого.

Если содержимое объекта меняется, изменяется и его Hash.

Такой подход называют Content-addressed Storage.

Content-addressed Storage

Вместо имени объекта его адресом становится хеш содержимого.

Content
↓ hash
Object ID

Это удобно для дедупликации и проверки целостности.

Дедупликация

Система может вычислить хеш каждого файла и найти одинаковые значения.

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

Хеширование в Backup

Backup System может разбивать данные на Blocks и вычислять их Hash.

Если Block уже хранится, повторно сохранять его не требуется.

Это уменьшает объем Storage.

Хеширование в облачном хранилище

Object Storage и File Synchronization Systems могут использовать Hash для определения, изменился ли объект, и проверки корректности передачи.

Хеширование и Database

Хеши могут использоваться:

• для сравнения записей;
• дедупликации;
• поиска изменений;
• распределения данных;
• создания технических ключей.

Однако криптографический Hash не всегда является лучшим Database Index для каждой задачи.

Hash Table

Хеш-таблица — структура данных, которая использует Hash Function для определения места хранения элемента.

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

Хеширование и индекс

Hash Index особенно хорошо подходит для некоторых операций точного сравнения.

Для Range Queries могут использоваться другие структуры.

Consistent Hashing

Consistent Hashing используется в распределенных системах для распределения Keys между Nodes так, чтобы при изменении числа серверов перемещалась только часть данных.

Это встречается в Cache и Distributed Storage Architecture.

Хеширование и Sharding

Hash от ключа можно использовать для выбора Shard.

hash(customer_id) mod N → shard

Так записи распределяются между несколькими Database Nodes.

Проблемы Hash-based Sharding

Такое распределение хорошо балансирует данные, но может усложнить Range Queries и изменение количества Shards.

Поэтому архитектура зависит от Workload.

Хеширование в Load Balancer

Load Balancer может использовать Hash от Client IP, Cookie или другого Key для выбора Backend.

Это позволяет получать относительно стабильное распределение Sessions.

Хеширование и Cache

Cache Key может включать Hash сложного набора параметров.

Это удобно, когда исходный Key слишком длинный или имеет сложную структуру.

Хеширование и API

В API хеши применяются для:

• проверки целостности;
• подписания Requests;
• идентификации Content;
• ETag-подобных механизмов;
• дедупликации сообщений.

Хеширование и HMAC

HMAC — механизм проверки целостности и Authenticity сообщения с использованием криптографической хеш-функции и Secret Key.

Message + Secret Key
↓ HMAC
Authentication code

Обычный Hash не подтверждает, кто создал сообщение, потому что вычислить его может любой.

Hash и HMAC

HMAC в Webhook

Webhook Provider может подписать Request с помощью HMAC.

Получатель самостоятельно вычисляет значение из Request Body и Secret и сравнивает результаты.

Это помогает убедиться, что сообщение действительно создано стороной, владеющей Secret.

Хеширование и Blockchain

Хеш-функции являются важной частью многих Blockchain Structures.

Они связывают данные, идентифицируют Blocks и помогают строить структуры проверки целостности.

Merkle Tree

Merkle Tree строится из хешей блоков данных.

Хеши объединяются по уровням до одного Root Hash.

Data A → Hash A
Data B → Hash B
↓
Hash AB
↓
Merkle Root

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

Хеширование и контейнерные образы

Container Registry может идентифицировать Image Layers через Content Digest.

Если содержимое изменилось, меняется и Digest.

Это удобно для проверки неизменности Artifact.

Хеширование в CI/CD

Pipeline может рассчитывать хеш Build Artifact и использовать его для:

• проверки целостности;
• идентификации версии;
• Cache;
• сравнения Artifacts;
• формирования Software Supply Chain Metadata.

Хеширование и Malware

Антивирус и EDR могут использовать Hash файла как один из Indicators of Compromise.

Если Malware Sample известен, его Hash можно искать на других Endpoints.

Почему одного Hash недостаточно для Detection Malware

Злоумышленник может немного изменить файл, и его Hash полностью изменится.

Поэтому EDR дополнительно использует Behavior Detection, Reputation и другие признаки.

Хеширование и SIEM

SIEM может хранить File Hash из EDR Events и сравнивать его с Threat Intelligence.

Например:

Endpoint event → file hash
↓
Threat intelligence match
↓
Alert

Хеширование и SOC

SOC Analyst может искать известный вредоносный Hash по всем Endpoint Events, чтобы определить Scope Incident.

Хеширование и XDR

XDR связывает File Hash с Process, User, Email Attachment и Network Activity.

Так один технический Indicator получает более широкий контекст.

Hash как IOC

File Hash является распространенным IOC.

Но это достаточно точный и одновременно хрупкий Indicator: изменение одного байта создает новое значение.

MD5

MD5 — исторически широко применявшаяся криптографическая хеш-функция.

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

Она может встречаться в Legacy Systems и некритичных сценариях проверки, но назначение необходимо четко понимать.

SHA-1

SHA-1 также является устаревшим для сценариев, где важна современная Collision Resistance.

Новые Security-sensitive системы должны использовать актуальные криптографические алгоритмы, соответствующие требованиям конкретной платформы.

SHA-256

SHA-256 — криптографическая хеш-функция семейства SHA-2 с 256-битным результатом.

Она широко применяется для контроля целостности, цифровых подписей, сертификатов и различных Security Protocols.

SHA-512

SHA-512 также относится к SHA-2 и формирует более длинный Digest.

Выбор между функциями должен соответствовать конкретному протоколу и требованиям системы, а не правилу «чем длиннее, тем всегда лучше».

SHA-3

SHA-3 — отдельное семейство криптографических хеш-функций с другой внутренней конструкцией.

Оно не является просто следующей версией SHA-2 в смысле обязательной замены всех существующих реализаций.

Почему нельзя самостоятельно придумывать хеш-функцию

Криптографические алгоритмы требуют серьезного анализа.

Простое смешивание символов, XOR или собственная математика почти наверняка не обеспечит необходимые Security Properties.

Для Security-sensitive систем следует использовать проверенные стандартные алгоритмы и библиотеки.

Сравнение хешей

Для некоторых Security-sensitive значений обычное посимвольное сравнение может создавать Timing Side Channel.

Поэтому HMAC и Authentication Codes рекомендуется сравнивать специализированной Constant-time операцией, если библиотека ее предоставляет.

Timing Attack

Если функция завершает сравнение при первом несовпавшем байте, время ответа теоретически может раскрывать информацию о совпавшей части Secret Value.

Современные криптографические библиотеки предоставляют безопасные функции сравнения для подобных сценариев.

Хеширование и производительность

Требования к скорости зависят от задачи.

Для проверки файлов высокая скорость полезна.

Для Password Hashing слишком высокая скорость, наоборот, ухудшает защиту от перебора.

CPU и GPU

Некоторые алгоритмы очень эффективно вычисляются параллельно на GPU.

При Password Hashing это учитывается выбором функций с настраиваемой вычислительной и Memory Cost.

Memory-hard алгоритмы

Memory-hard подходы требуют заметного объема памяти на каждую попытку вычисления.

Это повышает стоимость массового параллельного подбора Password.

Рехеширование паролей

Security Parameters со временем могут устаревать.

После успешного Login система может определить, что сохраненный Password Hash использует старые параметры, и пересчитать его с новыми настройками.

Миграция старых хешей

Нельзя преобразовать старый Hash непосредственно в более надежный, не имея исходного Password в подходящей модели.

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

Хеширование и Backup

Хеш позволяет проверить, что Backup File не изменился или не повредился.

Но Hash не заменяет тест восстановления.

Файл может иметь правильный хеш и при этом быть логически непригодным для восстановления из-за ошибки самого Backup Process.

Хеширование и дедупликация Backup

Backup Software может вычислять Hash Blocks и хранить одинаковый Block только один раз.

Это особенно эффективно при большом количестве похожих виртуальных машин.

Хеширование в распределенных системах

Хеши используются для распределения нагрузки, определения владельца Key и сравнения реплик.

Но для каждой задачи может требоваться другой тип Hash Function.

Криптографическая безопасность не всегда нужна

Для внутренней Hash Table применение медленной криптографической функции может быть неоправданным.

Важно выбирать алгоритм исходя из Threat Model и требований Performance.

Типичные ошибки при хешировании

1. Путать хеширование с шифрованием.
2. Считать Base64 защитой данных.
3. Хранить Password через обычный быстрый Hash.
4. Не использовать уникальный Salt для паролей.
5. Использовать устаревший алгоритм в Security-sensitive задаче.
6. Считать хеш доказательством происхождения файла.
7. Хешировать Email и считать данные полностью анонимными.
8. Хранить Secrets внутри обычного Hash без анализа возможности перебора.
9. Самостоятельно разрабатывать криптографическую функцию.
10. Не планировать обновление параметров Password Hashing.

Как правильно хранить пароли

Шаг 1. Не хранить исходный Password

Приложение должно сохранять только результат Password Hashing.

Шаг 2. Использовать специализированный алгоритм

Он должен поддерживать достаточную стоимость вычисления и быть предназначен именно для Password Storage.

Шаг 3. Использовать случайный Salt

Каждая учетная запись получает собственное значение.

Шаг 4. Настроить Cost

Параметры должны замедлять массовый перебор, но не создавать неприемлемую нагрузку при нормальном Login.

Шаг 5. Планировать обновление

При росте вычислительных возможностей параметры необходимо пересматривать.

Шаг 6. Защитить Authentication Infrastructure

Хороший Password Hash не заменяет MFA, Rate Limiting и мониторинг.

Практический пример хранения пароля

Пользователь регистрируется в корпоративном сервисе и задает Password.

Application генерирует случайный Salt и передает Password вместе с Salt в специализированную Password Hashing Function.

Password + unique salt
↓
Password hashing function
↓
Stored result

В Database сохраняются Hash, Salt и необходимые параметры алгоритма.

Через несколько месяцев происходит утечка Database.

Злоумышленник не получает Password в открытом виде. Чтобы найти его, необходимо отдельно подбирать варианты для каждого пользователя.

Уникальный Salt не позволяет эффективно сравнить одинаковые Passwords между Accounts или использовать одну заранее рассчитанную таблицу для всей Database.

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

Практический пример проверки файла

Компания передает партнеру архив с финансовыми данными.

Перед отправкой вычисляется криптографический Hash.

Партнер получает Archive по одному каналу и контрольное значение через доверенный механизм.

После загрузки он повторно вычисляет Hash.

Expected hash = A
Calculated hash = A
→ file unchanged

Если значения отличаются, файл мог повредиться или измениться.

Хеширование для бизнеса

Хеширование является фундаментальным механизмом современной IT-инфраструктуры.

Бизнес использует его даже тогда, когда сотрудники напрямую об этом не знают: при входе в корпоративные системы, проверке Software Updates, цифровой подписи документов, резервном копировании и работе Git.

Наибольшее значение имеет правильный выбор алгоритма под конкретную задачу. Функция для Hash Table, контрольной суммы файла и хранения Password решает разные проблемы и не должна выбираться по одному принципу.

Преимущества хеширования

• быстрое сравнение данных;
• проверка целостности;
• безопасное хранение Password при правильной реализации;
• идентификация Content;
• дедупликация;
• использование в цифровых подписях;
• эффективное распределение данных.

Ограничения хеширования

• хеш не обеспечивает Confidentiality;
• возможны коллизии;
• слабые исходные значения можно подобрать;
• обычный Hash не подтверждает автора данных;
• не все алгоритмы подходят для Security;
• устаревшие функции могут иметь известные криптографические недостатки;
• неправильное применение к Password создает серьезные риски.

Когда использовать хеширование

Хеширование подходит, когда необходимо получить компактный отпечаток данных, проверить их изменение, сравнить объекты, построить цифровую подпись или безопасно проверить Password без хранения исходного значения.

Если требуется позже восстановить исходные данные, необходимо рассматривать Encryption, а не Hashing.

Связанные термины

Краткий итог

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

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

При хранении Password необходимо использовать специализированные Password Hashing Functions с уникальным Salt и достаточной вычислительной стоимостью. Обычный быстрый Hash для этой задачи недостаточен. Правильный алгоритм всегда выбирается исходя из конкретной Security-задачи и Threat Model.