Ответ 1

Сохранение конфиденциальных данных на устройстве

Это сильно зависит от вашей аудитории. Обычно ОС Android запрещает приложениям обращаться к другим файлам (т.е. Базам данных, файлам предпочтений, обычным файлам, хранящимся в приватной папке приложения) через проверенные разрешения файлов Linux. Однако на корневых устройствах приложение может получить доступ root и прочитать все. Несколько вещей, о которых нужно подумать:

• Если вы знаете, что у ваших пользователей не будет root (например, если вы не распространяете приложение через Android Market, но только в своей компании или что-то в этом роде), вы можете просто полагаться на безопасность на базе файловой системы Android.
• Если пользователь получает root-доступ, он будет очень осторожен, какое приложение он дает, что привилегия
• Если приложение получает доступ root, это может привести к большому опустошению. Информация в вашем приложении может быть наименее опасной для пользователя.
• Корни ведут к нулевой гарантии. В том числе в приложениях. Вы не можете нести ответственность за утечку информации о корневом телефоне.

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

В противном случае шифрование - это путь. Это не на 100% безопасно (хакер может декомпилировать ваше приложение и выяснить, как расшифровать данные), но это большая боль, чтобы взломать и остановить большинство хакеров. Особенно, если вы запутываете свой код чем-то вроде ProGuard.

Перенос конфиденциальных данных с сервера на устройство

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

• Использовать систему ключей API. Включите этот ключ API во все ваши запросы и проверьте его на стороне сервера, прежде чем отправлять ответ. Помните, что, поскольку вы используете HTTPS, злоумышленник не сможет просто использовать сетевой сниффер, чтобы узнать ваш ключ API. Тем не менее, это довольно легко понять, если кто-то декомпилирует ваше приложение, поэтому вы можете запутать его еще больше (помимо использования ProGuard). Например, вы можете оставить ключ API разбитым на части вокруг вашего кода (например, как статические члены в двух или трех классах). Затем, когда вы отправляете запрос, вы просто объединяете все эти части. Вы даже можете применить некоторые другие преобразования (например, смещение битов), чтобы еще сложнее было выяснить, из декомпилированного кода.
• Вы можете генерировать ключ каждый раз, когда вы отправляете запрос. Этот ключ будет сгенерирован с использованием некоторой логики, которую вы только знаете, чтобы вы могли реализовать ее как на стороне клиента, так и на стороне сервера. Например, запрос может включать следующие параметры:
  time=1321802432&key=[generated-key]
  где generated-key генерируется из параметра time. Например: md5(time + salt). Когда сервер получает этот запрос, он может выполнять две функции:
  • Убедитесь, что key действительно равен md5(time + salt) (обратите внимание, что только клиент и сервер знают соль и могут быть запутаны аналогично вышеприведенному ключу API) и
  • Убедитесь, что time не слишком далеко назад (например, если прошло более 1-2 минут, считайте, что запрос недействителен).

Второй метод более полезен, если вы также выполняете простые HTTP-запросы, где каждый может видеть отправленные параметры. Кроме того, гораздо сложнее разобраться с декомпилированным кодом. Особенно, если вы распространили логику вычисления ключей на несколько классов.

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

Ответ 2

(появился здесь благодаря поиску Google)

В последнее время я очень много разбираюсь в этой проблеме, и эта страница пришла очень много благодаря поисковым запросам Google и Bing. Широко принятая процедура безопасного хранения данных на устройстве заключается в использовании сильного алгоритма шифрования, такого как AES. Более сложный вопрос: "AES требует безопасного ключа. Что вы делаете с ключом?"

Недавно Google анонсировала облачное решение для хранения приложений, поэтому вы можете рассмотреть возможность хранения ключа там, если это позволяет ситуация. В противном случае кажется, что лучше получить ключ вне устройства, например, на сервере. Если вы можете сделать попытку пользователя в ПИН-код, это будет работать наилучшим образом. Вы можете выполнить деривацию паролей, чтобы сохранить пароль, и вы можете повторить вывод, чтобы подтвердить пароль.

Без части "пробивание пользователя в ПИН" я не нашел много хороших ответов на этот вопрос. Однако НЕ ТРЕБУЙТЕ КОДИРОВАТЬ КЛЮЧ, ЕСЛИ ВЫ ДОЛЖНЫ ХРАНИТЬ ОДИН С ПРИЛОЖЕНИЕМ. Как минимум, сгенерируйте ключ, используя защищенный генератор паролей и/или функцию деривации, такую ​​как PBKDF2 (функция деривации на основе пароля 2).

Если я правильно прочитал сообщения, Google сказал, что один из подходов состоит в том, чтобы сгенерировать ключ после запуска приложения в первый раз, сохранить ключ через флаг MODE_PRIVATE для множества операций ввода-вывода файлов и использовать это как ключ. Вы также можете получить другие ключи на основе этого главного ключа, а NIST на самом деле предлагает что-то по этим линиям.

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

Ответ 3

Использовать SSL на HTTPS для передачи данных вместо HTTP, вам необходимо настроить сертификаты на веб-сервере, не очень уверенно, как это работает.

Если вы действительно обеспокоены данными, то затем зашифруйте его с помощью уникального алгоритма перед отправкой и расшифровкой его, когда он достигнет приложения. Я думаю, что все об этом.. Если вам не нужно что-то действительно сильное, тогда создайте свой собственный протокол на основе TCP и/или используйте другой порт. Возможно, это поможет

http://en.wikipedia.org/wiki/Secure_Sockets_Layer http://developer.android.com/reference/javax/net/ssl/package-summary.html http://blog.synyx.de/2010/06/android-and-self-signed-ssl-certificates/

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

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

Ответ 4

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

Ответ 5

Каждое приложение на Android работает в безопасной среде песочницы, поэтому другие процессы в системе не могут получить доступ к вашему коду или личным данным без надлежащего подтверждения. Но все же есть много уязвимостей, которые могут быть вызваны плохим дизайном приложений. Эта ссылка с сайта разработчиков Android советует вам некоторые полезные советы по безопасности - https://developer.android.com/training/articles/security-tips.html