После удаления и повторной установки приложения iOS сохраняет вход, а Android — нет. Как проверить, что причина в различиях жизненного цикла защищённого хранилища?
Нужно сравнить поведение именно защищённого хранилища при удалении и повторной установке, исключив серверную сессию, резервное копирование и обычное локальное хранилище. На iOS данные Keychain могут пережить удаление приложения, тогда как ключи Android Keystore обычно удаляются вместе с приложением, поэтому зашифрованный токен после переустановки становится недоступен.
Это не универсальное правило для любого приложения: результат зависит от способа хранения, настроек резервного копирования, области доступа и реализации восстановления сессии.
Мобильные платформы разделяют обычное хранилище приложения и хранилище секретов. Такой подход появился из-за необходимости защищать токены, ключи и учётные данные от чтения другими приложениями и одновременно учитывать жизненный цикл приложения, его удаление, обновление и восстановление устройства.
Keychain проектировался как системное хранилище учётных данных, независимое от обычного контейнера приложения. Android Keystore прежде всего защищает криптографические ключи и связывает их жизненный цикл с системой и, во многих случаях, с удалением приложения.
Если после переустановки пользователь неожиданно остаётся авторизованным, это может быть как корректным поведением, так и утечкой сессионного секрета. Обратная ситуация также неоднозначна: потеря входа может быть ожидаемым результатом удаления ключа, а может означать ошибку восстановления или истёкшую серверную сессию.
Нужно различить как минимум четыре сценария: обновление поверх установленного приложения, удаление с последующей установкой, восстановление из резервной копии и установку на чистое устройство. Ошибка в таком тесте может привести либо к нарушению безопасности, либо к неверным ожиданиям продукта относительно сохранения входа.
Сначала создают контролируемую сессию и фиксируют, где хранится её секрет: в Keychain, в связке Android Keystore с зашифрованным хранилищем или только в обычном локальном контейнере. Затем выполняют один сценарий за раз: принудительное завершение, обновление, удаление, повторную установку и запуск без восстановления резервной копии.
Для доказательства причины проверяют не только результат авторизации, но и наличие исходного секрета после переустановки. Если iOS повторно использует доступный элемент Keychain, а Android не может расшифровать данные из-за удаления ключа Keystore, различие объясняется жизненным циклом платформенного хранилища. Если сервер выдаёт новую сессию автоматически, это ещё не доказывает сохранность локального токена.
Контрольный вариант — заменить защищённое хранилище тестовым маркером и проверить его отдельно от API. Также важно проверить разные режимы установки: обновление обычно сохраняет контейнер приложения, а удаление и установка заново должны рассматриваться как отдельный жизненный цикл.
На iOS сохранение Keychain после удаления не следует считать гарантией для всех конфигураций: имеют значение тип элемента, группа доступа и политика восстановления. На Android нельзя делать вывод только по исчезновению файла: зашифрованный файл может остаться, но ключ для его расшифровки уже недоступен. С точки зрения безопасности автоматическое сохранение входа после удаления требует явного продуктового решения и оценки риска на общем устройстве.
После переустановки iOS-приложение автоматически входило в аккаунт, а Android показывал экран авторизации. Рассматривались три варианта: считать поведение iOS эталонным, отключить автологин везде или отдельно исследовать источник секрета.
Первый вариант был отклонён: одинаковый пользовательский результат не доказывает одинаковую модель безопасности. Второй ухудшал удобство и не объяснял причину. Выбранный вариант проверял наличие тестового токена в защищённом хранилище, состояние ключа шифрования, факт резервного восстановления и сетевой ответ сервера.
Выяснилось, что iOS повторно находила элемент Keychain после удаления приложения, а Android терял ключ Keystore при удалении. Продукт решил не восстанавливать сессию после удаления на обеих платформах: это сделало поведение предсказуемым и снизило риск сохранения доступа на переданном или общем устройстве.
Нет. Элемент Keychain может существовать независимо от контейнера приложения и быть доступным после повторной установки. Но это зависит от типа элемента, группы доступа, политики синхронизации и конкретной реализации, поэтому поведение нужно подтверждать отдельным тестом, а не считать безусловной гарантией платформы.
Нет. Приложение могло получить новую сессию через резервную копию, связанный аккаунт, серверный механизм восстановления или другой сохранённый идентификатор. Нужно проверить локальный секрет, сетевые запросы и состояние сервера, например отличить предъявление старого токена от получения нового.
Потому что данные могут сохраниться, а ключ Android Keystore — исчезнуть или стать недоступным после удаления приложения. В таком случае файл физически существует, но восстановить секрет невозможно. Корректный тест проверяет не наличие файла, а успешное чтение и расшифровку секрета с последующей проверкой фактического состояния сессии.