Аутентификация, авторизация и MFA

В этой статье разбираем основы контроля доступа, чётко разделим аутентификацию и авторизацию. Разберём многофакторную аутентификацию (MFA), подробно рассмотрим TOTP как второй фактор и сравним другие методы MFA.
Tags:

Введение

Любая информационная система, будь то домашний NAS, корпоративный Active Directory или облачная инфраструктура, ежедневно отвечает на два простых вопроса: «Кто вы?» и «Что вам разрешено делать?». За этими вопросами стоит - контроль доступа.

Можно выделить 3 слоя в безопасности систем:

  • Разграничение сети - подсети, VLAN и файрволлы создают периметры безопасности.
  • Шифрование - позволяет защитить данные от кражи.
  • Контроль доступа - это механизмы аутентификации, авторизации и аудита действий пользователей.

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

Аутентификация и авторизация

Эти термины часто путают или используют как синонимы, но в реальности это принципиально разные механизмы. Путаница между ними часто приводит к ошибкам в настройке, диагностике и реагировании на инциденты.

Аутентификация (Authentication) – это проверка идентичности. Система отвечает на вопрос: «Тот ли это субъект (пользователь, сервис, устройство), за кого он себя выдаёт?»

  • Результат: подтверждённый идентификатор.
  • Примеры: проверка пароля, SSH-ключа, смарт-карты, TOTP-кода, отпечатка пальца.

Авторизация (Authorization) – это проверка прав. Система уже знает, кто вы, и решает: «Разрешено ли этому субъекту выполнять конкретное действие?»

  • Результат: доступ разрешён или отклонён.
  • Примеры: проверка прав на чтение файла, разрешение на запуск sudo, доступ к API-эндпоинту, применение групповых политик AD.

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

  • В логах аутентификации ищут: authentication failure, invalid credentials, password expired.
  • В логах авторизации: permission denied, access denied, unauthorized.

Если инженер путает аутентификацию и авторизацию, он может часами сбрасывать пароли или пересоздавать токены, хотя проблема может быть в ACL на каталоге, отсутствии пользователя в нужной группе или неправильно настроенном AllowGroups в sshd_config.

При расследовании взлома критично понимать вектор:

  • Скомпрометированы учётные данные? → Проблема на уровне аутентификации. Необходимо: поменять пароли, заблокировать учётки, сбросить сессии.
  • Злоумышленник злоупотребил легитимными правами? → Проблема на уровне авторизации. Например: пользователь ввёл верный пароль, вошёл в систему, но через время запустил странный скрипт и начал сканировать порты на соседних серверах. Необходимо: пересмотреть политику доступа, удалить избыточные роли, включить принцип наименьших привилегий.

Пароли и требования к ним

Пароли - это один из самых распространенных способов аутентификации пользователей. Однако неправильное хранение и использование паролей может привести к утечкам данных и компрометации учетных записей.

Для систем аутентификации пароли почти всегда должны храниться именно в виде хеша, а не шифрования.

  • Linux — хранит хеши паролей в файле /etc/shadow.
  • Windows — хранит хеши паролей в системной базе SAM (Security Account Manager).
  • Обе системы используют дополнительные механизмы защиты: в Linux это соль и многократное хеширование (замедление перебора), а в Windows — шифрование самой базы SAM ключами, привязанными к конкретной установке ОС, и изоляция процессов.
  • В популярных CMS (WordPress, Joomla, 1C-Битрикс) пароли также хранятся в хешированном виде, обычно в базе данных. Стойкость зависит от версии продукта и настроек системы.

Для хранения множества паролей используются менеджеры паролей (например, KeePassXC). В отличие от систем входа, здесь данные зашифрованы а не хешированы. Так как пароли нужно расшифровывать для использования. Ключ шифрования (мастер-пароль) известен только пользователю и не передается на серверы. А хранение паролей в обычных текстовых файлах категорически недопустимо.

Чтобы снизить риск взлома, пароли должны соответствовать определенным требованиям. Актуальные рекомендации:

  • Длина важнее сложности. Длинный пароль (12-15 символов) надежнее чем короткий сложный пароль (с символами разных регистров, цифрами и спец. символами). Стойкость пароля резко возрастает с увеличением длины.
  • Отмена обязательной ротации. Раньше была рекомендация менять пароль периодически. Но сейчас рекомендуется менять пароль только при подозрении на компрометацию. Так как периодическая смена паролей ведёт к слабым паттернам и перегрузке сотрудников.
  • Запрет на личную информацию и повторяющиеся последовательности. Например пароли: qwerty, 123456, имя питомца или дата рождения легко угадываются и находятся в словарях атакующих.

Пароли можно проверять по утечкам. Для этого есть специальные базы или сервисы. Если пароль уже «светился» в сети, его использование опасно, даже если он кажется сложным. Лучше не отправлять реальные пароли в открытые онлайн-сервисы для проверки, хоть они и могут быть безопасными. Вот пример на Linux, как можно скачать базу с паролями и проверять пароль локально:

# 10 миллионов
wget https://raw.githubusercontent.com/danielmiessler/SecLists/refs/heads/master/Passwords/Common-Credentials/Pwdb_top-10000000.txt
grep -Fx 12345 Pwdb_top-10000000.txt

# около 64 миллионов
wget https://crackstation.net/files/crackstation-human-only.txt.gz
gunzip crackstation-human-only.txt.gz
grep -Fx 12345 crackstation-human-only.txt

Но есть и специализированные базы и утилиты к ним, которые работают быстрее чем grep.

Кроме этого, для защиты сервисов применяют и другие методы защиты аутентификации:

  • Ограничение количества попыток ввода пароля. Например: fail2ban или CrowdSec в Linux, политики блокировки AD в Windows.
  • Использование CAPTCHA, в основном на web-сервисах.
  • Обучение пользователей распознавать фишинг (письма и сайты).
  • Использование менеджеров паролей (Bitwarden, Vaultwarden, KeePassXC).
  • Многофакторная аутентификация (MFA).

TOTP Аутентификация

Если для первого фактора аутентификации чаще всего используется пароль, то для второго фактора используются различные технологии и алгоритмы. Я бы хотел остановиться подробнее на TOTP аутентификации.

TOTP (Time-based One-Time Password) – один из популярных и современных методов аутентификации. Он довольно популярный и может использоваться бесплатно на селф-хостинг решениях. Он работает офлайн и значительно снижает риски, связанные с утечкой или подбором паролей.

TOTP основан на стандарте RFC 6238 и является развитием алгоритма HOTP. Вместо счётчика попыток здесь используется текущее время.

  • Сервер генерирует секретный ключ (обычно 16–32 символа в base32) и привязывает его к учётной записи.
  • Ключ передаётся пользователю в виде QR-кода или текстовой строки.
  • Приложение-аутентификатор на смартфоне использует этот ключ и текущее время, вычисляя специальный 6-значный код.
  • Каждые 30 секунд (стандартный шаг) время сдвигается, и код обновляется.
  • При входе пользователь вводит 6-значный код. Сервер выполняет тот же расчёт на своей стороне. Если коды совпадают (с учётом допустимого дрейфа времени) – аутентификация считается успешной.

🔑 Важно: Смартфону не нужен интернет для генерации кодов. Но на устройстве и на сервере должно быть корректное (одинаковое) время. Без синхронизации часы начнут «расходиться», и коды перестанут совпадать.

Типичный процесс настройки:

  • Включаем TOTP в сервисе.
  • Система генерирует секрет и показывает QR-код.
  • Пользователь сканирует QR в приложении-аутентификаторе.
  • Вводит первый сгенерированный код для верификации привязки.
  • Сервер сохраняет привязку, выдаёт резервные коды восстановления.
  • При следующем входе система запрашивает пароль + TOTP-код.

Важно помнить про:

  • Синхронизацию времени.
  • Хранении резервных кодов. При утере телефона, они понадобятся.
  • Безопасное хранение секрета. При утечке злоумышленник может клонировать TOTP.

📱 Приложения-аутентификаторы

  • Android: TOTP Authenticator, 2FA Authenticator, Google Authenticator
  • Кроссплатформенные: Bitwarden, 1Password, KeePassXC

Кстати Google Authenticator и некоторые коммерческие менеджеры синхронизируют секреты в облаке для удобства восстановления. Это снижает риск потери доступа, но создаёт новую точку атаки.

TOTP не защищает от фишинга в реальном времени. Если пользователь введёт код на поддельном сайте, атакующий может мгновенно передать его на настоящий ресурс и пройти аутентификацию.

Альтернативные MFA

TOTP — не единственный способ добавить второй фактор.

В качестве второго фактора можно использовать SMS-код или Email-код. И хоть это до сих пор широко встречается, но современные стандарты безопасности (NIST, OWASP, FIDO Alliance) классифицируют их как устаревшие методы.

  • Злоумышленник может убедить оператора выдать новую SIM на ваш номер.
  • Вирус на телефоне может читать ваши SMS.
  • Злоумышленник может получить доступ к вашему email.

Кроме этого можно использовать Push-уведомления. Приложение получает push с запросом подтверждения входа. Пользователь нажимает “Approve / Это действительно я” или вводит числовой код для верификации. Числовой код считается более безопасным, так как защищает от атак Push bombing.

Эта атака происходит следующим образом. Атакующий уже знает ваш пароль, заходит на сервис, вам отправляется push: Новый вход. Одобрить? [Yes/No]. Атакующий отправляет десятки push-уведомлений, надеясь, что пользователь нажмёт Yes. Именно так была скомпрометирована Uber в 2022 году .

Push-уведомления требуют интернет на телефоне и зависит от конкретного вендора (Microsoft, Google, Yandex).

Также, в качестве второго фактора можно использовать Аппаратный ключ, который криптографически подписывает запрос входа, привязывая его к домену сайта. Аппаратный ключ использует стандарт FIDO2 / WebAuthn.

Плюсы:

  • Привязка к домену: Ключ “знает”, на каком сайте вы авторизуетесь. Если вы пытаетесь войти на фишинговый сайт, то ключ откажется подписывать запрос.
  • Физическое присутствие: Чтобы подтвердить вход, нужно физически владеть ключом. Никакие push-уведомления удаленно нажать не заставят.

Кстати, при использовании аппаратного ключа, в качестве первого фактора часто используется биометрия (отпечаток пальца) вместо пароля.

Но у аппаратного ключа есть и минусы:

  • Его необходимо приобрести, а это стоит денег.
  • Риск потери ключа (нужно минимум 2 ключа: основной + резервный).
  • Не все системы поддерживают (но поддержка растёт: Google, Microsoft, GitHub, Cloudflare).

Ещё один метод аутентификации - Passkeys (бесключевая аутентификация). Использует те же принципы что и аппаратный ключ, но криптографические ключи хранятся в облачном хранилище (iCloud Keychain, Google Password Manager, Windows Hello) и синхронизируются между устройствами пользователя.

То есть вам уже не нужно покупать отдельные ключи. В случае утери восстановление происходит через облако (не потеряешь). Зато фишинг-устойчивость совсем как у аппаратного ключа. В качестве первого фактора здесь также обычно используется биометрия (FaceID/TouchID)

Но есть и свои минусы:

  • Зависимость от экосистемы (Apple/Google/Microsoft).
  • Теоретическая возможность компрометации облачного аккаунта.
  • Пока не все сервисы поддерживают, но поддержка растёт.

Ключевой момент при использовании Passkeys - биометрия не передаётся на сервер в облако. На сервер уходит только криптографическая подпись. Даже если сервер скомпрометирован, злоумышленник не получит ни ваш отпечаток, ни приватный ключ. Он получит только ваш публичный ключ.

Если понравилась статья, подпишись на мой канал в   VK   или   Telegram  .