Может ли мое веб-приложение внедрить имя пользователя и остаться без состояния? - PullRequest
7 голосов
/ 21 июля 2010

У нас есть веб-приложение без состояния.Мы используем http-аутентификацию по SSL / TLS.Браузеры пользователя предположительно хранят учетные данные для аутентификации (возможно, даже после закрытия браузера, если они настраивают свои браузеры таким образом.) Мы проверяем их при каждом доступе.

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

  • Оставаться без состояния.
  • Не требовать от пользователей повторного ввода учетных данных при каждом доступе.
  • Будьте хотя бы какбезопасный как http-аутентификация по SSL / TLS.

Например, мы готовы использовать файлы cookie и можем сохранить имя пользователя и пароль в виде файла cookie.Однако это кажется менее безопасным.Но так ли это?Если мы используем непостоянный файл cookie, является ли он менее безопасным, чем любой другой метод, используемый браузером для хранения учетных данных на время сеанса или дольше?

Мы можем сохранить имя пользователя и хэш пароля, как это предлагаетсяздесь: Что я должен хранить в файлах cookie для реализации «Запомнить меня» при входе пользователя в систему , но разве это лучше?

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

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

Буду признателен за ваши мысли, но давайте начнем спредположение, что http-аутентификация через SSL / TLS является безопасной , достаточной для наших целей, и мы хотим остаться без состояния.

EDIT

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

Ответы [ 3 ]

1 голос
/ 21 июля 2010

В закрытой системе (интрасети компании или просто обычный сайт, но с небольшой толпой), проверка SSL-сертификатом предпочтительнее. Выпустите сертификат для каждого пользователя, позвольте ему установить его в своих браузерах, и вы можете отозвать доступ к этому сертификату в любое время (см., Например, систему идентификации ssl-cert на myopenid.com (к сожалению, глючит a.t.m.).

Это потребует некоторой работы со стороны ваших пользователей, и если это невозможно / нежелательно, то cookie-токен будет гораздо предпочтительнее, и если вы ищете комбо user / passwd или cookie-токен, не должны создавать такая большая разница.

0 голосов
/ 21 июля 2010

Возможно, вы захотите рассмотреть сеансы PHP в качестве альтернативы файлам cookie.

Вы можете начать сеанс с одного вызова session_start().

Оттуда вы можете хранить любые данные о пользователе, которые вам нужны, с глобальным массивом $_SESSION.

Это не учитывает, КАК вы будете аутентифицировать пользователей в первую очередь.Обычно это делается путем поиска сохраненных имен пользователей / паролей в базе данных.

0 голосов
/ 21 июля 2010

Я не вижу случайного токена как более или менее не имеющего состояния, чем имя пользователя и пароль.

И то, и другое нужно искать в какой-либо форме базы данных. Ваша заявка уже имела состояние. Состояние быть аутентифицированным или не аутентифицированным.

Имя пользователя и пароль, которые были отправлены, были точно такими же, как случайный токен.

Итак, мой ответ на ваш вопрос - нет. Веб-приложение не может реализовать какую-либо форму аутентификации пользователя и оставаться без состояния.

...