Использовать проверку данных клиента на основе hmac вместо сеансов?

Question

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

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

Обычно мы храним идентификатор пользователя и некоторые случайные данные (у меня нет конкретного примера).

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

Например, если у пользователя есть id = 9999, мы обычно храним его в файле, связанном с идентификатором сеанса.Каждый раз, когда клиент делает запрос, мы проверяем его идентификатор сеанса и извлекаем данные из файла сеанса, связанного с ним.

Я думаю о сохранении данных сеанса на стороне клиента, и каждый раз, когда клиент делает это запросотправляет хэш этих данных и данных.

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

Является ли это допустимым способом замены сеансов?Какие недостатки существуют, кроме того, что они не сохраняют данные сеанса на сервере?

Я был обеспокоен скоростью и сделал небольшой тест ...

<?php

$session = array(
    'userId' => 999,
    'timestamp' => time()
);
$privateKey = 'da39a3ee5e6b4b0d3255bfef95601890afd80709';

$startTime = microtime(true);

for ($i = 0; $i < 1000000; $i++){
    $hash = hash_hmac('sha1', json_encode($session), $privateKey);
}

echo 'Script took ' . (microtime(true) - $startTime) . ' seconds';

... который печатает

Script took 5.246542930603 seconds

Я запустил это на ноутбуке (Intel Duo).На мой взгляд, это доступное время (0,000005247 за хэш).Тест верен?

РЕДАКТИРОВАТЬ: метка времени хешируется вместе с идентификатором пользователя для обеспечения истечения сеанса.Таким образом, на стороне сервера, даже если сеанс действителен, но он слишком старый, его можно считать истекшим.

То есть, если мы хэшируем данные вместе с меткой времени с использованием закрытого ключа, это можно использовать в производстве

Answer 1

Я могу вспомнить несколько недостатков ...

1. Все данные cookie передаются при каждом HTTP-запросе, что замедляет запрос.
2. Пользователь может видеть все данные.
3. Вам еще нужно проверить действительность хэша, поэтому я не знаю, сколько времени или пространство это спасает вас.
4. Если есть возможность перепроектировать хэш (то есть, вы не используете какое-либо шифрование с закрытым ключом), пользователь может отправить что угодно, и вы скажете, что оно действительно.
5. Если у вас есть хеш, который не может быть подвергнут реинжинирингу, он, вероятно, генерируется довольно медленно. Вы говорите, что используете закрытый ключ, так что это может быть применимо. Решение может плохо масштабироваться.
6. Кто будет поддерживать этот код после того, как вы удивитесь, что вы сделали.

Answer 2

Единственное, что хорошо в этом - вам не нужно запоминать sessiond_id.Это слишком много работы.Я не знал, что он называется ViewState, но в итоге я использовал сжатие для хранения всех этих данных в скрытом поле на стороне клиента.Может быть, хорошей практикой является использование сжатия вместо шифрования?Это безопасность по неизвестности.