💬 Друзья, у меня к вам есть вопрос: кто-нибудь решал проблему подписей запросов симметричным / асимметричным шифрование?
Товарищи разрабатывают сервис денежных транзакций и выбрали HMAC (симетричное шифрование, где общий с клиентом ключ хранится с обоих сторон), но если хранилище секретов утечет – всему залупа
Хочется понять: стоит ли забить хрен и просто обезопасить хранилище секретов, или лучше воспользоваться каким-нибудь ассиметричным шифрованием
Есть идеи?
Комментарии: 20
S
S Dmitry
2022-01-01 01:56
А ssl нет?
🦾
🦾 IT-Раздевалка 💪
2022-01-12 16:06
S Dmitry
А ssl нет?
Не очень представляю как полноценно организовать в данной ситуации ssl. Имеется ввиду, выписывать и проверять самостоятельно сертификаты на каждый запрос от клиента?
Если что, решение нашлось решение, я его в следующем посте напишу
S
S Dmitry
2022-01-12 16:30
Ssl же проверяет сертификат один раз, а потом используется симметричный ключ сессии.
🦾
🦾 IT-Раздевалка 💪
2022-01-12 16:32
S Dmitry
Ssl же проверяет сертификат один раз, а потом используется симметричный ключ сессии.
Я просто не совсем понимаю на каком уровне и чем будет проверяться ssl сертификат
S
S Dmitry
2022-01-12 16:38
Ну вы же пользуетесь каким-то транспортным протоколом.
🦾
🦾 IT-Раздевалка 💪
2022-01-12 16:46
S Dmitry
Ну вы же пользуетесь каким-то транспортным протоколом.
HTTP
S
S Dmitry
2022-01-12 16:58
Почему тогда не использовать HTTPS?
🦾
🦾 IT-Раздевалка 💪
2022-01-12 17:00
S Dmitry
Почему тогда не использовать HTTPS?
Имеется ввиду, HTTPS
Мне кажется, мы о разных проблемах говорим: задача требует подписи тела запросов, а не только самих запросов. Для этого решили использовать HMAC, но поскольку он симетричный его придется делать под каждого клиента и хранить это где-то у себя, но вопрос был в том, как это сделать секурно. Об этом я расскажу в следующем посте
S
S Dmitry
2022-01-12 17:02
Вам надо скрыть данные от серверного кода? Зачем повторно шифровать то, что уже зашифрованно?
🦾
🦾 IT-Раздевалка 💪
2022-01-12 17:04
S Dmitry
Вам надо скрыть данные от серверного кода? Зачем повторно шифровать то, что уже зашифрованно?
Для того, чтобы убедиться, что нам отправляет запрос именно тот, от кого мы его ожидаем
Лучше всего на ваш вопрос ответит описание HMAC (https://ru.wikipedia.org/wiki/HMAC), большинство API, производящие транзакции (Stripe, Яндекс, Тинькофф, etc.) используют именно его формирования подписи при запросе на транзакцию
S
S Dmitry
2022-01-12 17:06
Когда вы устанавливаете соединение с сервером, то он может проверить сертификат клиента. Это и будет проверкой, что клиент тот, что нужно.
🦾
🦾 IT-Раздевалка 💪
2022-01-12 17:07
S Dmitry
Когда вы устанавливаете соединение с сервером, то он может проверить сертификат клиента. Это и будет проверкой, что клиент тот, что нужно.
Получается, вы предлагаете выпускать сертификаты под клиентов и самостоятельно проверять, что это именно те сертификаты, которые выпустили мы?
S
S Dmitry
2022-01-12 17:08
Если у клиентов нет своих сертификатов, то да.
S
S Dmitry
2022-01-12 17:09
В запросе будет identity клиента и его можно проверить.
🦾
🦾 IT-Раздевалка 💪
2022-01-12 17:11
S Dmitry
Если у клиентов нет своих сертификатов, то да.
Теперь понял)
🦾
🦾 IT-Раздевалка 💪
2022-01-12 17:11
S Dmitry
В запросе будет identity клиента и его можно проверить.
Вот как раз следующий вопрос: как на уровне кода мы увидим, что это тот самый клиент с тем самым сертификатом?
S
S Dmitry
2022-01-12 17:12
В транспортном протоколе есть identity клиента. Это может быть сертификат. И вы можете напимер проверить, что сертификат выдан вами.
S
S Dmitry
2022-01-12 17:14
Я пользовался wcf , там такое есть. Думаю, что везде есть.
S
S Dmitry
2022-01-12 17:18
Вам надо к ресурсу на сервере давать доступ конретному пользователю? Тогда можете хранить на сервере thumbprint ключа конкретного пользователя.
S
S Dmitry
2022-01-12 17:19
Или в самодельном сертификате, который вы датите пользователю, заполните какое-то поле его именем. И проверяйте имя на сервере.