Приветствую, ребята! Столкнулся с интересной задачей. Обычно для защиты данных между

фронтом и бэком использую JWT-токены. Но в этот раз требования интереснее:

- с бэкенда на фронт должны прийти персональные данные в зашифрованном виде.
- на фронте к этим данным нужно добавить еще некоторые данные
- полученный набор данных должен уйти с фронтенда на бэкенд опять же в зашифрованном виде.

JWT сразу не подходит, т.к.на фронте дописать что то в него не выйдет.

Подскажите, пожалуйста, как обычно поступают в таких случаях?

https

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

Так они и так зашифрованы

смысл от шифрования, если все ключи всё равно будут доступны на клиенте

Если клиент правильно настроен, то даже у его пользователя нет возможности, получить доступ к этим ключам.

Это как надо настраивать клиент? Сомневаюсь что можно консоль браузерную как-то заблокировать

У нас было запрещено все. У chrome есть спец политики безопастности.

Ну это у вас, у среднестатистического пользолвателя это сделать не возможно

А надо добавлять данные или изменять?

пользователю и не надо это делать. Это нужно только для корпоративной безопастности. С помощью СКЗИ можно настроить любой компьютер так, что не изменить программную среду, не похитить данные в принципе с него будет не возможно.

Да настроить можно, но речь выше шла о клиенте среднестатистическом, а не о конкретном клиенте

Что за среднестатистический клиент? Админ локалхоста?

Пользователь сайта например

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

но с сайтом проще, подключил стой юзерскрипт и у тебя уже собственный интерфейс с нужными возможностями при сохранении того же протокола общения с сервером

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

на самом деле ключи и пароли не должны быть доступны в том числе и программисту, тоступ иключительно директора и его замов

Ну есть электронные ключи для этого. ПОэтому при желание даже у "программистов" доступа не будет. Слабое звено однако это лица с наивысшим уровнем допуска. Например те кто подготавливает "чистые системы". Поэтому круг таких лиц всегда должен быть минимальным.

им во время работы можно предоставить тестовые фейковые данные, тогда и этот штат не будет необходимости ограничивать

Красиво сказано.

Я немного про другое. Если я настраиваю систему защиты, то у меня есть куча вариантов оставить для себя "черный ход". Соответственно я и являюсь наиболее слабым звеном защиты такой системы. А следовательно моя жизнь в таком случае также должна быть воплощением принципа паранойи и недопущения применения ко мне "физического доступа" и методов социальной инженерии.

паранойа это наше естественное состояние, с другой стороны та же паранойа может быть мотивом оставить эти самые дыры

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

А как же госуслуги? Они допускают любой браузер и там есть ценная инфа

Ну я знаю что их ломают все кому не лень, в смысле учетные данные воруют.

Ну случаи бывают, но единичные, чистую среду тоже все кому не день ломают

Нет, Когда госуслуги пользуют на домашнем компе или телефоне это явно не "чистая среда". А скорее очень сильно загрязненная.

Да, но и чистые среды ломаются на раз два

У вас достаточно квалификации для этого?

Для того чтобы делать подобные утверждения, да

Тогда возможно вы и правы. Я специально например не занимался взломом СКЗИ, кроме запуска сертифицированной сканеров уязвимостей. Однако если ваша квалификация поззволяет обойти аппартное шифрование жесткого диска в целях изменения защищенной программной среды, то как говориться снимаю шляпу в нижайшем поклоне.

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