Пользователь сменил пароль, но его старые сессии остаются активными. Какой механизм должен немедленно прекратить действие этих сессий?
Нужно централизованно отозвать все сессии пользователя при смене пароля. Практичный механизм — увеличить версию аутентификации пользователя или пометить его сессии отозванными, после чего проверять это состояние при каждом запросе либо при обновлении токена.
Одного изменения пароля недостаточно: уже выданная сессия обычно не проверяет пароль повторно. Если злоумышленник украл cookie или токен, он сохранит доступ до истечения срока действия либо до явной проверки отзыва.
Серверные сессии и bearer-токены создавались для того, чтобы не передавать пароль при каждом запросе. После успешной аутентификации клиент предъявляет ранее выданный идентификатор, а сервер считает его достаточным доказательством продолжения сессии.
Такая модель удобна, но создаёт проблему отзыва: предъявляемый токен не сообщает, изменился ли пароль или был ли аккаунт скомпрометирован. Поэтому архитектуры безопасности дополняют срок жизни токена централизованным состоянием отзыва или версией аутентификации.
После смены пароля старые сессии могут оставаться действительными в браузерах, мобильных приложениях и сторонних устройствах. Если прежний пароль был скомпрометирован или сессия украдена, злоумышленник продолжит выполнять операции от имени пользователя.
Особенно опасна реализация, в которой сервер проверяет только подпись токена или наличие записи о сессии. Криптографически корректный токен может быть легитимно выдан до смены пароля, но после этого он должен считаться недействительным.
У пользователя хранится версия аутентификации. При входе её значение записывается в сессию или помещается в выданный токен. При смене пароля версия увеличивается. На защищённой операции сервер сравнивает версию из сессии с текущей версией пользователя: несовпадение означает отзыв сессии.
Другой вариант — хранить список или статус отзыва сессий и удалять либо блокировать все сессии пользователя. Он позволяет отзывать отдельные устройства, но требует управления записями и очистки устаревших данных. Версия обычно проще и дешевле, если нужно отозвать все сессии сразу.
Для серверных сессий проверку можно выполнять на каждом запросе или при обращении к хранилищу сессии. Для статeless-токенов немедленный отзыв невозможен без дополнительного серверного состояния: применяют короткий срок жизни access-токенов, отзыв refresh-токенов и проверку версии при их обновлении.
Изменение пароля, сброс пароля, подтверждённый захват аккаунта и иногда включение или сброс многофакторной аутентификации должны использовать согласованную политику отзыва. Операцию смены пароля и увеличение версии следует выполнять атомарно, чтобы параллельный запрос не успел получить новое право на основе старого состояния.
Нельзя полагаться только на очистку cookie в текущем браузере: она не отзывает сессии на других устройствах. Также не следует считать достаточным лишь сокращение времени жизни токена: это уменьшает окно атаки, но не обеспечивает немедленного прекращения доступа.
В интернет-банке пользователь сменил пароль после подозрительного входа. Рассматривались три варианта: ничего не отзывать до естественного истечения токенов, добавить все токены в denylist или увеличить версию аутентификации пользователя.
Первый вариант прост, но оставляет украденные сессии активными. Denylist обеспечивает точный отзыв, однако требует хранения, синхронизации и удаления большого количества идентификаторов. Выбранная схема использует версию аутентификации для массового отзыва, а для refresh-токенов дополнительно хранит состояние их ротации и позволяет отзывать конкретное устройство.
После смены пароля текущая операция завершается, версия увеличивается, а все старые сессии перестают проходить проверку. Пользователь может заново войти на доверенных устройствах, не оставляя действующих сессий у злоумышленника.
Нет. При таком подходе уже активная сессия не заметит смену пароля. Проверка нужна на каждом запросе, при обращении к централизованному хранилищу сессий или как минимум при обновлении долгоживущего токена — выбор зависит от требуемой скорости отзыва и допустимой нагрузки.
Нет, если токен уже выдан и криптографически действителен. Без обращения к текущему состоянию сервер не узнает, что пароль был изменён. Компромисс состоит в коротком сроке жизни access-токена, использовании отзывных refresh-токенов или добавлении проверки версии либо denylist.
Если пароль обновляется отдельно от версии, между этими действиями возможна гонка. Параллельный запрос может пройти по старой версии в момент, когда пароль уже изменён, либо получить неконсистентное состояние. Атомарное обновление в одной транзакции или эквивалентный механизм согласованности устраняет это окно.