Вчера обещал рассказать, как устроена современная авторизация. Но сначала — история.

В древние времена в США можно было попасть на сервер, который тогда называли мейнфреймом, просто зная его IP и список доверенных пользователей. Примеры протоколов — Rlogin. Классический случай взлома — атака Кевина Митника на Цутому Симомору.

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

Так появилось хеширование. Хеш-функция работает только в одном направлении.
Например, у операции умножения есть обратное действие — деление, а вот хеширование идёт строго односторонне. Зная результат хеширования, невозможно легко определить изначальные данные (хотя подбор возможен). Простая аналогия — расчёт контрольной суммы:

Имеем ряд значений:
3,0,4,7,5,9,2,8,3,9,1,1,9,7,3,8,0,6,6,2,4,9,5

Сложив цифры:
3+0+4+7+5+9+2+8+3+9+1+1+9+7+3+8+0+6+6+2+4+9+5=111

Берём последнюю цифру: 1. Это наша контрольная сумма. Измените хотя бы один знак в ряду — изменится итоговая сумма. Обратное восстановление набора цифр по контрольному значению невозможно. Например, последовательность 3,0,4,4 даёт сумму 11, и соответственно, тоже значение 1 по описанному методу. Это называется коллизией.

Компьютерное хеширование устроено чуть сложнее, но принцип похожий.

Следующим этапом защиты стал шифрованный канал передачи паролей, защита хранилищ хеш-сумм и усложнение самих алгоритмов хеширования. Основные атаки превратились в кражи готовых хеш-значений и последующий локальный подбор паролей. Важно здесь именно длина пароля: если потенциальный пароль содержит до 32 различных символов длиной шесть знаков, возможных комбинаций будет ровно 32 в степени 6=1,073,741,824. Перебирая по 10 тысяч вариантов в секунду, понадобится порядка 107 тысяч секунд (≈30 часов).

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

Продолжение , начало

С приходом веба эволюция с паролями повторилась. Конечно, появилось несколько решений для интернет-банков с авторизацией по сертификатам. Но поначалу веб представлял собой простой протокол HTTP — без какого-либо шифрования. Уровень разработчиков, конечно, снизился: теперь это были уже не опытные программисты на C, а больше на скриптовых языках типа Perl, PHP.

На первых порах использовали встроенную в HTTP-аутентификацию. Потом стали создавать красивые формочки. Аутентификация в вебе представляла собой отправку методом POST по HTTP двух полей из формы на веб-странице — логина и пароля. Никакого шифрования, и любой, кто немного напрягал мозги и пользовался снифером, наслаждался тоннами соседских паролей из локальной сети.

Нешифрованные соединения были повсюду: http, smtp, pop3, ICQ. HTTPS был чем-то редким. Банки боролись с этим собственными решениями. Например, в 1999 году — мой банк предлагал специального клиента, становящегося прокси у браузера (и, разумеется, собственную пластиковую карту). В банках помимо паролей раздавались печатные наборы слов. Чтобы зайти в интернет-банк, вводили логин и пароль, после чего дополнительно указать одно из слов набора. Никакие SMS ещё не использовались. На банковских серверах хранилась копия набора слов, а у пользователей имелся распечатанный бумажный список. Это защищало от ситуации, когда начинающие хакеры могли бы подложить клавиатурного шпиона и украсть пароль. И банки старались шифровать соединений.

Потом SMS и сотовые подешевели, а мобильник превратился из предмета роскоши в обычную нужную вещь. К логину и паролю добавились СМС. Сейчас это используют для простой цифровой подписи (типа подписываешь документы, вводя код из СМС). Работает это просто: сервер генерирует случайное число и запоминает его, затем отправляет по СМС. Далее — ввод логина, пароля и кода из СМС. Серверу нужно лишь сравнить то, что он запомнил, и то, что вы ввели из СМС.

Но времена меняются — теперь сервисы не хотят отправлять SMS («капиталисты хотят экономить»). Да и с появлением Android получить доступ к сообщениям на устройстве стало довольно просто. В итоге они придумали программную реализацию старых методов с набором кодовых слов.

Теперь при первой регистрации или аутентификации — считается, что всё защищено должным образом (HTTPS и прочие меры). Система выдаёт случайный набор цифр, который сохраняется в мобильное приложение (например через QR код). Во время последующей авторизации нужно ввести соответствующее слово из мобильного приложения. Само приложение выбирает нужное слово исходя из текущего времени устройства. Но обычно используют вариант с цифрами вместо слова — экономят на локализации.Синхронизация точного времени давно стала стандартной задачей. Если даже немного сбить часы устройства (хотя бы на час), HTTPS перестанет корректно функционировать (точнее не скажу, пусть будет час).

Пример функции с цифрами: есть, например, время — 02.08.2025, 23:05:50 (MSK). На мобильнике пользователя и на сервере разница пусть будет 20 секунд. Разница в 20 секунд легко достижима, если специально не менять настройки мобильника. Алгоритм, скажем, приведёт это время по Гринвичу — 02.08.2025, 20:05:50 (UTC), отбросит секунды — получится 02.08.2025, 20:05. Затем сложим всё вместе:

0 + 2 + 0 + 8 + 2 + 0 + 2 + 5 + 2 + 0 + 0 + 5 = 26

Полученное значение 26 умножим на заранее запомнённое устройством число, допустим, 10. Получится 260. Эту цифру покажем пользователю. Обычно чисел больше, алгоритм сложнее, но общий принцип тот же самый.

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

Задавайте вопросы! Если интересно — расскажу, что ещё придумали злые программисты для аутентификации.