Идентификация - аутентификация. Часть 2. Протоколы с фиксированными паролями.

Итак, в прошлый раз мы рассмотрели Основные понятия и классификацию протоколов идентификации - аутентификации.
Сегодня поговорим о пункте 1.1 - протоколы с фиксированным паролем.
В цикле - это вторая теоритическая заметка.
--
Собственно, самый простой способ аутентификации - это просто пароль (или его разновидности). В основном принцип функционирования следующий:
A отправляет на сервер идентификатор и пароль. B проверяет что пароль соответствует идентификатору и присваивает A этот идентификатор. Пароль, естественно, храниться в секрете.
Итак, рассмотрели самый простой и ненадёжный случай. Протоколы тут очевидны и похожи. поэтому далее рассмотрим различные требования и вариации.

--
Что в самой простой схеме плохого?

• Подбор паролей для усложнения вводят timeout, или задержки по времени между попытками аутентификации, а также предъявляют требования к паролем, о них позже.
• Нет защиты от прослушивания. Тут совсем беда - мало того что при перехвате трафика получат пароль для доступа и идентификатор, так ещё этот пароль может быть не только от одного сервиса - есть возможность взлома иных систем. Так ещё и можно увидеть предпочтения пользователя в формировании паролей, и дальнейшее составления словаря.
• В самом простом случае пароли храняться просто в "файле" или БД открыто - то при доступе к БД (базе данных) пароли опять у злоумышленника

Эти протоколы, даже в самом простом виде имеют место быть. Да, в случае веб-приложения простые парольные системы опасны из-за прослушки. Но для локальных, не использующих сетевую инфраструктуры приложений - это вполне нормально. Поэтому главное позаботиться о атаках вида "подбора" и "взлома хранилища" у B.

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

• Рекомендации к паролям:
  1. Ограничения на минимальную длинну
  2. Невозможность того, чтобы пароль был частью идентификатора и наоборот
  3. Наличие символов разного регистра, цифр, знаков и.т.д
• Рекомендации к Хранилищу
  1. Защита от доступа неавторизированных пользователей - обычно доступ имеет только администратор
  2. Шифрование паролей
  3. Хэширование паролей (о хэшировании мы ещё не говорили - об этом чуть далее, тут имеется в виду дополнительное хэширование, а лучше даже шифрование)

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

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

--
Теперь ненмого о WEB. Я уже говорил ранее, что протоколы на основе фиксированных паролей очень слабы. Хотя одноразовые пароли могут тут пригодиться. Но всёже, для идентификации рекомендуется использовать более сложные схемы, о которых мы поговорим в следующих чатях цикла.
Но всёже, существует одна проблема. Сложные алгоритмы требуют большего числа шагов -> больше подключений. Естественно это неудобно, да и вводить пароль каждый раз при отправке данных, скажем, в социальной сети - это неудобно.

Поэтому применяют более сложные способы аутентификации (о которых потом), после чего B предоставляет A временный секрет (пароль). Обычно это делают на основе Cookie, в которых хранится большая сгенерированная случайная последовательность, которая используется для так называемой Cookie-base аутентификации (тотже протокол с фиксированным паролем, только в качестве пароля cookie).
Если злоумышленник похитил эти Cookie, то фактически он может получить доступ, но только на время, пока не истечёт срок валидности Cookie, или пока пользователь не нажмёт кнопку "Выход" (в этом случае обычно cookie сбрасывают) Также для выполнения критических задач просят пройти повторную идентификацию по более надёжному протоколу.
Иногда также эти cookie подписываются сервером, и привязываются к ip, хотя последнее обходится злоумышленником с помощью ip-spoofing.

--
А теперь печенька для терпеливых. Пример алгоритма с одноразовым паролем. Кстати, этот метод можно применять и для cookie-base аутентификации.
Берём суперсекретный пароль W. H(W) - криптографическая хэш-функция. H^2(W) =H(H(W)) Тогда для n : H^n(W) = H(H(..........)) - Тоесть словами, H^n(W) - это рекурсивно взятая n-раз хэш-функция для W.
Тогда для i-й идентификации паролем будет Wi=H^(n-i)(W)

A отправляет B свой идентификатор + i (номер идентификации) + Wi.
B проверяет что H(Wi) = W(i-1)
Если равенство выполняется B идентифицирует A

Недостаток: Не защищает от активного противника, который перехватывает, сохраняет и блокирует передачу информации от A к B.