Можно ли считать ключи сеанса пользователя, не сохраненные сервером выдачи, безопасными?

Question

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

1. Взять первичный ключ пользователя (он же "идентификатор пользователя")
2. Возьмите выбранную метку времени истечения срока действия ключа и, необязательно, IP-адрес клиента и все, что еще может стоить встраивания в ключ
3. Взять секретную строку в качестве подписи проверки ключа
4. Сериализация всего вышеперечисленного
5. Шифрование результата симметрично с помощью ключа, известного только серверу, или асимметрично с использованием выбранного закрытого ключа сервера

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

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

Преимущества подхода, который я вижу, таковы:

1. Нет необходимости поддерживать действительное отношение ключа пользователя, установленное в любом месте
2. Значение срока действия, встроенное в каждый ключ, гарантирует, что ключи не могут использоваться кем-либо за определенный период времени.
3. Проверка на основе расшифровки сервером может быть дешевле, чем доступ к базе данных.

Недостатками могут быть:

1. Аннулирование ключей сервером может считаться проблемным:
   • Даже если ключ надежно встраивается, например, IP-адрес, где сервер может использовать последний для проверки ключа путем сравнения встроенного адреса с адресом, стоящим за запросом на обслуживание, может быть подделан IP-адрес
   • Если проблема отзыва ключей решается сервером, поддерживающим набор отозванных ключей, можно спросить, как это лучше, чем поддерживать набор отношений между ключами и пользователями в первую очередь?

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

Answer 1

Слабость системы заключается в том, что «авторизованный» токен отправляется в виде cookie в виде открытого текста, и это та же слабость, независимо от того, находится токен в базе данных или нет, и защищается с помощью HTTPS-соединений. *

Сказав это, большинство сайтов не используют HTTPS. Они делают компромисс. Если вы не используете HTTPS и хотите сравнить отправку аутентифицированного куки-файла с посылкой куки-файла - это ключ базы данных, то в первой нет ничего, кроме последней.

Рекомендуется также указать IP-адрес запроса и дату истечения срока действия.

Нет необходимости хранить токен в зашифрованном виде в файле cookie, однако - он одинаково безопасен и гораздо более простой для отправки открытых текстовых учетных данных и затем криптографически безопасный хэш учетных данных и секрета. Подробнее см. HMAC . HMAC в основном:

Представьте себе, что переменные username, expires, ip_address и salt (случайное число) были сохранены в HttpOnly cookie; Вы извлекаете их, а также ваш хэш, который также был в cookie. В вашем скрипте у вас есть дополнительный «пароль», который никогда не сохраняется непосредственно в куки:

hash = hash_hmac("sha256",username+expires+ip_address+salt,"password")

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

Если хеш в файле cookie верен, вы можете быть уверенным , что хешированные поля не были изменены! Вероятность того, что злоумышленник произведет значимое столкновение, составит от одного до нескольких миллиардов [1] - безусловно, за пределами вычислительной мощности всех компьютеров во вселенной и нескольких миллиардов лет. Это так безопасно, если ваш пароль является случайным.

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

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

Решительный злоумышленник может скопировать учетные данные и отправить злые запросы от имени пользователя, например, csrf и т. Д.

и т. Д.

[1] Я занижаю шансы.

Answer 2

Что вы хотите использовать для шифрования / дешифрования данных?

Как правило, я бы не советовал делать то, о чем вы говорили выше, потому что:

• Почему бы не иметь все сеансы в централизованном хранилище? Ваш алгоритм шифрования также может быть украден / взломан.
• Доступ к базе данных, скорее всего, будет быстрее и проще в управлении / код

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

Хотели ли вы использовать стандартную библиотеку сессий в PHP?

Answer 3

Не очень хорошая идея. A очень похоже (и, по сути, если я правильно понимаю, одинаковый) вопрос был задан несколько недель назад. Мой ответ был (я добавил ударение, чтобы подчеркнуть основной момент):

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

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

Существуют лучшие и масштабируемые решения для этой проблемы. Почему бы, например, не настроить центральный экземпляр проверки сеанса, который могут опрашивать все связанные серверы и службы? Посмотрите в Интернете, я на 100% уверен, что есть готовые решения, отвечающие вашим потребностям.

Answer 4

Мне нравится этот метод, и я использую его для своих веб-сайтов, потому что его легко масштабировать.

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

Дополнительное чтение: Реализация PHP , которая содержит ссылку на замечательную статью на эту тему (извините, я не могу опубликовать более одной ссылки в стеке на данный момент;).