Post #521

Продолжение , начало С приходом веба эволюция с паролями повторилась. Конечно, появилось несколько решений для интернет-банков с авторизацией по сертификатам. Но поначалу веб представлял собой простой протокол 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. Эту цифру покажем пользователю. Обычно чисел больше, алгоритм сложнее, но общий принцип тот же самый. То же самое проделывает сервер, пользователю остаётся лишь шустро ввести числа с мобильного устройства, а сервер сравнит полученный результат с переданным значением. В отличие от пароля такие числа каждый раз будут разными. Задавайте вопросы! Если интересно — расскажу, что ещё придумали злые программисты для аутентификации.