Ответ 1
Этот вопрос был рассмотрен в несколько иной форме, здесь:
Но это обращается к нему со стороны сервера. Давайте посмотрим на это с клиентской стороны. Прежде чем мы это сделаем, есть важная прелюдия:
Javascript Crypto is Hopeless
Статья Матасано об этом известна, но уроки, содержащиеся в ней, очень важны:
http://www.matasano.com/articles/javascript-cryptography/
Подводя итог:
- Атака "человек в середине" может тривиально заменить ваш криптокод на
<script> function hash_algorithm(password){ lol_nope_send_it_to_me_instead(password); }</script> - Атака "человек-в-середине" тривиальна против страницы, которая обслуживает любой ресурс по не-SSL-соединению.
- Как только у вас есть SSL, вы все равно используете реальный крипто.
И добавить свое собственное:
- Успешная атака XSS может привести к тому, что злоумышленник выполнит код в вашем браузере клиента, даже если вы используете SSL - так что, даже если у вас есть каждый люк, вы можете отключить криптовальщик вашего браузера, если ваш атакующий найдет способ выполнить любой код javascript на другом браузере.
Это делает невозможным или глупым множество схем аутентификации RESTful, если вы намереваетесь использовать клиент JavaScript. Давай посмотрим!
HTTP Basic Auth
Прежде всего, HTTP Basic Auth. Простейшая схема: просто передайте имя и пароль с каждым запросом.
Это, конечно, абсолютно требует SSL, потому что вы передаете Base64 (обратимо) кодированное имя и пароль с каждым запросом. Любой, кто прослушивает эту строку, может извлекать имя пользователя и пароль тривиально. Большинство аргументов "Basic Auth is insecure" исходят из места "Basic Auth over HTTP", что является ужасной идеей.
В браузере предусмотрена поддержка HTTP Basic Auth, но она уродлива, как грех, и вы, вероятно, не должны использовать ее для своего приложения. Альтернативой, однако, является спрятать имя пользователя и пароль в JavaScript.
Это самое RESTful решение. Сервер не требует каких-либо знаний о состоянии и аутентифицирует каждое индивидуальное взаимодействие с пользователем. Некоторые энтузиасты REST (в основном, соломенные) настаивают на том, что поддержание любого состояния является ересью и будет пениться во рту, если вы думаете о каком-либо другом методе проверки подлинности. Существуют теоретические преимущества такого соответствия стандартам - он поддерживается Apache из коробки - вы можете хранить свои объекты в виде файлов в папках, защищенных файлами .htaccess, если вам нужно сердце!
Проблема ? Вы используете на стороне клиента имя пользователя и пароль. Это дает evil.ru лучший треск на нем - даже самые простые из уязвимостей XSS могут привести к тому, что клиент будет бить свое имя пользователя и пароль злому серверу. Вы можете попытаться смягчить этот риск, хэшируя и засовывая пароль, но помните: JavaScript Crypto is Hopeless. Вы могли бы смягчить этот риск, оставив его до поддержки браузера Basic Auth, но... уродливым как грех, как упоминалось ранее.
HTTP Digest Auth
Возможно ли аутентификация дайджеста с помощью jQuery?
Более "безопасный" auth, это запрос хеша запроса/ответа. За исключением JavaScript Crypto is Hopeless, поэтому он работает только через SSL, и вам все равно придется кэшировать имя пользователя и пароль на стороне клиента, что делает его более сложным, чем HTTP Basic Auth, но не более безопасным.
Аутентификация запроса с дополнительными параметрами подписи.
Еще одно "безопасное" auth, где вы шифруете свои параметры с помощью несевых и временных данных (для защиты от повторных и временных атак) и отправки. Одним из лучших примеров этого является протокол OAuth 1.0, который, насколько мне известно, является довольно сложным способом реализации проверки подлинности на сервере REST.
http://tools.ietf.org/html/rfc5849
О, но нет клиентов OAuth 1.0 для JavaScript. Зачем?
JavaScript Crypto is Hopeless, помните. JavaScript не может участвовать в OAuth 1.0 без SSL, и вам все равно нужно локально хранить имя пользователя и пароль клиента, что ставит его в ту же категорию, что и Digest Auth - это сложнее, чем HTTP Basic Auth, но не более безопасно.
Знак
Пользователь отправляет имя пользователя и пароль, а взамен получает токен, который может использоваться для аутентификации запросов.
Это немного более безопасно, чем HTTP Basic Auth, потому что как только транзакция имени пользователя/пароля будет завершена, вы можете отбросить конфиденциальные данные. Это также меньше RESTful, поскольку токены составляют "состояние" и усложняют реализацию сервера.
SSL еще
Правда, вам все равно придется отправить это начальное имя пользователя и пароль, чтобы получить токен. Чувствительная информация по-прежнему касается вашего компрометирующего JavaScript.
Чтобы защитить учетные данные пользователя, вам все равно нужно избегать атаки злоумышленников из вашего JavaScript, и вам все равно нужно отправить имя пользователя и пароль по кабелю. Требуется SSL.
Срок действия токена
Общепринято применять политики токена, такие как "эй, когда этот токен слишком долго, отбросьте его и повторите проверку подлинности пользователя". или "Я уверен, что единственным IP-адресом, разрешенным для использования этого токена, является XXX.XXX.XXX.XXX". Многие из этих политик являются довольно хорошими идеями.
Firesheeping
Однако использование токена Без SSL все еще уязвим для атаки под названием "sidejacking": http://codebutler.github.io/firesheep/
Злоумышленник не получает ваши учетные данные пользователя, но они все еще могут притворяться вашим пользователем, что может быть очень плохо.
tl; dr: Отправка незашифрованных токенов по проводу означает, что злоумышленники могут легко набить эти маркеры и притворяться вашим пользователем. FireSheep - это программа, которая делает это очень просто.
Отдельная, более безопасная зона
Чем больше приложение, которое вы используете, тем сложнее убедиться, что они не смогут ввести какой-либо код, который изменяет процесс обработки конфиденциальных данных. Вы абсолютно доверяете своему CDN? Ваши рекламодатели? Ваша собственная база кода?
Общие сведения о кредитной карте и менее распространенные для имени пользователя и пароля - некоторые разработчики сохраняют "конфиденциальный ввод данных" на отдельной странице из остальной части своего приложения, страницы, которая может быть жестко контролируемой и заблокирована как можно лучше, предпочтительно тот, с которым сложно подключить пользователей.
Cookie (только означает токен)
Возможно (и распространено) поставить токен аутентификации в файл cookie. Это не изменяет никаких свойств auth с токеном, это скорее удобная вещь. Все предыдущие аргументы все еще применяются.
Сессия (еще только означает токен)
Session Auth - это аутентификация только Token, но с несколькими отличиями, которые делают это несколько иначе:
- Пользователи начинают с неавторизованного токена.
- Бэкэнд поддерживает объект 'state', привязанный к токену пользователя.
- Токен предоставляется в файле cookie.
- Прикладная среда абстрагирует детали от вас.
Кроме того, однако, он не отличается от Token Auth, действительно.
Это еще больше удаляется от реализации RESTful - с объектами состояния, которые вы продвигаете дальше и дальше по пути простого RPC RPC на конечном сервере.
OAuth 2.0
В OAuth 2.0 рассматривается проблема "Как программное обеспечение A предоставляет ПО B доступ к данным пользователя X без программного обеспечения B, имеющего доступ к учетным данным пользователя X."
Реализация - это всего лишь стандартный способ для пользователя получить токен, а затем для стороннего сервиса "yep", этот пользователь и этот токен, и вы можете получить некоторые из своих данных от нас сейчас ".
В сущности, OAuth 2.0 - это всего лишь протокол токена. Он обладает теми же свойствами, что и другие протоколы токенов - для защиты этих токенов вам все еще нужен SSL, он просто изменяет способ генерации этих токенов.
Существует два способа, которыми OAuth 2.0 может помочь вам:
- Предоставление аутентификации/информации другим
- Получение аутентификации/информации от других
Но когда дело доходит до этого, вы просто... используете токены.
Вернуться к вашему вопросу
Итак, вопрос, который вы задаете, - "Я должен хранить свой токен в файле cookie и настроить автоматическое управление сеансом моей среды на детали, или я должен хранить свой токен в Javascript и самостоятельно обрабатывать эти данные?"
И ответ: делайте то, что делает вас счастливыми.
Дело в автоматическом управлении сеансами, тем не менее, заключается в том, что для вас много волшебства, происходящего за кулисами. Часто лучше контролировать эти детали самостоятельно.
Мне 21, поэтому SSL да
Другой ответ: используйте https для всего, или разбойники украдут пароли и токены ваших пользователей.