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

[kostik78]

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

Предлагаю приложить эту логику к basic authentication:

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

Не видим подвоха?

Данный способ вполне можно использовать с SSL mutual authorization. Последнее обычно используется для предотвращения Man-in-the-middle attack и это всё-таки работает на уровне транспорта. Так что одно не заменяет другое а вполне дополняет.

[dama123]

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

Предлагаю приложить эту логику к basic authentication:

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

Не видим подвоха?

Можно не говорить загадками? Решение с сертификатом - не очень, ничем не лучше чем basic authentication. В mutual TLS, кроме сертификата проверяется наличие private key, который соответствует public key из сертификата.

[Palych]

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]

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

Предлагаю приложить эту логику к basic authentication:

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

Не видим подвоха?

Можно не говорить загадками? Решение с сертификатом - не очень, ничем не лучше чем basic authentication. В mutual TLS, кроме сертификата проверяется наличие private key, который соответствует public key из сертификата.

Извините конечно но в чем по Вашему заключается проверка сертификата ? Просто Вы утверждаете про private key и public key и что они как то отдельно от сертификата и это выглядит сильно странно.

[Flash-04]

А кто-то предлагает без пароля? Это как бы разные уровни проверки авторизации пользователя. Вначале покажи аусвайс, потом ещё и пароль. Каждый этап затрудняет вражеский доступ.
Оффтоп: вот что меня реально напрягает, так повсемесиный переход с Hardware RSA токен на софтовый. Копируй сколько хочешь.

[kostik78]

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]

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]

Сертификаты не могут не быть именными. Это по сути многокомпонентное имя (X.509?...) подписанное электронным ключём.
Я говорю о том, что если "тупо проверить стоит ли такой сертификат на машине сервера" - это имя игнорируется, что ломает весь процесс аутентификации/авторизации.

Ок. Говорим об одном и том же в принципе.
Чтобы под итожить с mutual SSL auth можно использовать в двух воркфлов:
* для предотвращения MitM тогда нету user auth (просто проверка наличия правильного клиентского и серверного сертификата) и нужно добавлять что то ещё для user auth
* использование SSL cert с дополнительными полями для user auth - в данном случае защита от MitM + user auth.

[shadow7256]

Я говорю о том, что если "тупо проверить стоит ли такой сертификат на машине сервера" - это имя игнорируется, что ломает весь процесс аутентификации/авторизации.

ну Вы докопались просто )) Я просто привел пример одного из методов валидации сертификата ) Конечно можно и нужно использовать более изощренный способ нежели простая проверка стоит ли такой сертификат на машине пользователя.. вариантов много.

[dama123]

Извините конечно но в чем по Вашему заключается проверка сертификата ? Просто Вы утверждаете про private key и public key и что они как то отдельно от сертификата и это выглядит сильно странно.

Нет проблем. Проверка сертификата заключается в том, что сертификат ( т.е. public key) подписан CA private key. Это делается с использованием CA public key ( или key chain).
Результат этой проверки - можно дoверять pubic key, который содержится в сертификате.

[StrangerR]

Любая защита может быть взломана а хардварный ключ утащен

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

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

Расчитывать на защиту через юзеров можно только как на дополнительное препятствие - честные не полезут, нечестный зацепится и порвет штаны. Но как что то серьезное это просто несерьезно. Замучаетесь бегать дырки затыкать и все одно ваши же девелоперы дыр неумышленно накрутят. Ее естественно тоже ставят, но перед рвом с водой или после забора с колючкой да и то приходится туда Карацюпу с его Шариком запускать чтобы бегал и нарушителей обгавкивал. Проще считать что этого забора нет вообще и строить защиту не расчитывая на него, но конечно собака с пограничником и легкий штакетник как еще один уровень защиты никому еще не мешали. Правда кормить их надо, пограничника и его собаку.

[StrangerR]

А кто-то предлагает без пароля? Это как бы разные уровни проверки авторизации пользователя. Вначале покажи аусвайс, потом ещё и пароль. Каждый этап затрудняет вражеский доступ.
Оффтоп: вот что меня реально напрягает, так повсемесиный переход с Hardware RSA токен на софтовый. Копируй сколько хочешь.

Нуу если делать 2 стадийную регистрацию - например когда не просто QT код с гугла сканируем а когда софт токен сначала кажет приваси свой код а потом сканирует QT - то оно уже просто так не копируется. А так то да, конечно. Хот н сегодня больше любят PUSH методы. Чем меня они радуют - а кто сказал что мы не пушаем запрос на то же устройство с которого заходим и которое забыли на скамейке? Я от гугла нежданно получил запрос сразу на все свои планшетки. В этом смысле токены чуть секьюрнее но с другой стороны их да, можно и скопировать если криво сделано, бумажный можно сосканить, и так далее. Ну и потом если это H токен а не T то каждый заход то вызывает смену и если кто то без вас зашел то у вас следующий код уже не сработает (он уже использован). В этом смысле, кстати, T токены менее безопасны иногда.

Может кстати сертификат шифровать как то так что только по мак адресу девайса он расшифруется? Тогда тупой перенос на другой девайс сразу сломает его. Это все можно обойти но оно уже усилий потребует и еать шанс что поймается.

Сертификаты не могут не быть именными. Это по сути многокомпонентное имя (X.509?...) подписанное электронным ключём.

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

[kostik78]

Любая защита может быть взломана а хардварный ключ утащен

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

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

Расчитывать на защиту через юзеров можно только как на дополнительное препятствие - честные не полезут, нечестный зацепится и порвет штаны. Но как что то серьезное это просто несерьезно. Замучаетесь бегать дырки затыкать и все одно ваши же девелоперы дыр неумышленно накрутят. Ее естественно тоже ставят, но перед рвом с водой или после забора с колючкой да и то приходится туда Карацюпу с его Шариком запускать чтобы бегал и нарушителей обгавкивал. Проще считать что этого забора нет вообще и строить защиту не расчитывая на него, но конечно собака с пограничником и легкий штакетник как еще один уровень защиты никому еще не мешали. Правда кормить их надо, пограничника и его собаку.

Все верно написано про layers of defense. Не совсем понятен Ваш "наезд" про не серьезность защиты на уровне изоляции пользователей ибо в контексте обсуждаемого вопроса данное решение возможно и реально при наличии других слоев что Вы описали, включая ограниченая возможность ескалации привилегии.

[Palych]

Я говорю о том, что если "тупо проверить стоит ли такой сертификат на машине сервера" - это имя игнорируется, что ломает весь процесс аутентификации/авторизации.

ну Вы докопались просто )) Я просто привел пример одного из методов валидации сертификата ) Конечно можно и нужно использовать более изощренный способ нежели простая проверка стоит ли такой сертификат на машине пользователя.. вариантов много.

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

[Palych]

Это как бы разные уровни проверки авторизации пользователя. Вначале покажи аусвайс, потом ещё и пароль. Каждый этап затрудняет вражеский доступ.

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

[shadow7256]

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

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

[StrangerR]

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

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

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

[shadow7256]

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

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

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

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

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

[Flash-04]

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

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

[Flash-04]

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

https://www.kaspersky.com/resource-cent ... itions/dns

[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 поможет да и то если он не на ту же железку пойдет.