Аутентификация — это проверка того, что пользователь действительно тот, за кого себя выдает: система сверяет предъявленные им данные (пароль, код из смс, отпечаток пальца) с эталоном, который хранится на сервере. В статье разберем факторы и виды аутентификации, ее отличие от авторизации и идентификации, а также как эти три процесса выстраиваются вместе на примере входа в личный кабинет.
Содержание
Три близких понятия: идентификация, аутентификация, авторизация
Эти слова часто путают, потому что на практике они идут подряд за доли секунды. У каждого своя задача:
- Идентификация — пользователь заявляет, кто он: вводит логин, email или номер телефона. Система только ищет такую запись в базе, ничего не проверяет.
- Аутентификация — пользователь доказывает, что заявление верно: вводит пароль, код или прикладывает палец к сканеру.
- Авторизация — система определяет, что подтвержденному пользователю можно делать: какие разделы открыты, какие действия разрешены.
Границу между аутентификацией и авторизацией удобнее всего свести в таблицу.
| Признак | Аутентификация | Авторизация |
|---|---|---|
| Отвечает на вопрос | Это точно ты? | Что тебе можно? |
| Что проверяет | Подлинность личности | Права доступа |
| Когда происходит | При входе, до допуска в систему | После того как личность подтверждена |
| Типичный отказ | Неверный пароль, доступ не открыт вовсе | Пароль верный, но конкретное действие запрещено |
| Пример | Ввод пароля от личного кабинета | Обычному пользователю нельзя удалить чужой комментарий, администратору — можно |
Показательный пограничный случай: авторизация может состояться и без явной аутентификации. Если открыть документ Google по публичной ссылке «доступно всем, у кого есть ссылка», сервис выдает право на чтение без входа в аккаунт — идентификации и аутентификации в этот момент просто не было.
Факторы аутентификации
Любой способ подтвердить личность относится к одной из трех категорий:
- Знание — то, что пользователь помнит: пароль, PIN-код, ответ на секретный вопрос.
- Владение — то, что у пользователя есть физически: телефон для смс-кода, аппаратный токен, смарт-карта, приложение-аутентификатор.
- Биометрия — то, чем пользователь является: отпечаток пальца, геометрия лица, рисунок радужки.
Иногда отдельно упоминают проверку по геолокации или по поведению (скорость набора текста, типичное время входа). Это не полноценный четвертый фактор в классическом понимании, а вспомогательный риск-сигнал: сервис использует его, чтобы решить, запросить ли у пользователя дополнительное подтверждение, а не как самостоятельное доказательство личности.
Однофакторная и многофакторная аутентификация
При однофакторной аутентификации используется один элемент — чаще всего пароль. Это самый простой вариант для пользователя, но и самый уязвимый: пароли переиспользуют между сервисами, их подбирают перебором и получают через фишинг. Утечка базы одного сайта нередко открывает доступ и к другим аккаунтам того же человека.
Многофакторная аутентификация (MFA) требует минимум два элемента из РАЗНЫХ категорий — например, пароль (знание) плюс код из приложения-аутентификатора (владение). Две проверки из одной категории, скажем два разных пароля, факторность не увеличивают.
Частые связки MFA:
- пароль + одноразовый код из смс или почты;
- пароль + код из приложения-аутентификатора (TOTP);
- пароль + push-подтверждение в мобильном приложении;
- пароль + биометрия на устройстве.
MFA заметно снижает риск при утечке одного пароля, но не дает стопроцентной гарантии. Смс-код можно перехватить через подмену сим-карты (SIM-swap), а пользователя можно обмануть фишинговой страницей, которая в реальном времени ретранслирует и пароль, и одноразовый код. Устойчивее к фишингу аппаратные ключи и passkeys, которые проверяют подлинность именно сайта, а не только вводимый пользователем код.
Как это выглядит на практике: вход в личный кабинет
Пример на otus.ru или любом другом сервисе с личным кабинетом:
- Пользователь открывает форму входа и вводит email — это идентификация: система ищет такую учетную запись.
- Пользователь вводит пароль, а затем код из смс — это аутентификация: система проверяет, что оба элемента совпадают с сохраненными данными.
- После успешной проверки система решает, что доступно этому пользователю: обычный студент увидит свои курсы, а модератор — еще и панель управления. Это авторизация.
Первые два этапа неразрывны: без идентификации нечего аутентифицировать. Авторизация же может опираться на разные условия — роль пользователя, подписку, регион — и настраивается отдельно от процесса входа.
Как хранятся пароли: основы безопасности
Хорошо спроектированный сервис никогда не хранит пароль в открытом виде — только результат хеширования. Для новых систем актуальная по стандарту OWASP рекомендация — Argon2id: алгоритм с настраиваемой стоимостью по памяти и времени, что затрудняет перебор на специализированном оборудовании. Для legacy-систем часто остается bcrypt: он проще внедрить в старый стек, но у него есть ограничение — входная строка учитывается не длиннее 72 байт, «хвост» более длинного пароля молча игнорируется. Предварительное сокращение хешем (например, SHA-256) снимает проблему только при условии, что сырые байты хеша дополнительно кодируют в base64 или hex перед передачей в bcrypt: в необработанном бинарном дайджесте может встретиться нулевой байт, и часть реализаций bcrypt снова обрежет строку по этому байту — то есть повторит тот же дефект, от которого пытались уйти.
Быстрые хеши общего назначения (MD5, SHA-1, обычный SHA-256 без специальной настройки) для паролей не годятся. Главная причина — не коллизии, а скорость: они спроектированы вычисляться быстро, и именно это позволяет атакующему перебирать миллиарды вариантов в секунду на видеокарте после утечки базы.
Важно не путать, от какой именно угрозы что защищает:
- Медленное хеширование (Argon2id/bcrypt) защищает от офлайн-перебора — когда база с хешами уже украдена и атакующий подбирает пароли без ограничений на своем оборудовании.
- От онлайн-подбора — когда атакующий пытается угадать пароль прямо через форму входа на сайте — хеширование не спасает вовсе. Здесь нужны отдельные меры: ограничение числа попыток, временная блокировка аккаунта после серии неудач, мониторинг подозрительных входов и, как самая надежная мера, MFA.
Выводы
- Идентификация отвечает «кто ты», аутентификация — «докажи это», авторизация — «что тебе можно».
- Есть три категории факторов аутентификации: знание, владение, биометрия; геолокация и поведение — вспомогательные сигналы, а не полноценный фактор.
- Однофакторная аутентификация уязвима к утечкам и переиспользованию паролей; MFA требует факторы из разных категорий и снижает риск, но не исключает его полностью.
- Пароли хранят только в виде хеша (Argon2id для новых систем, bcrypt — для совместимости со старым стеком с учетом лимита в 72 байта).
- Хеширование защищает от офлайн-перебора украденной базы, а от онлайн-подбора при входе защищают ограничение попыток, блокировки и MFA.
Где применяется / связь с практикой
Освойте тему на практике
Разграничение аутентификации и авторизации — база для любой разработки, где есть личные кабинеты, роли пользователей и защита данных: веб- и мобильные приложения, корпоративные системы, API. Если тема безопасности входа и защиты данных интересна не только как теория, посмотрите курс по информационной безопасности — там разбирают проектирование аутентификации, хранение секретов и защиту от типовых атак на практике. Ближайшие открытые уроки Otus можно посмотреть бесплатно, чтобы оценить формат перед стартом курса.
FAQ
Может ли авторизация происходить без аутентификации?
Да, если ресурс публичный. Например, документ с доступом «по ссылке для всех» открывается на чтение без входа в аккаунт — авторизация выдана заранее, а этап аутентификации конкретного человека просто не требуется.
Чем аутентификация отличается от верификации?
Верификация обычно означает разовое подтверждение конкретного атрибута — например, email или номера телефона при регистрации, через переход по ссылке или ввод кода. Аутентификация — многократная процедура подтверждения личности при каждом входе в систему, а не разовая проверка одного контактного данного.
Правда ли, что многофакторная аутентификация полностью исключает взлом аккаунта?
Нет. MFA существенно повышает стоимость атаки, но смс-код можно перехватить через подмену сим-карты, а фишинговая страница в реальном времени может ретранслировать и пароль, и одноразовый код на настоящий сайт. Полной гарантии не дает ни один отдельный механизм — нужна связка мер защиты.
