Шифрование запросов: HMAC и AES-256-CBC для безопасности

🔐 Шифрование запросов

Мы нашли решение, хочу с вами поделиться:

Задача была сделать дополнительный слой безопасности, помогающий (1) идентифицировать пользователя, (2) сверить, что содержание сообщения не было изменено по пути до сервера. Такое часто нужно, например, при запросах на создание денежных транзакций.

Один из самых простых вариантов – использование HMAC (его используют Ю.Касса, Тинькоф, Страйп, etc.)

Смысл HMAC таков: клиент, после формирования объекта данных транзакции, из значений этого объекта формирует строку, добаляется к ней hmac-секрет и шифрует. Полученая строка-шифр (подпись) добавляется к запросу и отправляется на сервер.

Сервер, получив запрос, делает все теже операции над его содержанием, используя тотже самый hmac-секрет и сверяет с той подписью, которая был отправлен в запросе. Если они идентичны – все супер, если нет, значит или кто-то попытался подменить соедржание пакета или имеют не тот ключ.

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

Хранить его удобно в БД, но что если БД уведут?

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

Для этого идеально подходит алгоритм "aes-256-cbc". Секреты для него хранятся в env приложения.

Получается, даже если уведут БД, у злоумышленников не будет возможности расшифровать hmac-секреты, а чтобы это сделать, нужно иметь или доступ к приложению, или дамп памяти приложения.

Короче, шифрование шифрование шифрованием погоняет, такие дела

P.S.

У меня корона уже 4-ю неделю, поэтому я малоактивный 🙁 Будьте аккуратнее, правда, крайне много заражений последнее время, и даже при хорошем здоровье ощущения, как болеть 3-ный бронхитом