Безопасность аутентификации на основе токенов - PullRequest
6 голосов
/ 12 января 2011

Мое понимание аутентификации на основе токенов заключается в том, что после аутентификации (возможно, через ssl) токен передается пользователю для дешевой проверки пользователя на лету.Одной из реализаций этого было бы создание файла cookie, который передается пользователю для управления сеансом.

Но, насколько я понимаю, аутентификация на основе токенов (по крайней мере, с помощью файлов cookie) восприимчива к атакам типа человек в середине, таким какfiresheep.

Существуют ли другие способы реализации, которые позволяют обойти эту серьезную проблему безопасности, или у меня есть фундаментальное недопонимание tba?

1 Ответ

10 голосов
/ 12 января 2011

Ваше понимание хорошо. По сути, с точки зрения приложения, токен также может быть именем пользователя и паролем. Если у кого-то есть токен, он может аутентифицироваться в вашем приложении. Основная цель в случае файла cookie http - избежать утечки имени пользователя и пароля, если кто-либо получит файл cookie с помощью уязвимости межсайтового скриптинга (XSS) или иным образом. Да, при правильных обстоятельствах они могут «воспроизвести» этот токен для приложения как «человек посередине», но они не должны быть в состоянии выяснить сопряжение имени пользователя и пароля, но, опять же, это не гарантируется, если токен Скажем, алгоритм генерации слаб, например, если вы решили BASE64 кодировать имя пользователя и пароль, объединенные вместе, и использовать это в качестве значения.

Обычно токен -> сопоставление пользователей защищен на стороне сервера. Таким образом, в конечном итоге ваша безопасность основана на обеспечении безопасности токена и обеспечении контроля его срока службы (например, срок его действия истекает и / или он действителен только в том случае, если он предоставлен вам с того же IP-адреса, что и исходный поставщик учетных данных - опять просто пример)

Надеюсь, это поможет,

-Oisin

...