Викрадений токен може відкрити пошту без пароля: NIST оновив правила захисту входу

Коли браузер або застосунок запам’ятовує вхід, пароль може більше не запитуватися — доступ підтверджує токен. Якщо зловмисник викраде або підробить такий цифровий «пропуск», одного сильного пароля вже недостатньо. NIST і CISA завершили рекомендації NIST IR 8587 про захист токенів та інших тверджень ідентичності від крадіжки, підроблення й неправильного використання.

Що таке токен і чому він цінний для нападника

Після успішного входу сервіс часто видає короткий набір криптографічно захищених даних. Він підтверджує, хто ви та до яких ресурсів маєте доступ. Завдяки цьому працюють вебсесії та єдиний вхід: користувач не вводить пароль заново для пошти, календаря й хмарного диска. Токени також застосовують сервери, застосунки й автоматизовані агенти.

Проблема в тому, що дійсний токен іноді дозволяє оминути повторну автентифікацію. Якщо його витягнули зі шкідливого розширення, журналу, незахищеного сховища або через помилку хмарної конфігурації, нападник може видати себе за законного користувача. NIST нагадує про інцидент, у якому підроблені токени, створені на основі викраденого ключа підпису, дали змогу отримати доступ до поштових систем і викрасти понад 60 тисяч листів однієї установи.

Що змінилося у фінальній версії

Початковий проєкт рекомендацій опублікували в грудні 2025 року. Після відгуків NIST зробив поради щодо криптографічних ключів менш прив’язаними до одного способу реалізації й більше зосередився на результаті: організація повинна знати, де ключі зберігаються, хто ними користується, як фіксуються операції та як швидко ключ можна замінити після підозри на витік.

До документа додали високорівневі міркування про AI-агентів і майбутній перехід до постквантової криптографії. Це не готовий набір налаштувань для будь-якого чатбота й не повний посібник із PQC. Рекомендації лише звертають увагу, що машинні облікові записи теж отримують токени, а довгоживучі ключі та підписи потрібно планувати з урахуванням нових алгоритмів.

Що мають зробити сервіси

• Зменшувати строк життя й повноваження токенів. Один пропуск не повинен відкривати більше ресурсів і працювати довше, ніж необхідно.
• Захищати ключі підпису окремо. Компрометація одного центрального ключа може перетворитися на масове підроблення сесій.
• Уміти відкликати доступ. Вихід, звільнення працівника або сигнал про крадіжку мають швидко анулювати пов’язані токени.
• Обмінюватися сигналами ризику. Постачальник і клієнт хмари повинні узгодити, хто помічає аномалію та хто блокує сесію.
• Не записувати секрети в журнали. Діагностичні логи, URL і повідомлення про помилки часто стають непомітним джерелом витоку.

Рекомендації розраховані передусім на федеральні установи США та їхніх хмарних постачальників, але принципи застосовні й до комерційних компаній. NIST розділяє відповідальність: провайдер має дати безпечні механізми, а клієнт — правильно їх налаштувати. Купівля «захищеної хмари» сама по собі не вирішує проблему, якщо токени надто довгі, права надмірні, а відкликання не працює.

Що може зробити звичайний користувач

Людина не керує серверними ключами, але може скоротити власний ризик. Варто регулярно оновлювати браузер і застосунки, видаляти непотрібні розширення, не встановлювати програми з випадкових архівів та завершувати активні сесії на загублених пристроях. У налаштуваннях великих сервісів корисно переглянути список пристроїв і підключених застосунків, відкликати невідомі входи та ввімкнути стійку багатофакторну автентифікацію.

Зміна пароля після зараження не завжди миттєво вбиває вже викрадений токен. Тому після підозрілого входу потрібно використати функцію «вийти з усіх пристроїв», відкликати сесії й перевірити правила переадресації пошти та сторонні інтеграції. Якщо такої можливості немає, слід звернутися до служби підтримки.

Фінальний документ NIST не створює обов’язкового стандарту для кожного сайту й не гарантує захист від усіх атак. Його цінність у системному погляді: пароль, MFA, токен, ключ підпису, журналювання та відкликання мають працювати як один ланцюг. Безпека входу закінчується не в момент правильно введеного коду, а лише тоді, коли весь життєвий цикл сесії контролюється.

Матеріал перекладено й адаптовано за повідомленням NIST про NIST IR 8587. Текст NIST є публічною інформацією уряду США; сторонню Shutterstock-ілюстрацію з оригіналу не використано. Обкладинка з Wikimedia Commons має ліцензію CC0.