Зашифровать данные в базе данных

[Palych]

Как раз наоборот: я лично ни разу не видел чтобы в реальных проектах делали не так как Вы описали.
Везде тупо проверяли стоит ли такой сертификат на сервере.
И здесь пока никто не опроверг эту позицию. Наоборот, говорят что так и надо.

Но с другой стороны, чем так сильно плох этот метод?

Мне казалось я это изложил выше.
Попробую ещё раз.

1. Этот метод использует механизм аутентификации не по назначению.
2. Создаётся ложное впечатление что система защищена 100500-битным ключём, используя certificate based authentication. А это не так.
3. Конкретно: поскольку сертификат не привязан к пользователю - невозможно узнать кто вошёл, что ему можно делать, и что он сделал.

[Palych]

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

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

[shadow7256]

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

ну значит кто то, кто имел доступ к этой изолированой сети, помог им утащить все это, не так ведь?

[shadow7256]

3. Конкретно: поскольку сертификат не привязан к пользователю - невозможно узнать кто вошёл, что ему можно делать, и что он сделал.

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

В нашем случае наличие правильного сертификата в HTTP запросе является признаком того, что клиент может пользовать API (любые запросы к API).

В а чем отличие передачи правильного сертификата от передачи username + password? Юзернеймы и пароли где то хранятся (в базе например).. ну а сертификат хранится в Certificate store. И все таки сертификат подделать явно сложнее чем юзернейм и пароль.. нет?

[StrangerR]

Как раз наоборот: я лично ни разу не видел чтобы в реальных проектах делали не так как Вы описали.
Везде тупо проверяли стоит ли такой сертификат на сервере.
И здесь пока никто не опроверг эту позицию. Наоборот, говорят что так и надо.

Но с другой стороны, чем так сильно плох этот метод?

Метод имееет свою цель. Предотвратить кражу креденшиалов подсовыванием (или MITM или через подсунутый DNS) своего сервера вместо штатного.

MITM не получится. Весь разговор с API идет через HTTPS, по другому просто не получится, серверная часть требует client certificate, а в этом случае WEB API Framework даже не станет запускать инстанс сервера, если он вдруг захочет работать по HTTP протоколу.

Подсунутый DNS .. а можно поподробнее, что это такое и каким образом так можно "обмануть" серверную часть приложения?

Если клиент не проверяет сервер. То ставим прокси. Хачим DNS чтобы на него показывал. Пишем весь обмен. Ну а дальше его направляем на сервер. Сервер получит клиентский сертификат и будет счастлив. Конечно если все это еще и шифруется то не факт что поможет но... если клиент согласится работать с прокси то прокси все расшифрует запишет и запустит дальше на реальный сервер так что тот ничего не заметит кроме неверного IP.

Поэтому проверка сертификата сервера имеет много смысла. А клиент все равно логин пароль вводит и сертификатом больше или меньше мало там что меняет. Так, еще один невысокий заборчик. Если клиента захакают то и сертификат утащат если он не железный в USB стике зашит. Да и если зашит, клиента уже захакали - можно и с него все запустить... Это уже случай фатальный, против захаканного клиента только MFA поможет да и то если он не на ту же железку пойдет.

[Palych]

3. Конкретно: поскольку сертификат не привязан к пользователю - невозможно узнать кто вошёл, что ему можно делать, и что он сделал.

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

В нашем случае наличие правильного сертификата в HTTP запросе является признаком того, что клиент может пользовать API (любые запросы к API).

В а чем отличие передачи правильного сертификата от передачи username + password? Юзернеймы и пароли где то хранятся (в базе например).. ну а сертификат хранится в Certificate store. И все таки сертификат подделать явно сложнее чем юзернейм и пароль.. нет?

Допустим вы отключили одного из клиентов.
Он одолжил сертификат у другого клиента, поставил его себе, и продолжает работать.
Как вы отловите сей неприятный факт?
Допустим вы это обнаружили. Начальство требует почистить транзакции совершенные нарушителем...
Ваши действия?

А вообще - этот метод вполне годный, главное понимать его ограничения.

[kostik78]

3. Конкретно: поскольку сертификат не привязан к пользователю - невозможно узнать кто вошёл, что ему можно делать, и что он сделал.

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

В нашем случае наличие правильного сертификата в HTTP запросе является признаком того, что клиент может пользовать API (любые запросы к API).

В а чем отличие передачи правильного сертификата от передачи username + password? Юзернеймы и пароли где то хранятся (в базе например).. ну а сертификат хранится в Certificate store. И все таки сертификат подделать явно сложнее чем юзернейм и пароль.. нет?

Допустим вы отключили одного из клиентов.
Он одолжил сертификат у другого клиента, поставил его себе, и продолжает работать.
Как вы отловите сей неприятный факт?
Допустим вы это обнаружили. Начальство требует почистить транзакции совершенные нарушителем...
Ваши действия?

А вообще - этот метод вполне годный, главное понимать его ограничения.

Если сертификат именной то проблем нету. В этом случае сервер не только проверяет валидность сертификата но вытаскивает кому принадлежит и далее таже схема что и традиционными username + password. Только стадия проверки пасворда сведена к проверки валидности и то что сертификат не отозван
Практически весь DRM сделан на такой схеме с именными сертификатами и ничего работает. Все взломы DRM происходят уже после получения ключиков декриптования контента.

Опять же я говорю про mutual SSL когда оба: клиент и сервер проверяют сертификаты друг дружки. Уточняю на всякий случай а то тут в топике уже разные схемы мелькали

[Palych]

Если сертификат именной то проблем нету. В этом случае сервер не только проверяет валидность сертификата но вытаскивает кому принадлежит и далее таже схема что и традиционными username + password.

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

[kostik78]

Если сертификат именной то проблем нету. В этом случае сервер не только проверяет валидность сертификата но вытаскивает кому принадлежит и далее таже схема что и традиционными username + password.

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

Ну я это вижу повсеместно и применяеться это обычно в случаях когда тебуеться passwordless именная auth при этом ещё хочется чтобы MitM не возник.

Вы говорите скорее всего про server to server mutual SSL. Там любят прикрутить self-sign один на всех что есть глупо. По нормальному даже если делать selfsign то с CA и intermediates с разными subj по которым можно определять уровни доступа кому куда можно, чтобы не получилась так - сперли сертификат с одного микросервиса а получили доступ ко всей платформе

[shadow7256]

Допустим вы отключили одного из клиентов.

у нас специфика такая, что мы не отключаем конкретные клиентские станции у заказчика. Наши клиенты - довольно крупные организации (в том числе федеральные). Мы им ставим столько станций клиентских сколько им надо по контракту, а уж дальше они сами рулят, кого отключать, а кого нет. И отключают они станцию не просто удалив сертификат, а полностью стирают клиентский софт с комптьютера.

В нашем случае задача client certificate authentication при работе с API это убедится, что просто кто угодно не сможет обращаться к API, а даже если вдруг кто то "украдет" сертификат (что вполне возможно), то чтобы правильно обратиться к API и сделать что то "вредное", то надо знать еще кучу других деталей.

Как вы отловите сей неприятный факт?

бывают случаи, когда какая то станция вдруг начинает присылать данные которые не соответствуют тому формату, который ожидает API, но это не из за того, что кто то пытается взломать что то, а просто из за misconfiguration и сам же заказчик это быстро обнаруживает и просит нас посмотреть логи, потому что его станция не получает ответ от нашей API. мы быстро посмотрим и объясним заказчику "почему Володька сбрил усы".

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

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

А вообще - этот метод вполне годный, главное понимать его ограничения.

ограничения мы понимаем, главное чтобы это понимал заказчик

[dama123]

В нашем случае задача client certificate authentication при работе с API это убедится, что просто кто угодно не сможет обращаться к API, а даже если вдруг кто то "украдет" сертификат (что вполне возможно), то чтобы правильно обратиться к API и сделать что то "вредное", то надо знать еще кучу других деталей.

Я правильно понимаю, что mutual SSL connection на основе сертификата _не_ устанавливается? Если это так, то использование сертификата в данном случае - security theater и ничем не лучше пароля. Безопасность основанная на том, что кто-то не знает "кучу других деталей" вызывает улыбку.

[StrangerR]

В нашем случае задача client certificate authentication при работе с API это убедится, что просто кто угодно не сможет обращаться к API, а даже если вдруг кто то "украдет" сертификат (что вполне возможно), то чтобы правильно обратиться к API и сделать что то "вредное", то надо знать еще кучу других деталей.

Я правильно понимаю, что mutual SSL connection на основе сертификата _не_ устанавливается? Если это так, то использование сертификата в данном случае - security theater и ничем не лучше пароля. Безопасность основанная на том, что кто-то не знает "кучу других деталей" вызывает улыбку.

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

[Palych]

В нашем случае задача client certificate authentication при работе с API это убедится, что просто кто угодно не сможет обращаться к API, а даже если вдруг кто то "украдет" сертификат (что вполне возможно), то чтобы правильно обратиться к API и сделать что то "вредное", то надо знать еще кучу других деталей.

Я правильно понимаю, что mutual SSL connection на основе сертификата _не_ устанавливается? Если это так, то использование сертификата в данном случае - security theater и ничем не лучше пароля. Безопасность основанная на том, что кто-то не знает "кучу других деталей" вызывает улыбку.

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

Одно дело когда эти детали придумал разработчик Вася, использовать сборник анекдотов в качестве ключа.
Другое дело - когда детали в том что стандартные инструменты используются неправильно.
И особенно - когда это распространённая практика.

[StrangerR]

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

[Palych]

Справедливости ради стоит отметить что есть пожалуй один пример когда такой подход оправдан:
Если у сервиса ровно один клиент по дизайну.
И такая ситуация вполне распространёна.
P.S. при условии что будут использоваться только self signed certificates.