Демистификация веб-аутентификации

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

Вот мой первый bash:

cookie = user_id|expiry_date|HMAC(user_id|expiry_date, k)

Где k - HMAC(user_id|expiry_date, sk), а sk - это 256-битный ключ, известный только серверу. HMAC - это хэш SHA-256. Обратите внимание, что '|' является разделителем, а не просто конкатенацией.

В PHP это выглядит так:

$key = hash_hmac('sha256', $user_id . '|' . $expiry_time, SECRET_KEY);
$digest = hash_hmac('sha256', $user_id . '|' . $expiry_time, $key);
$cookie = $user_id . '|' . $expiry_time . '|' . $digest;

Я вижу, что он уязвим для Replay Attacks, как указано в Secure Cookie Protocol, но должен быть устойчивым к Volume Attacks и криптографическому сращиванию.

ВОПРОС: Я нахожусь на правильных линиях здесь, или есть огромная уязвимость, которую я пропустил? Есть ли способ защитить от Replay Attacks, который работает с динамически назначенными IP-адресами и не использует сеансы?

ПРИМЕЧАНИЯ

Самый последний материал, который я прочитал:
Дос и отсутствие аутентификации клиента в Интернете aka Fu et al.
(https://pdos.csail.mit.edu/papers/webauth:sec10.pdf)

Безопасный протокол cookie aka Liu и др.
(http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf)
который расширяется по предыдущему методу

Закаленные cookie-сессии без сохранения состояния
(http://www.lightbluetouchpaper.org/2008/05/16/hardened-stateless-session-cookies/)
который также расширяется по предыдущему методу.

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

Ответ 1

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

Незначительные предложения:

Поместите поле в свои пользовательские данные, которое будет обновляться при смене пароля (может быть, счетчик генерации пароля или даже случайная соль) и включить это поле в токен и подписанную часть. Затем, когда пользователь изменяет свои пароли, они также аннулируют любые другие украденные жетоны. Без этого вы ограничены тем, как долго вы можете разумно разрешить токен жить до истечения срока действия.
Поместите идентификатор схемы в токен и подписанную часть, чтобы (а) у вас могли быть разные типы токенов для разных целей (например, один для auth и один для защиты XSRF), и (b) вы может обновить механизм с новой версией без необходимости аннулировать все старые токены.
Убедитесь, что user_id никогда не используется повторно, чтобы предотвратить использование токена для доступа к другому ресурсу с тем же идентификатором.
Разграничение труб предполагает, что | никогда не может появляться ни в одном из значений поля. Вероятно, это работает с числовыми значениями, которые вы, по-видимому, имеете в виду, но в какой-то момент вам может понадобиться более сложный формат, например, пары имени/значения URL-кодировки.
Двойной HMAC, похоже, вам не очень-то нравится. Как грубая сила, так и криптоанализ против HMAC-SHA256 уже неумолимо трудны по настоящему пониманию.

Ответ 2

Если ваши транзакции/секунда не будут облагать налогом ваше оборудование, я бы только передал хэш в cookie (то есть не укажу user_id и expiry_date - нет смысла давать плохим людям больше информации, чем вам абсолютно необходимо).
Вы можете сделать некоторые предположения о том, каким должен быть следующий динамический IP-адрес, учитывая предыдущий динамический IP-адрес (у меня нет данных, удобных, увы). Хеширование только неизменной части динамического IP-адреса поможет в проверке пользователя, даже когда их IP-адрес изменится. Это может работать или не работать, учитывая разновидности схем распределения IP-адресов.
Вы можете получить информацию об этой системе и хэш, а также - в Linux вы могли бы uname -a (но есть и другие возможности, доступные для других ОС). Достаточная системная информация, и вы можете пропустить с помощью (частичного) IP-адреса целиком. Этот метод потребует некоторых экспериментов. Использование только стандартной информации, предоставляемой браузером, упростит ее.
Вам нужно подумать о том, как долго ваши куки должны оставаться свежими. Если вы можете жить с людьми, которые должны пройти аутентификацию один раз в день, это будет проще при кодировании вашей системы, чем разрешать людям проходить проверку подлинности только один раз в месяц (и т.д.).

Ответ 3

Я считаю этот протокол очень слабым!

ваш сеансовый cookie не является случайным источником с высокой энтропией.
Для проверки пользователя сервер должен выполнять асимметричное шифрование на каждой странице.
Безопасность пользователя ANY зависит только от безопасности сервера-ключа sk.

Сервер-ключ SK является наиболее уязвимой частью здесь. Если кто-то может догадаться или украсть его, он может войти в систему как конкретный пользователь.

Итак, если sk генерируется для каждого сеанса и пользователя, то почему hmac? Я думаю, вы будете использовать TLS в любом случае, если нет, рассмотрите свой протокол как сломанный из-за повторных атак и подслушивания в целом!

Если sk генерируется для каждого пользователя, но не для каждого сеанса, он похож на 256-битный пароль.

Если sk одинаково для всех пользователей, кто-то просто должен взломать 256 бит, и он может войти в систему как любой пользователь, которого он хочет. Он должен только угадать идентификатор и дату истечения.

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