Я делаю похожую вещь в приложении, над которым работаю. Вы можете использовать комбинацию шифрования с открытым ключом, SSL и цепочки ключей местного телефона.
Прежде всего, все коммуникации между iPhone и сервером должны быть зашифрованы. Это довольно просто, если вы используете HTTP POST-запросы и SSL. Это также мешает анализаторам пакетов.
Когда ваше приложение запускается, оно ищет внутри локальной цепочки ключей открытый ключ RSA для сервера и сохраненное значение хеш-функции. Если он не найден, он связывается с вашим сервером с UDID телефона, который сервер использует (вместе с системным временем) для генерации хэша. Он отправляет обратно копию хэша и его открытый ключ на телефон. Затем сервер создает запись в локальной базе данных (скажем, MYSQL) с UDID и хэшем, который он отправил обратно, чтобы он мог использовать ее для проверки позже.
Приложение на iPhone сохраняет хеш и открытый ключ сервера в локальной цепочке ключей безопасности. Это все рукопожатие за кулисами, то есть никакого взаимодействия с пользователем. Это делается только при первом запуске приложения.
С тех пор каждый раз, когда вы хотите отправить электронное письмо, ваше приложение форматирует ваше сообщение (часть изображения + JSON), привязывает свой собственный UDID и значение хеш-функции, полученное с сервера, а затем использует сервер. открытый ключ у него есть в цепочке для ключей, и RSA шифрует весь беспорядок. Он добавляет это к телу HTTP POST на сервер и отправляет его (через SSL).
Сервер получает сообщение, использует свой личный ключ RSA для дешифрования сообщения, анализирует его, ищет UDID телефона в своей базе данных и сравнивает полученные значения хеш-функции с тем, который был сохранен после первого запуска, для создания уверен, что это телефон, с которым он уже сделал рукопожатие. Если проверено, он принимает пользовательские данные и форматирует их как почтовое сообщение SMTP и отправляет их в пути. Затем он отвечает обратно на телефон со статусом.
Это устанавливает двустороннее рукопожатие между телефоном и сервером. Учетные записи на уровне пользователей не были созданы, и все это за кадром. Единственная информация, которую вы сохраняете на сервере - это UDID телефона анонимно, поэтому не должно быть проблем с конфиденциальностью. Связь защищена (SSL), сервер принимает запросы только от телефонов, которые прошли через квитирование, сохранили вычисленный хэш, и, в довершение, весь пакет шифруется с помощью шифрования с открытым ключом.
Если вы хотите, чтобы все было интересно, время от времени вы можете отправлять обратно новый вычисленный хеш с результатами вашего статуса и попросить телефон заменить тот, что находится в цепочке для ключей. Таким образом, даже если после всего этого кто-то взломает вашу схему, ему придется следить за изменениями с течением времени.
Если пользователь удаляет ваше приложение и переустанавливает его или переходит на новый телефон, вы просто делаете рукопожатие снова. Стоимость дополнительной записи базы данных на сервере. Если это проблема, вы также можете сохранить дату «последней транзакции» с записью на сервере, а затем истекать пустые записи каждые N месяцев и заставлять телефон проходить новое рукопожатие (вместо того, чтобы считать это сообщением об ошибке). Если подумать, вы можете сделать это в любом случае. Стоимость - небольшая задержка время от времени, когда телефон снова проходит последовательность рукопожатия.
Чтобы сделать это вдвойне интересным, сервер, который выполняет это первое рукопожатие, может быть сервером, отличным от того, который фактически выполняет работу позже. Сервер квитирования также отправляет обратно конечную точку URL-адреса, куда должны отправляться последующие запросы, и iphone также сохраняет его в цепочке для ключей. Таким образом, даже если ваше приложение будет декомпилировано, все, что они получат, это URL конечной точки рукопожатия. Поскольку большая часть данных хранится во время выполнения в цепочке для ключей, статический анализ вашего кода с взломанного телефона не даст ничего особенного.
Также для повышения производительности вы можете захотеть поставить запрос в очередь на сервер, как только он будет проверен, и позволить пользователю вернуться к тому, что он делает, а затем с помощью задания cron откачать сообщения SMTP периодически. Преимущество в том, что ответ пользователя лучше. Недостатком является то, что если адрес электронной почты плохой, у вас нет возможности ответить на них, если вы не полюбите push-уведомления. Я бы сделал это пользовательским предпочтением и позволил бы им решать, хотят ли они ждать подтверждения.
Все технические элементы для этого уже существуют на iPhone (т. Е. Сторонние библиотеки не нужны), и их должно быть легко внедрить на сервере с Rails или Django.