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

kostik78
Уже с Приветом
Posts: 3170
Joined: 17 May 2007 14:07

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

Post by kostik78 »

Palych wrote: 21 Apr 2021 19:00
shadow7256 wrote: 21 Apr 2021 15:13 API требует наличия client certificate в каждом запросе, считывает сертификат и делает валидацию (много способов, но один из способов тупо проверить стоит ли такой сертификат на машине сервера).
Предлагаю приложить эту логику к basic authentication:

API требует наличия client user:password в каждом запросе, считывает password и делает валидацию (много способов, но один из способов тупо проверить есть ли такой пароль на машине сервера).

Не видим подвоха?
Данный способ вполне можно использовать с SSL mutual authorization. Последнее обычно используется для предотвращения Man-in-the-middle attack и это всё-таки работает на уровне транспорта. Так что одно не заменяет другое а вполне дополняет.
dama123
Уже с Приветом
Posts: 742
Joined: 08 Apr 2021 01:54

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

Post by dama123 »

Palych wrote: 21 Apr 2021 19:00
shadow7256 wrote: 21 Apr 2021 15:13 API требует наличия client certificate в каждом запросе, считывает сертификат и делает валидацию (много способов, но один из способов тупо проверить стоит ли такой сертификат на машине сервера).
Предлагаю приложить эту логику к basic authentication:

API требует наличия client user:password в каждом запросе, считывает password и делает валидацию (много способов, но один из способов тупо проверить есть ли такой пароль на машине сервера).

Не видим подвоха?
Можно не говорить загадками? Решение с сертификатом - не очень, ничем не лучше чем basic authentication. В mutual TLS, кроме сертификата проверяется наличие private key, который соответствует public key из сертификата.
Palych
Уже с Приветом
Posts: 13604
Joined: 16 Jan 2001 10:01

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

Post by Palych »

dama123 wrote: 21 Apr 2021 19:52
Palych wrote: 21 Apr 2021 19:00
shadow7256 wrote: 21 Apr 2021 15:13 API требует наличия client certificate в каждом запросе, считывает сертификат и делает валидацию (много способов, но один из способов тупо проверить стоит ли такой сертификат на машине сервера).
Предлагаю приложить эту логику к basic authentication:

API требует наличия client user:password в каждом запросе, считывает password и делает валидацию (много способов, но один из способов тупо проверить есть ли такой пароль на машине сервера).

Не видим подвоха?
Можно не говорить загадками? Если передавать сертификат по открытому каналу, то решение не очень, ничем не лучше чем basic authentication. В mutual TLS, кроме сертификата проверяется наличие private key, который соответствует public key из сертификата.
Первый подвох в том, что сертификаты (и пароли в данном примере) не привязаны к пользователю. Например, если у кого-то сертификат протух - от может одолжить/украсть сертификат другого пользователя, и провайдера этого не заметит.
Фундаментальный подвох в том что результатом аутентификации является true/false, есть доступ или нет.
А должно быть - аутентичное имя пользователя, в данном случае подтвержденное сертификатом и подписавшим его CA.
Особенно коварно получается когда начальство решает что self signed certificates - не серьёзно для солидной системы, и добавляет какой-нибудь публичный CA. Тогда доступ открывается полностью.
kostik78
Уже с Приветом
Posts: 3170
Joined: 17 May 2007 14:07

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

Post by kostik78 »

dama123 wrote: 21 Apr 2021 19:52
Palych wrote: 21 Apr 2021 19:00
shadow7256 wrote: 21 Apr 2021 15:13 API требует наличия client certificate в каждом запросе, считывает сертификат и делает валидацию (много способов, но один из способов тупо проверить стоит ли такой сертификат на машине сервера).
Предлагаю приложить эту логику к basic authentication:

API требует наличия client user:password в каждом запросе, считывает password и делает валидацию (много способов, но один из способов тупо проверить есть ли такой пароль на машине сервера).

Не видим подвоха?
Можно не говорить загадками? Решение с сертификатом - не очень, ничем не лучше чем basic authentication. В mutual TLS, кроме сертификата проверяется наличие private key, который соответствует public key из сертификата.
Извините конечно но в чем по Вашему заключается проверка сертификата ? Просто Вы утверждаете про private key и public key и что они как то отдельно от сертификата и это выглядит сильно странно.
User avatar
Flash-04
Уже с Приветом
Posts: 63377
Joined: 03 Nov 2004 05:31
Location: RU -> Toronto, ON

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

Post by Flash-04 »

А кто-то предлагает без пароля? Это как бы разные уровни проверки авторизации пользователя. Вначале покажи аусвайс, потом ещё и пароль. Каждый этап затрудняет вражеский доступ.
Оффтоп: вот что меня реально напрягает, так повсемесиный переход с Hardware RSA токен на софтовый. Копируй сколько хочешь.
Not everyone believes what I believe but my beliefs do not require them to.
kostik78
Уже с Приветом
Posts: 3170
Joined: 17 May 2007 14:07

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

Post by kostik78 »

Palych wrote: 21 Apr 2021 20:06
dama123 wrote: 21 Apr 2021 19:52
Palych wrote: 21 Apr 2021 19:00
shadow7256 wrote: 21 Apr 2021 15:13 API требует наличия client certificate в каждом запросе, считывает сертификат и делает валидацию (много способов, но один из способов тупо проверить стоит ли такой сертификат на машине сервера).
Предлагаю приложить эту логику к basic authentication:

API требует наличия client user:password в каждом запросе, считывает password и делает валидацию (много способов, но один из способов тупо проверить есть ли такой пароль на машине сервера).

Не видим подвоха?
Можно не говорить загадками? Если передавать сертификат по открытому каналу, то решение не очень, ничем не лучше чем basic authentication. В mutual TLS, кроме сертификата проверяется наличие private key, который соответствует public key из сертификата.
Первый подвох в том, что сертификаты (и пароли в данном примере) не привязаны к пользователю. Например, если у кого-то сертификат протух - от может одолжить/украсть сертификат другого пользователя, и провайдера этого не заметит.
Фундаментальный подвох в том что результатом аутентификации является true/false, есть доступ или нет.
А должно быть - аутентичное имя пользователя, в данном случае подтвержденное сертификатом и подписавшим его CA.
Особенно коварно получается когда начальство решает что self signed certificates - не серьёзно для солидной системы, и добавляет какой-нибудь публичный CA. Тогда доступ открывается полностью.
Ошибаетесь. Сертификаты вполне могут быть именными и это не просто true/false.
Palych
Уже с Приветом
Posts: 13604
Joined: 16 Jan 2001 10:01

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

Post by Palych »

kostik78 wrote: 21 Apr 2021 20:10
Palych wrote: 21 Apr 2021 20:06
dama123 wrote: 21 Apr 2021 19:52
Palych wrote: 21 Apr 2021 19:00
shadow7256 wrote: 21 Apr 2021 15:13 API требует наличия client certificate в каждом запросе, считывает сертификат и делает валидацию (много способов, но один из способов тупо проверить стоит ли такой сертификат на машине сервера).
Предлагаю приложить эту логику к basic authentication:

API требует наличия client user:password в каждом запросе, считывает password и делает валидацию (много способов, но один из способов тупо проверить есть ли такой пароль на машине сервера).

Не видим подвоха?
Можно не говорить загадками? Если передавать сертификат по открытому каналу, то решение не очень, ничем не лучше чем basic authentication. В mutual TLS, кроме сертификата проверяется наличие private key, который соответствует public key из сертификата.
Первый подвох в том, что сертификаты (и пароли в данном примере) не привязаны к пользователю. Например, если у кого-то сертификат протух - от может одолжить/украсть сертификат другого пользователя, и провайдера этого не заметит.
Фундаментальный подвох в том что результатом аутентификации является true/false, есть доступ или нет.
А должно быть - аутентичное имя пользователя, в данном случае подтвержденное сертификатом и подписавшим его CA.
Особенно коварно получается когда начальство решает что self signed certificates - не серьёзно для солидной системы, и добавляет какой-нибудь публичный CA. Тогда доступ открывается полностью.
Ошибаетесь. Сертификаты вполне могут быть именными и это не просто true/false.
Сертификаты не могут не быть именными. Это по сути многокомпонентное имя (X.509?...) подписанное электронным ключём.
Я говорю о том, что если "тупо проверить стоит ли такой сертификат на машине сервера" - это имя игнорируется, что ломает весь процесс аутентификации/авторизации.
kostik78
Уже с Приветом
Posts: 3170
Joined: 17 May 2007 14:07

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

Post by kostik78 »

Palych wrote: 21 Apr 2021 21:12 Сертификаты не могут не быть именными. Это по сути многокомпонентное имя (X.509?...) подписанное электронным ключём.
Я говорю о том, что если "тупо проверить стоит ли такой сертификат на машине сервера" - это имя игнорируется, что ломает весь процесс аутентификации/авторизации.
Ок. Говорим об одном и том же в принципе.
Чтобы под итожить с mutual SSL auth можно использовать в двух воркфлов:
* для предотвращения MitM тогда нету user auth (просто проверка наличия правильного клиентского и серверного сертификата) и нужно добавлять что то ещё для user auth
* использование SSL cert с дополнительными полями для user auth - в данном случае защита от MitM + user auth.
shadow7256
Уже с Приветом
Posts: 9381
Joined: 18 Mar 2004 15:11
Location: New York -> FL

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

Post by shadow7256 »

Palych wrote: 21 Apr 2021 21:12 Я говорю о том, что если "тупо проверить стоит ли такой сертификат на машине сервера" - это имя игнорируется, что ломает весь процесс аутентификации/авторизации.
ну Вы докопались просто :))) Я просто привел пример одного из методов валидации сертификата :)) Конечно можно и нужно использовать более изощренный способ нежели простая проверка стоит ли такой сертификат на машине пользователя.. вариантов много.
dama123
Уже с Приветом
Posts: 742
Joined: 08 Apr 2021 01:54

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

Post by dama123 »

kostik78 wrote: 21 Apr 2021 20:09 Извините конечно но в чем по Вашему заключается проверка сертификата ? Просто Вы утверждаете про private key и public key и что они как то отдельно от сертификата и это выглядит сильно странно.
Нет проблем. Проверка сертификата заключается в том, что сертификат ( т.е. public key) подписан CA private key. Это делается с использованием CA public key ( или key chain).
Результат этой проверки - можно дoверять pubic key, который содержится в сертификате.
StrangerR
Уже с Приветом
Posts: 37986
Joined: 14 Dec 2006 20:13
Location: USA

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

Post by StrangerR »

kostik78 wrote: 21 Apr 2021 18:48
Любая защита может быть взломана а хардварный ключ утащен :pain1:

Далее по Вашей аксиоме никто не должен был использовать user level access and privileges. Но используется и много где более того во этот пунктик часто фигурирует в сертификация. P.S. На линухе все системные приложения обычно имеют уникального юзвера для каждого приложения и ничего работает как то десятки лет.

Ну в целом то да но
- понятно что любая защита это забор
- защита через сегрегацию сети это ров с водой и высокая стена за ним с колючкой.
- защита через виртуалки это забор с колючей проволокой
- защита через юзеров это невысокий штакетник да еще и с дырами которые постоянно белки и койоты прогрызают
- защита через докеров это табличка _не влезай убьет_.

Расчитывать на защиту через юзеров можно только как на дополнительное препятствие - честные не полезут, нечестный зацепится и порвет штаны. Но как что то серьезное это просто несерьезно. Замучаетесь бегать дырки затыкать и все одно ваши же девелоперы дыр неумышленно накрутят. Ее естественно тоже ставят, но перед рвом с водой или после забора с колючкой да и то приходится туда Карацюпу с его Шариком запускать чтобы бегал и нарушителей обгавкивал. Проще считать что этого забора нет вообще и строить защиту не расчитывая на него, но конечно собака с пограничником и легкий штакетник как еще один уровень защиты никому еще не мешали. Правда кормить их надо, пограничника и его собаку.
StrangerR
Уже с Приветом
Posts: 37986
Joined: 14 Dec 2006 20:13
Location: USA

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

Post by StrangerR »

Flash-04 wrote: 21 Apr 2021 20:10 А кто-то предлагает без пароля? Это как бы разные уровни проверки авторизации пользователя. Вначале покажи аусвайс, потом ещё и пароль. Каждый этап затрудняет вражеский доступ.
Оффтоп: вот что меня реально напрягает, так повсемесиный переход с Hardware RSA токен на софтовый. Копируй сколько хочешь.
Нуу если делать 2 стадийную регистрацию - например когда не просто QT код с гугла сканируем а когда софт токен сначала кажет приваси свой код а потом сканирует QT - то оно уже просто так не копируется. А так то да, конечно. Хот н сегодня больше любят PUSH методы. Чем меня они радуют - а кто сказал что мы не пушаем запрос на то же устройство с которого заходим и которое забыли на скамейке? Я от гугла нежданно получил запрос сразу на все свои планшетки. В этом смысле токены чуть секьюрнее но с другой стороны их да, можно и скопировать если криво сделано, бумажный можно сосканить, и так далее. Ну и потом если это H токен а не T то каждый заход то вызывает смену и если кто то без вас зашел то у вас следующий код уже не сработает (он уже использован). В этом смысле, кстати, T токены менее безопасны иногда.

Может кстати сертификат шифровать как то так что только по мак адресу девайса он расшифруется? Тогда тупой перенос на другой девайс сразу сломает его. Это все можно обойти но оно уже усилий потребует и еать шанс что поймается.
Сертификаты не могут не быть именными. Это по сути многокомпонентное имя (X.509?...) подписанное электронным ключём.
Нуу, не надо так сразу. Вполне бывают сертификаты с именем пользователя. Никто же не мешает его в сертификат засунуть и потом проверить. Помнится мне что то в эту сторону в ssh вроде делали но до конца не уверен.
kostik78
Уже с Приветом
Posts: 3170
Joined: 17 May 2007 14:07

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

Post by kostik78 »

StrangerR wrote: 22 Apr 2021 00:42
kostik78 wrote: 21 Apr 2021 18:48
Любая защита может быть взломана а хардварный ключ утащен :pain1:

Далее по Вашей аксиоме никто не должен был использовать user level access and privileges. Но используется и много где более того во этот пунктик часто фигурирует в сертификация. P.S. На линухе все системные приложения обычно имеют уникального юзвера для каждого приложения и ничего работает как то десятки лет.

Ну в целом то да но
- понятно что любая защита это забор
- защита через сегрегацию сети это ров с водой и высокая стена за ним с колючкой.
- защита через виртуалки это забор с колючей проволокой
- защита через юзеров это невысокий штакетник да еще и с дырами которые постоянно белки и койоты прогрызают
- защита через докеров это табличка _не влезай убьет_.

Расчитывать на защиту через юзеров можно только как на дополнительное препятствие - честные не полезут, нечестный зацепится и порвет штаны. Но как что то серьезное это просто несерьезно. Замучаетесь бегать дырки затыкать и все одно ваши же девелоперы дыр неумышленно накрутят. Ее естественно тоже ставят, но перед рвом с водой или после забора с колючкой да и то приходится туда Карацюпу с его Шариком запускать чтобы бегал и нарушителей обгавкивал. Проще считать что этого забора нет вообще и строить защиту не расчитывая на него, но конечно собака с пограничником и легкий штакетник как еще один уровень защиты никому еще не мешали. Правда кормить их надо, пограничника и его собаку.
Все верно написано про layers of defense. Не совсем понятен Ваш "наезд" про не серьезность защиты на уровне изоляции пользователей ибо в контексте обсуждаемого вопроса данное решение возможно и реально при наличии других слоев что Вы описали, включая ограниченая возможность ескалации привилегии.
Palych
Уже с Приветом
Posts: 13604
Joined: 16 Jan 2001 10:01

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

Post by Palych »

shadow7256 wrote: 21 Apr 2021 21:55
Palych wrote: 21 Apr 2021 21:12 Я говорю о том, что если "тупо проверить стоит ли такой сертификат на машине сервера" - это имя игнорируется, что ломает весь процесс аутентификации/авторизации.
ну Вы докопались просто :))) Я просто привел пример одного из методов валидации сертификата :)) Конечно можно и нужно использовать более изощренный способ нежели простая проверка стоит ли такой сертификат на машине пользователя.. вариантов много.
Как раз наоборот: я лично ни разу не видел чтобы в реальных проектах делали не так как Вы описали.
Везде тупо проверяли стоит ли такой сертификат на сервере.
И здесь пока никто не опроверг эту позицию. Наоборот, говорят что так и надо.
Palych
Уже с Приветом
Posts: 13604
Joined: 16 Jan 2001 10:01

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

Post by Palych »

Flash-04 wrote: 21 Apr 2021 20:10Это как бы разные уровни проверки авторизации пользователя. Вначале покажи аусвайс, потом ещё и пароль. Каждый этап затрудняет вражеский доступ.
В данном случае аусвайс содержит имя владельца, фотографию, и проч. И всё это в защищённом чипе. И аппарат для чтения имеется.
Но вахтёрам даётся инструкция проверять только водяные знаки.
shadow7256
Уже с Приветом
Posts: 9381
Joined: 18 Mar 2004 15:11
Location: New York -> FL

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

Post by shadow7256 »

Palych wrote: 22 Apr 2021 02:08 Как раз наоборот: я лично ни разу не видел чтобы в реальных проектах делали не так как Вы описали.
Везде тупо проверяли стоит ли такой сертификат на сервере.
И здесь пока никто не опроверг эту позицию. Наоборот, говорят что так и надо.
Но с другой стороны, чем так сильно плох этот метод?
StrangerR
Уже с Приветом
Posts: 37986
Joined: 14 Dec 2006 20:13
Location: USA

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

Post by StrangerR »

shadow7256 wrote: 22 Apr 2021 12:45
Palych wrote: 22 Apr 2021 02:08 Как раз наоборот: я лично ни разу не видел чтобы в реальных проектах делали не так как Вы описали.
Везде тупо проверяли стоит ли такой сертификат на сервере.
И здесь пока никто не опроверг эту позицию. Наоборот, говорят что так и надо.
Но с другой стороны, чем так сильно плох этот метод?
Метод имееет свою цель. Предотвратить кражу креденшиалов подсовыванием (или MITM или через подсунутый DNS) своего сервера вместо штатного.
shadow7256
Уже с Приветом
Posts: 9381
Joined: 18 Mar 2004 15:11
Location: New York -> FL

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

Post by shadow7256 »

StrangerR wrote: 22 Apr 2021 16:25
shadow7256 wrote: 22 Apr 2021 12:45
Palych wrote: 22 Apr 2021 02:08 Как раз наоборот: я лично ни разу не видел чтобы в реальных проектах делали не так как Вы описали.
Везде тупо проверяли стоит ли такой сертификат на сервере.
И здесь пока никто не опроверг эту позицию. Наоборот, говорят что так и надо.
Но с другой стороны, чем так сильно плох этот метод?
Метод имееет свою цель. Предотвратить кражу креденшиалов подсовыванием (или MITM или через подсунутый DNS) своего сервера вместо штатного.
MITM не получится. Весь разговор с API идет через HTTPS, по другому просто не получится, серверная часть требует client certificate, а в этом случае WEB API Framework даже не станет запускать инстанс сервера, если он вдруг захочет работать по HTTP протоколу.

Подсунутый DNS .. а можно поподробнее, что это такое и каким образом так можно "обмануть" серверную часть приложения?
User avatar
Flash-04
Уже с Приветом
Posts: 63377
Joined: 03 Nov 2004 05:31
Location: RU -> Toronto, ON

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

Post by Flash-04 »

StrangerR wrote: 22 Apr 2021 16:25 Метод имееет свою цель. Предотвратить кражу креденшиалов подсовыванием (или MITM или через подсунутый DNS) своего сервера вместо штатного.
вот именно. Абсолютной защиты нет. NSA и тот взламывали. Shadowbrokers стащили их тулкит с сервера не имеющего интернет соединения и находящегося в изолированной сети.
Но затрудняя работу взломщику, повышаем свои шансы выжить.
Not everyone believes what I believe but my beliefs do not require them to.
User avatar
Flash-04
Уже с Приветом
Posts: 63377
Joined: 03 Nov 2004 05:31
Location: RU -> Toronto, ON

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

Post by Flash-04 »

shadow7256 wrote: 22 Apr 2021 17:54 Подсунутый DNS .. а можно поподробнее, что это такое и каким образом так можно "обмануть" серверную часть приложения?
https://www.kaspersky.com/resource-cent ... itions/dns
Not everyone believes what I believe but my beliefs do not require them to.
Palych
Уже с Приветом
Posts: 13604
Joined: 16 Jan 2001 10:01

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

Post by Palych »

shadow7256 wrote: 22 Apr 2021 12:45
Palych wrote: 22 Apr 2021 02:08 Как раз наоборот: я лично ни разу не видел чтобы в реальных проектах делали не так как Вы описали.
Везде тупо проверяли стоит ли такой сертификат на сервере.
И здесь пока никто не опроверг эту позицию. Наоборот, говорят что так и надо.
Но с другой стороны, чем так сильно плох этот метод?
Мне казалось я это изложил выше.
Попробую ещё раз.

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

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

Post by Palych »

Flash-04 wrote: 22 Apr 2021 18:25 Но затрудняя работу взломщику, повышаем свои шансы выжить.
Если механизм используется неправильно, значит разработки не понимают как он работает.
Если взломщик понимает это: шансы взломщика увеличиваются.
shadow7256
Уже с Приветом
Posts: 9381
Joined: 18 Mar 2004 15:11
Location: New York -> FL

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

Post by shadow7256 »

Flash-04 wrote: 22 Apr 2021 18:25 вот именно. Абсолютной защиты нет. NSA и тот взламывали. Shadowbrokers стащили их тулкит с сервера не имеющего интернет соединения и находящегося в изолированной сети.
Но затрудняя работу взломщику, повышаем свои шансы выжить.
ну значит кто то, кто имел доступ к этой изолированой сети, помог им утащить все это, не так ведь?
shadow7256
Уже с Приветом
Posts: 9381
Joined: 18 Mar 2004 15:11
Location: New York -> FL

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

Post by shadow7256 »

Palych wrote: 22 Apr 2021 20:38 3. Конкретно: поскольку сертификат не привязан к пользователю - невозможно узнать кто вошёл, что ему можно делать, и что он сделал.
в нашем случае у кастомера несколько сотен клиентских станций, которые будут обращаться к API. Если какая то станция в HTTP запросе прикрепит сертификат, которого нет на стороне сервера, то сервер даст тут же отлуп. Запишет в лог, с какого IP пришел запрос и отлупит.

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

В а чем отличие передачи правильного сертификата от передачи username + password? Юзернеймы и пароли где то хранятся (в базе например).. ну а сертификат хранится в Certificate store. И все таки сертификат подделать явно сложнее чем юзернейм и пароль.. нет?
StrangerR
Уже с Приветом
Posts: 37986
Joined: 14 Dec 2006 20:13
Location: USA

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

Post by StrangerR »

shadow7256 wrote: 22 Apr 2021 17:54
StrangerR wrote: 22 Apr 2021 16:25
shadow7256 wrote: 22 Apr 2021 12:45
Palych wrote: 22 Apr 2021 02:08 Как раз наоборот: я лично ни разу не видел чтобы в реальных проектах делали не так как Вы описали.
Везде тупо проверяли стоит ли такой сертификат на сервере.
И здесь пока никто не опроверг эту позицию. Наоборот, говорят что так и надо.
Но с другой стороны, чем так сильно плох этот метод?
Метод имееет свою цель. Предотвратить кражу креденшиалов подсовыванием (или MITM или через подсунутый DNS) своего сервера вместо штатного.
MITM не получится. Весь разговор с API идет через HTTPS, по другому просто не получится, серверная часть требует client certificate, а в этом случае WEB API Framework даже не станет запускать инстанс сервера, если он вдруг захочет работать по HTTP протоколу.

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

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

Return to “Вопросы и новости IT”