Основная идея в том, что посредством Lua описываются типы объектов, методы и делегаты. Т.е. код должен быть в той же сборке. Поднимать приложение в дырявом докере и общаться с ним по сокету - то еще удовольствие, к тому же решение остается кривым. Т.е. в случае залетной птицы мы не сольем всю базу и не похерим систему, но при перезапуске получим тот же сценарий. Как итог - вечно стоящий сервис. Не выход((
Это как раз понятно. Вопрос в том, как именно надо заморочиться, чтобы создать потенциальному злоумышленнику побольше геморроя? Понятно, что тут и фантазия, и "секретность алгоритмов" (прямое нарушение правила Керкхоффа), но толковое, рабочее и популярное что-нибудь есть?
Помимо прочего, насколько я понимаю, мы вытягиваем данные один раз - при покупке. Но речь идет о подписке, контент появляется много раз за месяц, а покупка только один раз в месяц.
Посмотрел. Прикол в том, что SQLCipher шифрует БД через AES256, а где хранить ключ - решает разработчик. Допустим, мы его положим рядом с БД в файлик. И? Тогда сливаем ключ, расшифровываем БД.
Зашить в исходный код? Декомпиляция кода apk расковыряет статичные данные, долго, но реально.
Единственное решение, которое на данный момент не понимаю, но которое рекоммендуют многие (в т.ч. Гугл) - AndroidKeyStore. Что это за зверь до конца не понял. Это фиговина для подписания приложения, т.е. защита приложения от подмены. Но как там ключик хранить, или использовать тот, который туда вшит (когда генерируется сертификат для подписи в приложение вшивается ключ) - не понятно. Да и как там с безопасностью? Если есть физический доступ к девайсу - выковырять можно что угодно.
1. не всегда пользователь может это сделать, и не всегда знает, что ему нужно это делать (обычно сим восстанавливают). Необходимо учитывать, что пользователь может "Тупануть"
2. И что это дает?
3. Смс приходит на тот же девайс. Если по п.1. сим не заблокировано - не помеха.
4. А как программа поймет, что ее запускает не "хозяин", а "злоумышленник"? Никак. И значит при каждом входе "Хозяину" нужно вбивать длинющий пароль, а это минус в удобстве использования
5. Это да, но на какой срок? если 1 час - см.п. 4. если месяц - то и толку не будет
6. И что это дает? телефон у злоумышленника, смс у него же. Он получит новый, корректный пин. Даже ломать ничего не надо
7. Сомневаюсь, что подобные вещи используются (кроме, разве что, позиционирования. если запускаешь из другого города - да, надо перелогиниться. но если девайс упёрли и в течении часа, в той же локации пытатся все провернуть - проблем не будет)
Вопрос в том, можно ли реализовать всю эту систему средствами криптографии? Хотя, организационные меры тоже интересны, но ничего толкового я придумать не смог. Или мешаем пользователю жить, или надеемся, что он не дурак. И то и другое - плохо.
Возникает вопрос в механизме работы SQLCipher'a. Если у злоумышленника есть физический доступ к девайсу, неужели нельзя выковырять ключ, которым зашифровано БД? Если нет - то почему?
З.Ы. Спасибо за наводку, юуду в эту сторону копать, но пока непонятно, как оно работает))
Firebase, насколько я понимаю, это механизм двухвфакторной аутентификации посредством Email. В моем случае я использую отправку СМС (да, их тоже можно перехватить, но для мобильного приложения я считаю это более
а. удобным
б. надежным). Но Firebase хранит сессионный ключ на локали (что не мешает его вытянуть при физическом доступе к девайсу). Он защищает от попытки взлома без доступа к девайсу, но не спасает от последнего. Помимо прочего, требует постоянного подключения к сети Интернет, а это не удобно, для решения моей задачи.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
P.S. Аллюминька не умеет Core( Но NeoLua умеет, ее допилить можно