Криптография — это не предмет для математиков с PhD. Это инструмент, который каждый разработчик обязан понимать хотя бы на базовом уровне. Без этого ты не сможешь написать безопасное приложение. Точка.
Хэширование: отпечаток пальца для данных
Представь, что ты берёшь любой текст — хоть «привет», хоть «Войну и мир» — и пропускаешь его через мясорубку. На выходе получаешь строку фиксированной длины. Это и есть хэш.
"привет" → SHA-256 → "a1b2c3d4e5..." (64 символа, всегда)
"приветт" → SHA-256 → "f7g8h9i0j1..." (совершенно другой хэш!)Ключевые свойства хэша:
Односторонность — из хэша нельзя восстановить исходные данные. Это как сжечь книгу и получить пепел определённого цвета. По цвету пепла книгу не восстановишь.
Детерминированность — одинаковый вход всегда даёт одинаковый выход. «привет» через SHA-256 всегда будет одним и тем же хэшем.
Лавинный эффект — изменение одного символа полностью меняет хэш. Это не «похожий» хэш — это абсолютно другая строка.
Где это применяется?
Хранение паролей — вместо самого пароля в базе хранится его хэш. При входе пользователь вводит пароль, система хэширует его и сравнивает хэши.
Проверка целостности файлов — скачал файл, посчитал хэш, сравнил с эталонным. Не совпал — файл повреждён или подменён.
Git — каждый коммит идентифицируется хэшем. Именно поэтому коммиты выглядят как a3f2b1c...
Какие алгоритмы использовать?
MD5 — устарел, не используй для безопасности (но для контрольных сумм файлов ещё ок)
SHA-1 — тоже устарел, найдены коллизии
SHA-256 — текущий стандарт для общего хэширования
bcrypt / Argon2 — специализированные алгоритмы для паролей (об этом ниже)
Соль: почему просто хэшировать пароль — это мало
Допустим, ты хранишь хэши паролей. Звучит безопасно? Не совсем.
Проблема: у миллионов людей пароль «123456». Хэш этого пароля всегда один и тот же. Злоумышленник может заранее посчитать хэши для миллионов популярных паролей (это называется радужная таблица) и просто искать совпадения в твоей базе.
Соль — это случайная строка, которая добавляется к паролю перед хэшированием.
Без соли:
"123456" → SHA-256 → "8d969eef..." (у всех одинаковый)
С солью:
"123456" + "x7Km9p" → SHA-256 → "4f2a8b71..." (уникальный!)
"123456" + "Qw3rTy" → SHA-256 → "9c1d5e83..." (тоже уникальный!)Теперь даже одинаковые пароли дают разные хэши. Радужная таблица бесполезна — злоумышленнику пришлось бы строить отдельную таблицу для каждой соли.
Правила работы с солью
Соль должна быть уникальной для каждого пользователя. Одна соль на всю базу — это почти бесполезно.
Соль не секретна. Она хранится рядом с хэшем в открытом виде. Её задача — не быть секретной, а делать каждый хэш уникальным.
Соль должна быть достаточно длинной. Минимум 16 байт.
На практике — используй bcrypt
Не изобретай велосипед. Алгоритм bcrypt (или Argon2) делает всё за тебя: генерирует соль, хэширует с нужным количеством итераций, и упаковывает результат в удобную строку.
// Node.js пример
const bcrypt = require('bcrypt');
// Хэширование пароля
const hash = await bcrypt.hash('мой_пароль', 12); // 12 раундов
// Результат: "$2b$12$LJ3m5... " — тут и алгоритм, и соль, и хэш
// Проверка пароля
const isValid = await bcrypt.compare('мой_пароль', hash); // trueЧисло раундов (12 в примере) — это «стоимость» хэширования. Чем больше — тем дольше считается хэш. Для злоумышленника, перебирающего миллионы вариантов, это критично.
Шифрование: когда данные нужно прочитать обратно
Хэширование — это дорога в один конец. А что если данные нужно защитить, но потом прочитать обратно? Тогда нужно шифрование.
Симметричное шифрование: один ключ
Один и тот же ключ используется и для шифрования, и для расшифровки. Как замок с одним ключом — кто его имеет, тот и открывает.
Текст + Ключ → [AES-256] → Шифротекст
Шифротекст + Тот же Ключ → [AES-256] → ТекстAES-256 — золотой стандарт симметричного шифрования. Используется везде: от мессенджеров до банковских систем.
Проблема: как передать ключ второй стороне безопасно? Если отправить его по открытому каналу — его перехватят. Это «задача обмена ключами».
Асимметричное шифрование: два ключа
Здесь появляется пара ключей: публичный (открытый) и приватный (секретный).
Публичный ключ — это как открытый почтовый ящик. Любой может бросить туда письмо. Но достать письмо может только тот, у кого есть ключ от ящика — приватный ключ.
Текст + Публичный ключ → [RSA] → Шифротекст
Шифротекст + Приватный ключ → [RSA] → ТекстЭто решает задачу обмена ключами: ты публикуешь свой публичный ключ, и любой может зашифровать для тебя данные. Расшифровать сможешь только ты.
Цифровая подпись — обратный процесс
Подпись работает наоборот: ты шифруешь своим приватным ключом, а проверить может любой с помощью твоего публичного ключа. Это доказывает, что данные отправил именно ты.
TLS: как всё это работает вместе в интернете
Каждый раз, когда ты видишь 🔒 в браузере и https:// — это работает TLS (Transport Layer Security). И вот что происходит за кулисами при каждом HTTPS-запросе.
Рукопожатие (TLS Handshake)
Шаг 1. Твой браузер говорит серверу: «Привет, хочу безопасное соединение. Вот алгоритмы, которые я поддерживаю.»
Шаг 2. Сервер отвечает: «Привет! Вот мой сертификат (с публичным ключом), и давай используем вот эти алгоритмы.»
Шаг 3. Браузер проверяет сертификат — реально ли он выдан доверенным центром сертификации (CA), не просрочен ли, соответствует ли домену.
Шаг 4. Используя асимметричное шифрование, браузер и сервер договариваются о сессионном ключе — это симметричный ключ, который будет использоваться дальше.
Шаг 5. Всё дальнейшее общение идёт через быстрое симметричное шифрование (AES).
Почему именно так?
Асимметричное шифрование надёжно, но медленное. Симметричное — быстрое, но нужен безопасный обмен ключами. TLS элегантно комбинирует оба подхода: асимметричное — для обмена ключами, симметричное — для передачи данных.
Что может пойти не так?
Самоподписанные сертификаты — браузер им не доверяет, и правильно делает
Устаревшие версии TLS — TLS 1.0 и 1.1 уязвимы, используй минимум TLS 1.2
Man-in-the-Middle — атака, при которой кто-то встаёт между тобой и сервером. TLS защищает от неё, если сертификат валидный
JWT: токены, которые ты видишь каждый день
Если ты работаешь с веб-приложениями, ты точно сталкивался с JWT (JSON Web Token). Это компактный способ передавать проверенные данные между сторонами.
JWT состоит из трёх частей, разделённых точками:
eyJhbGci... . eyJzdWIi... . SflKxwRJ...
Header Payload SignatureHeader — алгоритм подписи (например, HS256).
Payload — данные (например, ID пользователя, роль, срок действия).
Signature — подпись, которая гарантирует, что токен не подделан.
Важно понимать
JWT подписан, но не зашифрован (по умолчанию). Payload закодирован в Base64 — это не шифрование, это просто кодировка. Любой может декодировать и прочитать содержимое. Не клади туда пароли или секретные данные.
Подпись гарантирует целостность: если кто-то изменит payload, подпись перестанет совпадать.
Учи программирование с практикой 🚀
Криптография — это один из тех топиков, которые лучше всего усваиваются через практику. И если ты только начинаешь свой путь в программировании или хочешь закрепить знания — попробуй Кодик. Это приложение, в котором можно изучать программирование с упором на практику: не просто читать теорию, а сразу решать задачи и видеть результат.
А ещё у нас есть сообщество в Телеграм, где регулярно выходят полезные посты по программированию, разборы задач, объяснения концепций. Это отличный способ повторять материал в удобном месте — в дороге, в перерыве, перед сном. Подписывайся и прокачивайся каждый день!
Итого
Криптография в повседневной работе разработчика — это не сложная математика. Это набор инструментов и правил.
Хэши — необратимые отпечатки данных. Соль — защита от массовых атак на пароли. Симметричное шифрование — быстрая защита данных одним ключом. Асимметричное шифрование — безопасный обмен ключами и цифровые подписи. TLS — комбинация всего вышеперечисленного для защиты интернет-трафика.
Ты не обязан знать, как именно работает AES на уровне битовых операций. Но ты обязан знать, когда что применять и каких ошибок избегать.
Безопасность — это не фича, которую «потом добавим». Это фундамент.