Окремо розглядайте вхід до облікового запису, дозвіл на доступ до даних і відновлення ключів чату: одна кнопка входу не відповідає на всі три питання.
«Вхід через Google» не означає автоматично, що Google має доступ до тексту чатів, але й не є варіантом без додаткових вимог до довіри. Цей спосіб залучає постачальника ідентифікації до процесу входу; передані відомості та залежність облікового запису слід оцінювати за дозволами й реальною архітектурою сервісу.
Ухвалюючи рішення, відокремлюйте вхід до облікового запису від дозволу на доступ до даних Google і від ключів шифрування розмов. Одна кнопка входу не відповідає на всі три питання.
Чим відрізняються OAuth і OpenID Connect?
OAuth — це механізм надання доступу до ресурсів. OpenID Connect додає до нього рівень автентифікації. Документація Google щодо входу описує процес на основі OpenID Connect для ідентифікації користувача.
Тому фраза «OAuth передає пароль Google месенджеру» неправильна. Сервіс має належно перевіряти відповідний токен і захищати власний сеанс. Дозвіл на Gmail, Drive або інші дані — також окреме питання, не тотожне простому входу. Пояснення дозволів та областей доступу.
Яка інформація може передаватися?
Процес входу зазвичай передає сервісу ідентифікатор і, залежно від дозволів, відомості на кшталт електронної адреси або даних профілю. Постачальник ідентифікації також бере участь у запитах, пов’язаних з автентифікацією. Але з назви способу входу не можна зробити висновок, що йому надсилаються відомості про кожне відкриття застосунку, кожне повідомлення або вся історія використання.
| Запитання | Що слід перевірити |
|---|---|
| Які дані облікового запису отримує месенджер? | Екран згоди, області доступу та політику приватності |
| Чи запитано дозвіл на додаткові дані? | Відмінність між входом і доступом до пошти, файлів або контактів |
| Коли постачальник ідентифікації залучається знову? | Політику сеансів і оновлення токенів у реалізації |
| Чи залежать ключі чату від цього входу? | Документацію зі зберігання та відновлення ключів, а не лише кнопку входу |
Не надавайте дозволу, який неможливо обґрунтувати вашими потребами. Водночас не тлумачте конкретний запит дозволу як «читання всіх повідомлень» без перевірки.
Чим ризикована залежність від центрального облікового запису?
Якщо єдиний спосіб увійти до месенджера пов’язаний з обліковим записом, що стає недоступним, нові входи можуть порушитися. Вплив на наявні сеанси, локальні дані та відновлення залежить від архітектури сервісу. Тож висновок «блокування Google обов’язково знищує всі чати» неправильний.
До виникнення термінової потреби перевірте, чи має сервіс альтернативний спосіб входу або процедуру відновлення та як їх додавання впливає на безпеку облікового запису. Альтернатива не має перетворюватися на простіший шлях для зловмисника. Не змінюйте й не видаляйте прив’язку облікового запису, не переконавшись у можливості наступного входу.
Чи усуває прямий вхід через SRP усі ці ризики?
Прямий вхід може зменшити залежність від стороннього постачальника ідентифікації. За правильної реалізації SRP також доводить знання пароля, не надсилаючи сам пароль у повідомленнях протоколу. Проте месенджер і далі обробляє ім’я облікового запису, подію входу та пов’язані операційні відомості; вислів «без цифрового сліду» неточний.
Крім того, збережене перевірочне значення SRP потрібно захищати. RFC 5054 описує ризик підбору пароля після розкриття verifier. Безпека сторінки входу, сеансу, відновлення та пристрою залишається необхідною.
Жоден технічний принцип не стверджує, що SRP — єдиний приватний спосіб входу або що будь-який федеративний вхід небезпечний за своєю природою. Визначальними мають бути якість реалізації та модель загроз.
Межі тверджень Livara
Сторінка безпеки Livara описує SRP для автентифікації й прямо повідомляє про зберігання певних операційних даних. Це не означає, що ідентичність облікового запису прихована від самого сервісу. Та сама сторінка відокремлює відновлення криптографічної ідентичності від історії чатів.
Для практичного порівняння вимагайте від кожного сервісу відповідей на ті самі запитання: які дані він отримує, яка третя сторона залучена, як він завершує сеанс і як відновлюються ключі чату? Задокументована відповідь корисніша за гасло «нульове знання».
Перед вибором способу входу
Захистіть основний обліковий запис і шляхи відновлення, прочитайте запитані дозволи, перегляньте підключені пристрої та ознайомтеся з планом втрати доступу до облікового запису. Потім оберіть спосіб входу, що відповідає вашим потребам і можливостям керування; зручність і незалежність цінні, але жодна з них сама по собі не гарантує безпеки.
