Ключи, учетные данные и хранилище на Android.
В предыдущем материале о безопасности пользовательских данных Android мы рассмотрели шифрование данных с помощью предоставленного пользователем кода. В этом уроке перейдём к хранению учётных данных и ключей. Я начну с ознакомления с учётными данными и закончу примером защиты данных с помощью хранилища ключей KeyStore.
Часто, при работе со сторонней службой, требуется какая-то форма авторизации. Она может быть настолько простой, как /login на стороне пользователя, которая принимает имя пользователя и пароль.
Сначала может показаться, что простое решение — это собрать UI, который будет предлагать пользователю войти в систему, а затем записать и сохранить их данные для входа. Однако, это не лучший метод, так как нашему приложению не нужно знать данные для входа в сторонний аккаунт. Вместо этого, мы можем использовать Диспетчер учётных записей (Account Manager), который уполномочен отрабатывать эту конфиденциальную информацию для нас.
Диспетчер учётных записей
Диспетчер учётных записей (Account Manager) — это централизованный помощник для работы с учётными данными пользователя, поэтому вашему приложению, иметь дело с паролями напрямую не нужно. Часто он предоставляет токен вместо реального имени пользователя и пароля, который можно использовать для выполнения аутентифицированных запросов к службе. Например, при запросе токена OAuth2 .
Иногда, вся необходимая информация уже хранится на устройстве, а иногда Account Manager придётся обращаться к серверу за новым токеном. Вы, наверное, видели раздел Учётные записи в Настройках вашего устройства для разных приложений. И вот как, мы можем получить список доступных учётных записей:
Этому коду потребуется разрешение android.permission.GET_ACCOUNTS . Если вы ищете определённую учётную запись, вы можете найти её вот так:
Как только найдёте учётную запись, её токен можно получить вызвав метод getAuthToken(Account, String, Bundle, Activity, AccountManagerCallback, Handler) . Затем, таки можно использовать как для авторизированных запросов API к сервису. Это может быть RESTful API, в котором вы передаёте параметр токена во время HTTPS-запроса без необходимости знать детали личной учётной записи пользователя.
Так как, у каждой службы будет свой способ проверки подлинности и хранения личных учётных данных, Диспетчер учётных записей предоставляет модули проверки подлинности для реализации сторонней службой. Хотя Android может выполнять вход на многие популярные сервисы, для вашего приложения, вы можете написать свой собственный обработчик авторизации учётной записи и хранилища учётных данных. Это позволит убедиться, что учётные данные зашифрованы. Имейте также в виду, что учётные данные в Диспетчере учётных записей, которые используются другими службами, могут храниться в виде открытого текста, что делает их видимыми для любого, кто имеет рут-права на своё устройство.
Временами вам нужно будет иметь дело с ключами или сертификатами для отдельного лица или сущности, вместо просто данных для входа. Например, когда стороннее приложение отправляет вам файл сертификата, который вам нужно сохранить. Самый распространённый сценарий — это когда приложению нужно авторизироваться на сервере частной организации.
В следующем уроке, мы рассмотрим использование сертификатов для аутентификации и безопасной связи, ну а пока, я всё же хочу рассмотреть, как хранить эти элементы. Изначально Keychain API был создан для очень конкретного использования — установка закрытого ключа или пары сертификатов из файла PKCS#12.
Keychain — связка ключей
Представленный в Android 4.0 (API Level 14), Keychain API управлял ключами. В частности, это работает с объектами PrivateKey и X509Certificate и обеспечивает более безопасный контейнер, чем использование хранилища данных вашего приложения. Связано это с тем, что разрешения закрытых ключей открывают доступ к ключам только вашему приложению и только после авторизации пользователя. Это означает, что, прежде чем, вы сможете использовать хранилище учётных данных, на устройстве должен быть настроен экран блокировки. Кроме того, объекты в связке ключей можно объединить с защитой от оборудования, если доступно.
Код установки сертификата выглядит следующим образом:
Пользователю будет предложено ввести пароль для доступа к закрытому ключу и указать имя сертификата. Для получения ключа, в следующем коде представлен пользовательский интерфейс, который позволяет пользователю выбирать ключ из списка установленных ключей.
Как только выбор сделан, возвращается строка с названием псевдонима alias(final String alias) , где вы можете напрямую получить доступ к закрытому ключу или цепочке сертификатов.
Вооружившись этими знаниями, теперь давайте посмотрим, как мы можем использовать хранилище учётных данных для сохранения конфиденциальных данных.
KeyStore
В предыдущем уроке , мы рассмотрели защиту данных с помощью предоставляемого пользователем пароля. Такой вариант хорош, но требования к приложениям часто уводят от того, чтобы пользователи каждый раз входили в систему и запоминали дополнительный пароль.
Вот где можно использовать KeyStore API. Начиная с API 1, KeyStore используется системой для хранения учётных данных WiFi и VPN. Начиная с 4.3 (API 18), вы можете работать с асимметричными ключами конкретного приложения, а в Android M (API 23) можно хранить симметричный ключ AES. Таким образом, хотя API не позволяет хранить конфиденциальные строки напрямую, эти ключи можно сохранить, а затем использовать для шифрования строк.
Преимущество хранения ключа в хранилище ключей заключается в том, что он позволяет работать с ключами без раскрытия секретного содержимого этого ключа; данным ключа не место в приложении. Помните, что ключи защищаются разрешениями, так что только ваше приложение может получить к ним доступ, и они могут быть дополнительно защищены аппаратным обеспечением, если устройство поддерживает это. Создаётся контейнер, который усложняет извлечение ключей с устройства.
Генерирование нового случайного ключа
В этом примере вместо генерации ключа AES из предоставленного пользователем пароля мы можем автоматически сгенерировать случайный ключ, который будет защищён в хранилище ключей KeyStore. Мы можем сделать это, создав экземпляр KeyGenerator , настроенного на поставщика «AndroidKeyStore» .
Здесь важно обратить внимание на спецификации .setUserAuthenticationRequired(true) и .setUserAuthenticationValidityDurationSeconds(120) . Для этого, обязательно должна быть включена блокировка экрана и ключ должен быть заблокирован, до тех пор, пока пользователь не аутентифицируется.
Изучив документацию .setUserAuthenticationValidityDurationSeconds() , вы увидите, что это означает, что ключ доступен только через определённое количество секунд после аутентификации по паролю, и что для передачи -1 требуется идентификация по отпечатку пальца каждый раз, когда вы хотите получить доступ к ключу. Включение требования для аутентификации также приводит к отзыву ключа, когда пользователь удаляет или изменяет экран блокировки.
Поскольку хранение незащищённого ключа вместе с зашифрованными данными, это как прятать ключ от дома под половик, эти параметры пытаются защитить ключ в состоянии покоя в случае взлома устройства. Примером может служить автономный дамп данных устройства. Если пароль устройства не известен, эти данные, по сути, бесполезны.
Опция .setRandomizedEncryptionRequired(true) включает требование о наличии достаточного количества случайных чисел (каждый раз новый случайный ВИ [вектор инициализации]), чтобы при повторном шифровании одних и тех же данных, зашифрованный результат всё равно не повторялся. Это не позволяет злоумышленнику получить информацию о зашифрованном тексте на основе передачи тех же данных.
Ещё стоит отметить — setUserAuthenticationValidWhileOnBody(boolean remainsValid) , что блокирует ключ, как только устройство обнаружит, что он больше не принадлежит человеку.
Шифрование данных
Теперь, когда ключ хранится в хранилище KeyStore, мы можем создать метод, который зашифрует данные с использованием объекта Cipher , учитывая SecretKey . Это вернёт HashMap , содержащий зашифрованные данные и случайный ВИ, который понадобится для расшифровки данных. Зашифрованные данные вместе с ВИ могут быть сохранены в файл или в открытых настройках.
Расшифровка в массив байтов
Для расшифровки применяется обратный ход. Объект Cipher инициализируется с использованием константы DECRYPT_MODE , и возвращается расшифрованный массив byte[] .
Смотрим на примере
Теперь мы можем посмотреть на пример!
Использование асимметричных ключей RSA для старых устройств
Это хорошее решение для хранения данных в версии M и выше, но что, если ваше приложение поддерживает более ранние версии? Хотя симметричные ключи AES не поддерживаются в M, поддерживаются асимметричные ключи RSA. Это означает, что для достижения того же результата, мы можем использовать RSA ключи и шифрование.
Основное отличие заключается в том, что асимметричная пара ключей содержит два ключа: закрытый и открытый ключ, где открытый ключ шифрует данные, а закрытый ключ расшифровывает их. KeyPairGeneratorSpec передаётся в KeyPairGenerator , который инициализируется с помощью KEY_ALGORITHM_RSA и поставщика AndroidKeyStore .
Для шифрования, из пары ключей мы получаем RSAPublicKey и используем его с объектом Cipher .
Расшифровка выполняется с использованием объекта RSAPrivateKey .
Кое-что об RSA — шифрование медленнее, чем в AES. Для небольших объёмов информации, например, когда вы защищаете строки общих настроек, это не страшно. Если вы обнаружите проблему с производительностью при шифровании больших объёмов данных, то вместо этого вы можете использовать данный пример для шифрования и хранения только ключа AES. И тогда, для остальной части ваших данных, используйте более быстрое шифрование AES, которое обсуждалось в предыдущем уроке . Вы можете сгенерировать новый AES ключ и преобразовать его в массив byte[] , который совместим с этим примером.
Чтобы получить ключ, сделайте вот так:
Довольно много кода! Для простоты примеров, я пропустил обработку исключений. Но помните, что для итогового кода не рекомендуется просто перехватывать все случаи Throwable в одном операторе catch.
Заключение
На этом урок по работе с учётными данными и ключами завершён. Большая часть неразберихи вокруг ключей и хранилища связана с эволюцией ОС Android, но вы можете выбрать, какое решение использовать, учитывая уровень API, поддерживаемый вашим приложением.
Теперь, когда мы рассмотрели лучшие примеры защиты данных в состоянии покоя, следующий урок будет сосредоточен на защите данных при передаче.
Что лучше использовать для защиты аккаунта Google: пароли или ключи доступа?
В марте 2023 года компания Google представила возможность создания «Ключей доступа» (passkeys) для защиты своих аккаунтов вместо классических паролей. На прошлой неделе компания разблокировала возможность создания ключей доступа для всех пользователей. У клиентов Google теперь может возникнуть вполне логичный вопрос: следует ли переходить на ключи доступа или лучше продолжить какое то время использовать пароли?
В данной статье рассмотрим преимущества и недостатки обоих вариантов аутентификации, чтобы вы могли принять взвешенное решение.
Защита аккаунта Google с помощью пароля
Пароли являются самым популярным вариантом аутентификации. Пользователи могут создавать пароли, которые они хотят использовать, но с учетом некоторых ограничений, таких как минимальная длина пароля или наличие определенных символов.
Эта свобода является одной из сильных сторон паролей, но также и источником проблем. Легко запоминающиеся пароли обычно небезопасны, в то время как трудно запоминаемые пароли безопасны, но непрактичны, если только не используется менеджер паролей. Существует также проблема повторного использования паролей. В этом случае, если злоумышленникам удастся взломать один сервис или подобрать пароль методом грубой силы, то они могут получить доступ к вашим аккаунтам на других сайтах и сервисах.
Пароли или их хэши хранятся на сервере сервиса, потому что это единственный способ проверить их, когда пользователь пытается аутентифицироваться.
Для повышения безопасности при использовании паролей многие компании внедрили двухфакторную аутентификацию. Пользователь получит доступ к своему аккаунту только после прохождения второго этапа проверки. Код доступа можно создавать с помощью приложений или отправлять пользователям по электронной почте или в сообщениях.
Хотя двухфакторная аутентификация повышает безопасность учетных записей, она усложняет работу пользователя, поскольку добавляет еще один шаг в процесс входа в систему.
Защита аккаунта Google с помощью ключей доступа
Ключи доступа — новый стандарт аутентификации, который не требует использования пароля. Ключи доступа создаются автоматически на локальном устройстве во время установки, и часть информации никогда не покидает устройство.
Для входа в сервисы или приложения требуется подтверждение пользователя. Это может быть PIN-код или биометрические методы аутентификации. Пароль никогда не используется, и все методы проверки выполняются локально.
Сам процесс входа в аккаунт выполняется быстро и больше не требует второго шага проверки. Одним из основных преимуществ ключей доступа является то, что они делают атаки на пароли бесполезными. Фишинг, перебор паролей или взлом сервера оказываются бессмысленными, потому что пароли больше не вводятся и не хранятся удаленно.
У ключей доступа есть свои недостатки. Их поддержка может быть ограничена некоторыми версиями ОС, браузеров и приложений. Например, для использования ключей доступа Google требуются операционные системы: Windows 10 или новее, macOS Ventura, Chrome OS, iOS 16 или Android 9. Поддержка браузеров официально ограничена Chrome 109 или новее, Microsoft Edge 109 или новее и Safari 16 или новее.
Другие браузеры тоже могут работать с ключами доступа, например Firefox, но официально они не поддерживаются.
Вторая проблема связана с тем, что ключи доступа зависят от устройства. Хотя теоретически синхронизация возможна, большинство сервисов и приложений ее не поддерживают. Ключи доступа нужно создавать на каждом используемом устройстве, чтобы полностью перейти с использования паролей на ключи доступа. Тем не менее, пароль учетной записи Google не будет удален.
Что выбрать: пароли или ключи доступа?
Некоторые пользователи Google не смогут использовать ключи доступа на некоторых устройствах из-за требований.
Защита учетной записи Google с помощью ключей доступа повышает безопасность несколькими способами. Это, определенно, стандарт будущего, на который перейдут многие онлайн-сервисы.
Переход на ключи доступа улучшит уровень безопасности вашего аккаунта. Однако, некоторые пользователи могут подождать, пока синхронизация не станет доступной, особенно если используется много устройств.
Классические пароли пока рано списывать со счетов. Как минимум они должны использоваться на устройствах, которые не поддерживают ключи доступа и на общедоступных компьютерах.
По этому причине большинству клиентов Google может потребоваться какое-то время, чтобы переключаться между паролями и ключами доступа.
Надежные пароли наряду с двухфакторной аутентификацией, хорошим менеджером паролей и использованием здравого смысла в достаточной степени защищают учетную запись Google. Ключи доступа — это будущий стандарт, который будет постоянно улучшаться, но пока находится на ранней стадии развития.
На данный момент сложно дать однозначный ответ. В общем случае, клиенты, которые используют одно поддерживаемое устройство, имеют более высокие шансы полностью перейти на использование ключей доступа, чем пользователи нескольких устройств, браузеров и аккаунтов.
Большинство менеджеров паролей еще не поддерживают ключи доступа, но получат их поддержку в ближайшие месяцы и годы. NordPass, Dashlane, Bitwarden, 1Password и LastPass уже добавили или собираются добавить поддержку беспарольной аутентификации в ближайшее время. Реализация поддержки может отличаться, так как некоторые сервисы добавили поддержку службы управления паролями, в то время как другие планируют добавить опции для хранения паролей других учетных записей с помощью менеджера паролей.
Ключи Passkeys — начало постпарольной эпохи? Не так быстро…
В мае 2023 года компания Google присоединилась к общему тренду отказа от паролей — и выкатила passkeys (ключи доступа), которые позволяют войти в аккаунт без пароля, а по пальцу, лицу, локальному пинкоду или аппаратному ключу. То есть авторизоваться в Google тем же методом, которым вы авторизуетесь в операционной системе (на смартфоне или ПК). Ранее об отказе от паролей заявила Microsoft.
По своей природе парольные ключи невозможно «потерять». Ими не может воспользоваться злоумышленник. Разработчики заявляют, что такие ключи надёжнее обычных паролей и даже надёжнее, чем 2FA через SMS, поскольку SMS легко перехватить.
Хотя некоторые говорят о начале постпарольной эпохи, всё-таки подобный оптимизм кажется слегка чрезмерным.
С мая ключи доступа поддерживаются на всех аккаунтах Google, а с июня — на некоторых аккаунтах Workspace и Cloud (тестирование). Браузер Chrome поддерживает парольные ключи с декабря.
Что это такое?
Ключи доступа как метод двухэтапной верификации (2-Step Verification, 2SV) — это более удобная и безопасная альтернатива паролям. Они работают на всех основных платформах и браузерах, позволяя входить в систему, разблокируя компьютер или мобильное устройство с помощью отпечатка пальца, распознавания лица или локального пинкода.
Чтобы создать ключ доступа, нужно перейти по специальной ссылке и авторизоваться в учётной записи.
После этого Google начнёт запрашивать ключ при входе или выполнении важных действий в аккаунте.
Сам ключ хранится на локальном компьютере или мобильном устройстве пользователя. Для доступа к нему устройство проверяет отпечаток пальца или лицо, или пинкод, чтобы подтвердить личность владельца.
В отличие от паролей, ключи доступа существуют только локально. Их невозможно записать или случайно передать злоумышленнику. Когда вы используете ключ входа, это доказывает, что вы имеете доступ к своему устройству и можете его разблокировать. В совокупности это означает, что ключи защищают также от фишинга, повторного использования паролей или утечки данных. По мнению разработчиков, это более надёжная защита, чем большинство современных методов 2SV (2FA/MFA).
Создание ключа доступа делает его вариантом входа в аккаунт Google. Остальные методы, включая пароль, по-прежнему работают при использовании устройств, которые пока не поддерживают ключи.
Ключи доступа остаются новинкой и пройдёт некоторое время, прежде чем они заработают повсеместно. Однако создание ключа уже сейчас даёт преимущества с точки зрения безопасности, считает Google, потому что позволяет более внимательно отнестись к остальным случаям входа в систему, без использования ключей, как потенциально приметам злоумышленника.
Как это работает?
Ключи работают по стандартной схеме асимметричной криптографии. Основным компонентом является закрытый ключ, который хранится на устройстве. При его создании соответствующий открытый ключ загружается в Google. Когда вы входите в систему, она просит устройство подписать уникальный вызов с помощью закрытого ключа. Устройство делает это только с одобрения пользователя, что требует разблокировки устройства. Затем система проверяет подпись с помощью открытого ключа. Вот и всё.
Такая схема гарантирует, что подпись можно передать только конкретной стороне (Google), а не фишинговым посредникам. Поэтому нет риска утечки и никакой фишинговый сайт не нанесёт пользователю вреда. Единственные данные, которые передаются на сервер в этой схеме — открытый ключ и подпись. Ничего из этого не содержит биометрических данных.
Поскольку каждый ключ можно использовать только для одной учётной записи, нет риска его повторного использования в разных службах.
Ключи доступа построены на протоколах и стандартах FIDO Alliance и рабочей группы WebAuthn. То есть это открытые стандарты. Любой веб-разработчик может внедрить такую схему для аутентификации пользователей на своих серверах.
Дополнительно о поддержке ключей на платформах Chrome и Android см. в документации для разработчиков.
Мультимодальная аутентификация
На самом деле, пароли уже стали очень привычны для среднего пользователя за многие годы их использования.
Среди самых распространённых методов аутентификации самым простым и безопасным считается сканирование отпечатка пальца (см. таблицу внизу). В то же время чуть более комфортным и естественным является ввод пароля (вторая строчка в таблице), хотя разница между ними не слишком велика.
Источник: «Мультимодальная аутентификация пользователей в „умных“ средах: Исследование отношения пользователей» (arXiv:2305.03699v2, вторая версия препринта опубликована 23 мая 2023 года)
Интересно, что желание людей применять всё более сложные методы аутентификации возрастает, когда они остаются в одиночестве (или хотя бы в обществе супруга). На публике желание использовать серьёзную аутентификацию уменьшается:
Источник тот же
Будущее без паролей?
В целом человечеству ещё есть куда стремится на пути к улучшению аутентификации, а именно — для достижения баланса между комфортом, надёжностью, приватностью, простотой в использовании и безопасностью. Этот пентабазис изображён на следующей иллюстрации:
Будем надеяться, что Passkeys — шаг в правильном направлении. Но не стоит забывать, что среди всех методов аутентификации наиболее комфортным и естественным для пользователей по-прежнему остаётся ввод пароля (см. результаты исследования выше).
А в случае ключей доступа нужно помнить, что в данном случае утрата контроля над устройством (смартфоном) автоматически означает компрометацию аккаунта Google, потому что парольная защита отсутствует. Google сама признаёт проблему и пишет: «Любой человек, имеющий доступ к устройству и возможность разблокировать его, сможет войти в ваш аккаунт Google. Хотя это может показаться немного тревожным, большинству людей проще контролировать доступ к своим устройствам, чем поддерживать высокий уровень безопасности с помощью паролей и постоянно следить за попытками фишинга».
Возможно, мы действительно наблюдаем начало беспарольного будущего, но это ещё неясно. Некоторые специалисты считают WebAuthn сомнительным стандартом: «Он снимает почти все риски с поставщика услуг и возлагает всю ответственность на пользователя. Поскольку ключи — это просто строки, ничто не мешает нам хранить их где угодно. Мы уже делаем это — хранение ключей SSH или GPG — это то, что мы делаем каждый день. Однако это не относится к массовой публике. Я не могу представить себе бабушку, которая должна следить за тем, чтобы никогда не потерять этот файл, — пишет Михал Сапка, польский разработчик. — Как уже упоминалось выше, Apple и Google пытаются стать хранителями закрытых ключей. Поначалу это звучит замечательно: в аккаунте Google или Apple iCloud ключ будет храниться и синхронизироваться автоматически. Но после некоторых размышлений выясняется, что это не лучшая идея для большинства людей».
Во-первых, это небезопасно. Известно, что корпорации могут без причины заблокировать аккаунты пользователей. Во-вторых, это затрудняет одновременное использование разных экосистем, а тем более — альтернативных ОС и браузеров. То есть передавать свои ключи на хранение внешней стороне— не всегда хорошая идея, считают некоторые специалисты.
В любом случае, в самых защищённых системах отказываться от паролей пока рано.
Как настроить ключи доступа и входить в учетную запись Google и другие сайты на iPhone без пароля
В iOS 16 Apple добавила новую функцию — Apple Passkey. С помощью нее можно авторизовываться на совместимых сайтах и приложениях без пароля, используя специальный ключ, который хранится на вашем Айфоне. Мы уже рассказывали, как она работает, на примере сервиса Kayak. Вот только на тот момент ни одна другая платформа не поддерживала Passkey. Да и зарегистрироваться на Каяке, который не работает в России, было той еще проблемой. Но с недавних пор с ключами доступа стал работать Google, и поэтому теперь вы можете настроить их для своей учетной записи Гугл и пользоваться всеми удобствами такого способа авторизации.
С Passkey входить в учетную запись можно в одно касание
❗️ПОДПИШИСЬ НА НАШ ДЗЕН. ТАМ КАЖДЫЙ ДЕНЬ ВЫХОДЯТ КРУТЫЕ СТАТЬИ
Мы протестировали, как работают ключи доступа для входа в аккаунт Google, и теперь рассказываем вам, как настроить Passkey для Google Аккаунта и входить в него без ввода пароля не только с iPhone, но и любого другого устройства.
Как создать ключ доступа
Когда я впервые пробовал Apple Passkey, то из-за того, что поддерживались они только на iPhone, полноценно ими воспользоваться было невозможно. Создал ключ доступа на Айфоне и можешь использовать его только на этом же Айфоне или Айпаде с Макбуком. На сегодняшний день Passkey интегрирован в следующие приложения и операционные системы и их более свежие версии:
Google:
- Chrome 109;
- Android 9;
- ChromeOS 109.
Apple:
- iOS 16;
- iPadOS 16; ;
- Safari 16.
Microsoft:
- EDGE 109;
- Windows 10 или 11.
❗️ПОДПИШИСЬ НА НАШ ТЕЛЕГРАМ-ЧАТ И ЗАДАВАЙ ВОПРОСЫ НАШИМ АВТОРАМ, НА КОТОРЫЕ ОНИ ОБЯЗАТЕЛЬНО ОТВЕТЯТ
Во всех этих системах и браузерах вы можете для любого сайта и приложения создать ключ доступа, и вам не понадобится Айфон для авторизации. Теперь давайте активируем ключи доступа для учетной записи Google:
-
Через Safari перейдите на сайт Google и авторизуйтесь под своей учетной записью;
Обязательно активируйте ключи доступа
Добавьте свой ключ для Айфона
Теперь, если вы зайдете в раздел “Пароли” в настройках и найдете там свою учетную запись Гугл, то сможете увидеть, что помимо пароля там появился еще и ключ входа.
Как войти в аккаунт Гугл на Айфоне
Войти в учетную запись Гугл на Айфоне теперь еще проще, чем раньше. При использовании пароля вам обязательно надо было подтвердить вход с любого другого вашего устройства или кодом из СМС-сообщения. А вот при авторизации с помощью Passkey никаких лишних телодвижений вам не потребуется. Смотрите сами:
-
и нажмите кнопку “Вход” в правом верхнем углу;
Достаточно будет только помнить свой email
Подтвердите биометрией и вы в учетной записи
На этом авторизация завершена. Вы даже не получите на почту уведомление, что совершен вход с нового устройства. Гугл уже точно будет знать, что это ваш Айфон, и безопасности ничто не угрожает. А самое главное, что не нужна никакая двухфакторная аутентификация. Сказать, что это удобно — ничего не сказать.
Как войти в Гугл без пароля
Наверняка вас теперь интересует, а как при наличии ключа доступа входить в вашу учетную запись с других устройств. Например, с компьютера. Если у вас Мак, на котором используется ваш Apple ID и установлена macOS Ventura, то ключ доступа окажется на компьютере через связку ключей, и вы легко сможете им воспользоваться и там. А вот если в паре с Айфоном вы пользуетесь Windows, то придется провернуть очень хитрый трюк:
-
в браузере Chrome;
Введите адрес электронной почты
Согласитесь со входом с помощью ключа доступа
Выберите “Использовать другой смартфон или планшет” для генерации QR-кода
Отсканируйте QR-код камерой Айфона
В камере сразу появится кнопка “Вход с ключом доступа”
Все! Никаких паролей, кодов подтверждения и прочей ерунды. Есть только доверенные устройства, с помощью которых можно подтвердить вход. Все работает очень быстро и без каких-либо задержек.
Вход на сайты без пароля
О поддержке ключей доступа заявляет большое количество сайтов и сервисов. Более-менее спокойно у меня получилось воспользоваться ими только на сайте Kayak. Но если вы решите зарегистрироваться на нем из России, обязательно используйте VPN, иначе у вас ничего не получится. О поддержке Passkey заявляют:
- PayPal;
- BestBuy;
- 1Password;
- Ebay;
- CardPointer;
- WordPress.
Сбер тоже поддерживает Passkey
К сожалению, большинство из них неактуальны для жителей России. А вот вход без пароля в Сбербанк Онлайн вам точно пригодится. Наш автор Иван Кузнецов рассказывал, как это работает, в отдельном материале, обязательно прочитайте.
Самое интересное, что Apple до сих пор не реализовала поддержку Passkey в своих сервисах. Если вы попытаетесь войти в iCloud или учетную запись Apple ID через Сафари с Айфона, то при выборе вашего аккаунта просто придется подтвердить вход с помощью биометрии и все. При этом если вы решите войти в учетку через любое другое устройство, то придется ввести пароль и подтвердить вход с помощью кода-подтверждения. Хочется верить, что Apple подключит Passkey к своим сервисам. Надо же показывать пример остальным. Ну а пока пионером выступает Google.