Демистификация веб-аутентификации - PullRequest
12 голосов
/ 22 октября 2010

В настоящее время я изучаю протоколы аутентификации пользователей для разрабатываемого веб-сайта.Я хотел бы создать файл 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;

Я вижу, что он уязвим к атакам воспроизведения, как указано в Безопасный протокол cookie , но должен быть устойчивым кОбъемные атаки и криптографическое соединение.

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

ПРИМЕЧАНИЯ

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

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

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

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

Ответы [ 3 ]

7 голосов
/ 11 февраля 2013

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

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

  • Поместите поле в свои пользовательские данные, которое будет обновляться при смене пароля (может быть, счетчик генерации пароля или даже просто случайная соль), и включите это поле в токен и подписанную часть. Затем, когда пользователь меняет свои пароли, он также делает недействительными любые другие украденные токены. Без этого вы ограничены тем, как долго вы можете позволить токену жить до истечения срока действия.

  • Поместите идентификатор схемы в токен и подписанную часть, чтобы (а) у вас могли быть разные типы токенов для разных целей (например, один для аутентификации и один для защиты XSRF), и (б) вы может обновить механизм новой версией без необходимости аннулировать все старые токены.

  • Убедитесь, что user_id никогда не используется повторно, чтобы предотвратить использование токена для получения доступа к другому ресурсу с тем же идентификатором.

  • Разграничение каналов предполагает, что | никогда не может появиться ни в одном из значений поля. Это, вероятно, работает для числовых значений, с которыми вы (предположительно) имеете дело, но в какой-то момент вам может понадобиться более сложный формат, например, пары имя / значение в кодировке URL.

  • Двойной HMAC, похоже, не очень-то вас привлекает. Как грубой силой, так и криптоанализом против HMAC-SHA256 уже сложилось невероятное суровое понимание.

0 голосов
/ 18 февраля 2013

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

  1. ваш файл cookie сеанса не является случайным источником с высокой энтропией.
  2. Сервер должен выполнять асимметричное шифрование на каждой странице, чтобыпроверить пользователя.
  3. Безопасность ЛЮБОГО пользователя зависит только от безопасности ключа сервера sk.

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

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

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

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

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

0 голосов
/ 15 февраля 2013
  1. Если ваши транзакции в секунду не будут облагаться налогом на ваше оборудование, я бы только передал хеш в cookie (т.е. оставил бы user_id и expiry_date - нет смысла давать плохим людям больше информации, чем вам абсолютно необходимо) .

  2. Вы можете сделать некоторые предположения о том, каким должен быть следующий динамический IP-адрес, учитывая предыдущий динамический IP-адрес (увы, у меня нет подробностей). Хэширование только неизменной части динамического IP-адреса поможет в проверке пользователя даже при изменении его IP-адреса. Это может или не может работать, учитывая разнообразие схем распределения IP-адресов.

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

  4. Вам нужно подумать о том, как долго ваши куки должны оставаться свежими. Если вы можете жить с людьми, которым приходится проходить аутентификацию один раз в день, это будет проще для вашей системы аутентификации, чем если бы люди могли проходить аутентификацию только раз в месяц (и т. Д.).

...