Если у атакующего есть рут на клиентской стороне - у него есть тысячи возможностей.

Атака реальна, если чел зарутовал смарт и установил с виду прилично ведущий себя софт. Поэтому, к примеру, (многие? некоторые? все?) банковские клиентские приложухи отказываются работать на рутованых смартах.

JWT это как-бы контейнер

Стоит всем отказаться от использования https как средства защиты данных.

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

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

Атака реальна, если чел зарутовал смарт

Если используются системные сертификаты можно без рута - ставим свой сертификат и через локальный VPN делаем mitm (adguard так делает).

Поэтому, к примеру, (многие? некоторые? все?) банковские клиентские приложухи отказываются работать на рутованых смартах.

Сейчас везде magisk, так что детектить рут или разлоченый бут бесполезно.

без рута - ставим свой сертификат и

Если пиннинг настроен, не получится

можно без рута - ставим свой сертификат и через локальный VPN делаем mitm

Но тебе нужен доступ к телефону чтобы поставить свой сертификат, разве нет? Если есть доступ для установки сертификата я считаю это тот же уровень что и рут.

Сейчас везде magisk, так что детектить рут или разлоченый бут бесполезно.

Не знаком с magisk, расскажи подробнее?

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

В итоге почитав статеек, СО, форумов пришел к выводу что собственно говоря никак не получится. Более того похоже что и Гугл и Фейсбук отправляют текстовый пароль по HTTPS.

Есть левые сервисы которые помогают определить что запрос прислало твое настоящее, неизмененное приложение (https://approov.io/) что немного помогает с тем какие запросы могут приходить.

А, ты про это: по ссылке Фрида и подтасовка сертификатов

но сессионный токен короткоживущий

Насколько например? Один час?

рефреш передаётся клиенту только раз, при аутентификации, его перехватить сложнее. А ещё, рефреш можно оставить на бэке.

Типа делать рефреш без запроса логина у пользователя? А можешь подробнее про то как оставить его на бэке?

Насколько например? Один час?

Нет, совсем мало, несколько минут.

Типа делать рефреш без запроса логина у пользователя?

Нет конечно, но он долгоживущий. В некоторых случаях практически вечный, до перелогина.

А можешь подробнее про то как оставить его на бэке?

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

Как проверить подлинность клиента не могу придумать. Что-то можно сделать в этой ситуации? И насколько реальна такая атака? Все-таки требуется доступ к внутренностям телефона.

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

несколько минут. В некоторых случаях практически вечный, до перелогина.

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

сам генерит новый сессионный и отправляет его клиенту.

А как сервер отправит используя REST?

От мужика) просто используя оригинальное приложение например он не сможет отправлять кастомные запросы с токеном, придется сделать логин. Логин немного сложнее перехватить потому что он происходит раз в некоторое время, а токен летает с каждым запросом.

Все бросил и побежал скупать аппаратные ускорители rot26.

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

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

Не знаком с magisk, расскажи подробнее?

https://4pda.ru/forum/index.php?showtopic=774072 Рут + скрытие рута + репа с крутыми аддонами. Де-факто это стандарт в 2019, позволяет обмануть даже gpay.

От мужика) просто используя оригинальное приложение например он не сможет отправлять кастомные запросы с токеном, придется сделать логин. Логин немного сложнее перехватить потому что он происходит раз в некоторое время, а токен летает с каждым запросом.

Ну смотри, я в этом нихрена не понимаю, поэтому меня не слушай.

Проблема номер раз: Мужик может перехватить токен из любого запроса, сформировать свой запрос, положить в него токен и отправить.

Решение номер раз: Используем какой-нибудь hmac.

Проблема номер два: Даже с использованием hmac мужик может может перехватить запрос и повторять его снова и снова по своему усмотрению.

Решение номер два: В запросе нужна какая-то динамическая компонента, допустим счётчик запросов. Сервер ожидает запрос номер один. Пользователь отправляет запрос номер 1. Запрос, включая номер, «подписан» с помощью hmac. Сервер его исполняет и ожидает запрос номер два. Мужик перехватывает запрос номер один и повторяет его. Сервер его не исполняет, потому что ждёт запрос номер два. Если мужик меняет номер запроса на два, то сервер его тоже не принимает, потому что сломался hmac.

Проблема номер три: Сервер и клиент должны как-то обмениваться ключём для hmac. Ключ может перехватить мужик.

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

Проблема номер четыре: Мужик может перехватить пароль при первом логине. Алсо, у мужика рут, он может тупо прочитать ключ для hmac из памяти.

Решение: Жопа. Мы нагородили бесполезную фигню.

но как я понял именно от пользователя ты и хочет защититься

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

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

Ну вот я к этому сейчас и пришел, приложение не безопасно, сеть не безопасна, обменяться секретами не получается.

Есть всякая хардварная фигня, на данные из которой ни рут, ни ядро не имеют доступа (теоретически). Trusted platform module, arm trustzone, вот это всё. Но я тут совсем не копенгаген, гугли сам.

Главный пароль - имеется в виду юзерский пароль? Его стоит требовать раз в какое-то время это точно.

А ключ (я так понимаю для шифрования) хранить постоянно или как?

Главный пароль - имеется в виду юзерский пароль? Его стоит требовать раз в какое-то время это точно.

Да. Стоит требовать – ну требуй. Суть в том, чтобы его не сохранять на девайсе, вместо него хранить какой-то токен/ключ/сгенерированый пароль.

Первый логин с девайса – юзер вводит пароль. Сервер генерирует токен и отдаёт клиенту. Клиент сохраняет токен и забывает пароль. При следующем запуске клиент логинится с помощью токена.

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

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

А ключ (я так понимаю для шифрования) хранить постоянно или как? Для подписи. Хранить постоянно. Автоматически обновлять.

В общем случае не возможно.

Но имеет смысл прикинуть прибыль злоумышленника от успешной атаки и его затрат на неё.

Более того похоже что и Гугл и Фейсбук отправляют текстовый пароль по HTTPS.

Да что там гугл с мордокнигой, даже ЛОР пользуется https для отправки паролей!

Там где реально нужна безопасность, только один https использовать не стоит.

А что еще можно накрутить поверх?

one time password

one time password куда, когда? У юзера не может быть совсем одноразового пароля, иначе как я узнаю что это этот юзер?

куда

sms, e-mail etc.

когда

после идентификации

sms, e-mail etc.

Это называется 2FA :) Не геморно ли на каждый логин слать?

накрутить поверх?

Правильно мыслишь, если взамен дырявого HTTPS не хочешь ничего сделать, то его надо чем-то сверху обмотать.

ipsec.

Или внутри HTTPS шифровать, например, пакетно gpg. Так может программисту проще будет, чем игралтся с VPN тунелями.

А в чем проблема сделать простейшую аутентификацию с ключом? Даже по http прокатит.

Авторизация: запрашиваешь у сервера разрешение на авторизацию, получаешь некий ключ. Далее его используешь как соль, добавляя к MD5 пароля и вычисляя SHA512 результата + отправляешь SHA512 от случайной последовательности с той же солью. Отправляешь серваку. Если все ОК, тот вычисляет MD5 от твоей случайной последовательности и использует это в качестве дешифрующей.

Аутентификация: все, что клиент хочет отправить серверу, он XOR’ит своей дешифрующей последовательностью. Сервер принимает это дело и опять XOR’ит тем же самым. И никакой man-in-the-middle не сможет этот обмен раскусить.

Прикола ради можно авторизацию повторять каждые N единиц времени.

P.S. Только полный дегенерат будет посылать пароль через интернеты в явном виде! Даже если используется https.

Что мешает хранить хэш пароля и сравнивать с тем хэшем, что присылает клиент? Естественно, соль использовать каждый раз разную.

Интересно, нашел что Whatsapp генерирует и хранит ключи на клиенте, но подробностей пока не нашел: https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf

отправляешь SHA512 от случайной последовательности с той же солью Если все ОК, тот вычисляет MD5 от твоей случайной последовательности и использует это в качестве дешифрующей.

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

Что мешает хранить хэш пароля и сравнивать с тем хэшем, что присылает клиент? Естественно, соль использовать каждый раз разную.

Если клиент хешует - как клиент и сервер могут договориться о соли?

program for cryptanalyzing xor 'encryption' with variable key length

https://www.habets.pp.se/synscan/programs.php?prog=xor-analyze

«Шифровальщиков» с XOR не слушай!

program for cryptanalyzing xor 'encryption' with variable key length

http://www.habets.pp.se/synscan/programs.php?prog=xor-analyze

«Шифровальщиков» с XOR не слушай!

Не в ту сторону свернул, смотри https://tox.chat

А есть описание того как они работают с мобильными клиентами? Главный вопрос хранят ли они ключи на клиенте?

А есть описание того как они работают с мобильными клиентами? Главный вопрос хранят ли они ключи на клиенте?

Серверов несуществует!!!

Все клиентское ПО создает крыптоучетки (ключи) и хранит их запаролеными только у создателя.

Необходимо делать бекап крыптоучетки. Уже года 3 по инету ходит злобный вирь и херит крыптоучетки TOX.

Если система скомпрометирована, то вирус может кейлогером стырить пароль и твою крыптоучетку.

Все клиентское ПО создает крыптоучетки (ключи) и хранит их запаролеными только у создателя.

А как они хранят на мобилках? В Android Keystore / аналоге для iOS?

Оффтопик немного. Как там nim поживает. Вроде как заредизился, но после этого опять тишина. Попробовал искать либо. Но что-то не густо.

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

А как они хранят на мобилках? В Android Keystore / аналоге для iOS?

Не скажу, надо смотреть..

А вообще в РФ сегодня как с разработкой меседжеров которые хоть какую-то крыптографию используют? Ну или в общем сетей с шифрованием типа замены/дополнения HTTPS?

С одной стороны:

Статья 23, Конституции РФ: Что должен знать специалист ИБ на старте (комментарий)

2. Каждый имеет право на тайну переписки, телефонных переговоров, почтовых, телеграфных [b]и иных сообщений[/b]. Ограничение этого права допускается только на основании судебного решения.

С другой стороны подзаконные акты требуют лицензирования деятельности по шифрованию: Что должен знать специалист ИБ на старте (комментарий)

Федеральный закон от 04.05.2011 N 99-ФЗ (ред. от 02.08.2019) «О лицензировании отдельных видов деятельности»

Статья 12. Перечень видов деятельности, на которые требуются лицензии

1. В соответствии с настоящим Федеральным законом лицензированию подлежат следующие виды деятельности:

1. разработка, производство, распространение шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств, …

и

«Уголовный кодекс Российской Федерации» от 13.06.1996 N 63-ФЗ (ред. от 02.08.2019)

УК РФ Статья 171. Незаконное предпринимательство

1. Осуществление предпринимательской деятельности без регистрации или без лицензии в случаях, когда такая лицензия обязательна, ….

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

Сделаешь хорошее дело, зашифруешь трафик своего приложения и в благодарность от Путина и «Единой России» 5 лет тюрьмы!

Вот посмотрите, даже архиватор забанили, наверно потому что кнопочку имел «заархивировать с паролем»: http://www.7-zip.org/

А линуксовую версию не банят: http://p7zip.sourceforge.net/

А, с этим я особо не волнуюсь потому что моя разработка за пределами РФ :)

Насчет 7zip я слышал что они хостинг с кем-то забаненным делят.

У каждой страны свои тараканы!

А, с этим я особо не волнуюсь потому что моя разработка за пределами РФ :)

Сегодня, во времена геноцида, очень много стран ссучились. Мне точно известно:

США - запрет на экспорт криптографии. Разработка и внутренне использование разрешено.

РФ - как выше написал, запрет на разработку и распространение.

Англия - точно не скажу, кажется есть «запрет на крыптографию которую нельзя расшифровать» - слова их премьерминистра.

Канада - Кажись все разрешено, поэтому OpenBSD разрабатывают у них.

Германия - было все разрешено, поэтому разработку GPG перенесли к ним. Но сегодня времена меняются…

Швейцария - Кажись все разрешено. Причем разрешение гарантируется их законами, примерно как у нас: Что должен знать специалист ИБ на старте (комментарий) только противоречащие Конституции подзаконные акты их власть не принимает…

Статья 12. Перечень видов деятельности, на которые требуются лицензии

В соответствии с настоящим Федеральным законом лицензированию подлежат следующие виды деятельности:

разработка, производство, распространение шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств, …

IANAL, но скорее всего это только для случаев, когда ты официально хочешь сертифицировать свой говнокод как некое средство для шифрования. Типа КриптоПро и прочего подобного шлака.

Если трактовать это иначе, то можно

gcc -lssl ...

и сразу с вещами идти сдаваться в полицию 8).