Как приложение Google iOS сохраняет и восстанавливает активные учетные записи после удаления приложения?

На устройстве iOS 8 я установил Google Hangouts, и при первом запуске он предварительно заполнил учетную запись, которая ранее была связана с другим и давно удаленным приложением Google.

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

Затем я переустановил Google Hangouts и запустил его. У него ВСЕ ЕЩЕ была активна старая учетная запись. Это не только загадочное поведение, но и довольно серьезная уязвимость в системе безопасности и конфиденциальности. Когда приложение удаляется, и особенно когда удаляются все приложения от поставщика, на устройстве не должно оставаться активных учетных записей или данных.

Любые идеи о том, как Google Hangouts узнает о старой учетной записи?

Ответы (3)

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

Связки ключей — это безопасные контейнеры для хранения, а это означает, что когда связка ключей заблокирована, никто не может получить доступ к ее защищенному содержимому. В OS X пользователи могут разблокировать цепочку для ключей, тем самым предоставляя доверенным приложениям доступ к содержимому, введя один мастер-пароль. В iOS каждое приложение всегда имеет доступ к своим элементам связки ключей; пользователя никогда не просят разблокировать связку ключей. В то время как в OS X любое приложение может получить доступ к любому элементу цепочки для ключей, если пользователь дает разрешение, в iOS приложение может получить доступ только к своим собственным элементам цепочки для ключей.

https://developer.apple.com/library/ios/documentation/Security/Conceptual/keychainServConcepts/01introduction/introduction.html

Это кажется наиболее вероятным механизмом, но если это действительно механизм, который использует Google (или любое приложение в этом отношении), он кажется безумно небезопасным и серьезным нарушением конфиденциальности. Я получил доступ к учетной записи Google другого человека, просто установив приложение от Google, когда на устройстве не было других приложений Google. Похоже, что есть способ очистить недавно установленные приложения: stackoverflow.com/questions/4747404/… но Hangouts этого не сделал. Также, похоже, у пользователя нет способа удалить элементы цепочки ключей, не относящиеся к Safari.
Большая проблема безопасности/конфиденциальности Apple заключается в том, что элементы связки ключей не очищаются при удалении приложения (или, в худшем случае, при удалении последнего приложения поставщика). Проблема Apple также заключается в том, что у пользователей нет простого способа удалить отдельные (не относящиеся к Safari) элементы связки ключей. И проблема безопасности/конфиденциальности Google заключается в том, что они позволяют логину сохраняться при удалении приложения (включая удаление всех приложений Google).
Я не согласен с тем, что это большая проблема безопасности/конфиденциальности. Если кто-то дал вам свое устройство и беспокоился о своих данных, он должен был сначала их стереть. Я бы никогда не дал устройство кому-то с данными все еще на нем. У приложения нет механизма для удаления своих элементов цепочки для ключей, поэтому вы не можете винить Google и здесь. Я согласен, однако, что было бы хорошо, если бы Apple предоставила нам возможность редактировать нашу связку ключей, подобно тому, как вы можете зайти в настройки Safari на устройстве iOS и отредактировать сохраненные учетные данные.
Да, если бы я избавлялся от устройства, я бы его стер, хотя я уверен, что многие люди забывают или не знают, как это сделать. Но я думаю, что это очень контринтуитивное поведение. Распространено совместное использование iPad членами семьи и/или друзьями, но это не должно подразумевать постоянные активные входы в удаленные приложения.
Другой вариант использования — удаление приложения (или даже всех приложений в группе приложений), но позже желание переустановить приложение с новым идентификатором, не связанным со старым. Если старые данные восстанавливаются из резервной копии, это становится невозможным.

Вероятно, в качестве метода используется iCloud, возможно, iCloud Key-Value Store .

Что касается этого хранилища…

Общее пространство, доступное в хранилище ключей и значений iCloud вашего приложения, составляет 1 МБ на пользователя. Максимальное количество ключей, которое можно указать, равно 1024, а предельный размер каждого значения, связанного с ключом, составляет 1 МБ. Например, если вы храните одно большое значение размером ровно 1 МБ для одного ключа, это полностью расходует вашу квоту для данного пользователя вашего приложения. Если вы храните 1 КБ данных для каждого ключа, вы можете использовать 1000 пар ключ-значение. Максимальная длина ключевой строки составляет 64 байта при использовании кодировки UTF8. Размер данных ваших кумулятивных строк ключей не учитывается в общей квоте в 1 МБ для хранилища ключей и значений iCloud; скорее, ваши ключевые строки (которые максимум потребляют 64 КБ) учитываются в общем выделении iCloud для пользователя.

(Источник: Концептуальное чтение Apple Developer для ограничений данных iCloud Key-Value Storage, см. ссылку выше)

Короче говоря, разработчики могут получать доступ к данным через пары KV iCloud через NSUbiquitousKeyValueStore, хранить объекты, хранящиеся в NSDictionary(до 64 КБ на элемент, до 1024 ключей, а общий размер должен быть менее 1 МБ), и извлекать их позже.

Изменить: хранилище iCloud Key-Value не так безопасно, как связки ключей. Google может использовать цепочки ключей, но они также могут хранить зашифрованные данные в хранилище «ключ-значение», учитывая проблемы с безопасностью iCloud. Может быть, использовать имя устройства как способ дешифрования?

У приложений Google не было разрешений для iCloud, поэтому, скорее всего, это связка ключей.
@pseudon KVS не требует разрешения.
Возможно тогда. Это также было бы нелогичным поведением для пользователя, который никогда не ожидал бы, что приложение сможет постоянно хранить активный логин в своем iCloud, особенно для удаленного приложения. Может ли приложение использовать iCloud KV Store, если iCloud не зарегистрирован или вообще не используется на устройстве?
@pseudon, о котором я не знаю.

...в iOS приложение может получить доступ только к своим элементам связки ключей

Поставщики могут обмениваться данными между своими приложениями с помощью связки ключей, если они используют группу связки ключей , определенную в правах в их пакете приложений; «собственный» означает поставщика, а не приложения.

Как указывали другие, записи цепочки для ключей могут не очищаться неявно.

Поскольку самая широкая область этого типа «отслеживания» ограничена одним поставщиком с установленными приложениями, это значительно уменьшает поверхность риска безопасности (по сравнению с общим доступом UUID или UIPsteboard — оба удалены/закрыты).

Важно отметить, что продукты Apple в настоящее время предназначены для «одиночных пользователей»; Apple пока не предлагает разделения пользователей (например, любой зарегистрированный отпечаток пальца разблокирует все устройство, поэтому, если у вас есть друг/ребенок с зарегистрированным отпечатком пальца, они получают точно такой же доступ, как и вы).

Добавление к ответам DDPWNAGE и Алистера (поскольку у меня недостаточно представителей для комментариев), но указание того, как все приложения Google могут получить доступ только к одной записи цепочки для ключей.

Как приложение Google iOS сохраняет и восстанавливает активные учетные записи после удаления приложения?
СпросиСетьПолитика конфиденциальности1y, 0v