Краткий ответ
Не делай этого.Вы пожалеете об этом в долгосрочной перспективе.Конечно, вы можете зашифровать его, но что произойдет, когда кто-то выяснит ваш ключ шифрования.Теперь вы просто передали им учетные данные всех пользователей на табличке (ну, не совсем, но достаточно близко).
Лучший способ сделать это
Вместо того, чтобы хранить зашифрованное имя пользователя и парольпочему бы не создать случайный токен и сохранить его под именем пользователя?Вы хотели бы что-то значительное, поэтому должно быть достаточно что-то вроде sha256 хеша.
$randomToken = hash('sha256',uniq_id(mt_rand(), true).uniq_id(mt_rand(), true));
Затем сохраните его в базе данных рядом с пользователем и отправьте cookie клиенту (я бы также предложил подписать токен, чтобы предотвратить подделку:
$randomToken .= ':'.hash_hmac('md5', $randomToken, $serverKey);
Теперь, когда вы подтвердите, сначала убедитесь, что хеш совпадает:
list($token, $hmac) = explode(':', $_COOKIE['remember_me'], 2);
if ($hmac != hash_hmac('md5', $token, $serverKey)) {
die('tampered token!');
}
Оттуда, просто найдите пользователя по токену. Если вы найдете его, войдите в систему этого пользователя.
Я бы также предложил менять маркер при каждой смене пароля.
Чтобы ответить на ваш вопрос напрямую
Примечание: не делайте этого в живом, производственном коде Вы никогда не можете полностью доверять данным, которые покидают ваш веб-сервер. Поэтому не раскрывайте информацию о вашем пользователе таким образом. Это того не стоит. Однако я добавил некоторые дополнительные проверки (такие как подпись cookie), чтобы сделать их несколько более безопасными., но вас предупредили ...
Чтобы закодировать его, я бы использовал mcrypt для шифрования данных в cookie. Затем я бы сделал случайную соль и сохранил еес строкой пользователя, а затем подписать зашифрованные данные с hash_hmac используя эту уникальную соль.Таким образом, если кто-то перехватит файл cookie и определит ключ для шифрования, вы все равно сможете обнаружить недопустимый hmac и найти тамперы.
function generateCredentialsCookie($user_id, $password) {
$encrypted = encrypt($user_id.':'.$password, $secretkey);
$salt = uniq_id(mt_rand(), true);
$encrypted .= ':'.hash_hmac('sha256', $encrypted, $salt);
storeSaltForUser($user_id, $salt);
set_cookie('credentials', $encrypted);
}
function readCredentialsCookie() {
$parts = explode(':', $_COOKIE['credentials']);
$salt = array_pop($parts);
$encrypted = implode(':', $parts); //needed incase mcrypt added `:`
$raw = decrypt($encrypted, $secretkey);
list ($user_id, $password) = explode(':', $raw, 2);
if ($salt == getSaltForUser($user_id))
return array($user_id, $password);
} else {
return die('Invalid Cookie Found');
}
}
Примечание - это псевдокод.Вам нужно гораздо больше, чтобы быть в безопасности (например, проверка на недопустимые значения, проверка того, что он успешно расшифровывается и т. Д.).
НЕ используйте длительные сеансы!
Выследует поддерживать истечение сеанса на минимальном уровне (обычно я использую 30-минутные сеансы, но на некоторых сайтах они ниже)Срок действия истекает после последнего использования, поэтому, пока сайт активно используется, это не имеет значения.
Что касается того, почему бы не использовать длительный сеанс, вот некоторые минусы:
DOS (отказ в обслуживании созданы уязвимости
Дисковое пространство - каждый сеанс использует достаточно небольшой объем дискового пространства. Но если у вас длительный сеанс, каждый новый сеанс только добавляет к предыдущему общему количеству. То же самое с длительными сеансамикому-то просто нужно снова и снова посещать ваш сайт с новым идентификатором сеанса, и вдруг у вас не хватает места на диске (при условии нормального диска).
Место в папке- Каждый сеанс занимает один файл в одной папке. Большинство популярных файловых систем будет замедляться с большим количеством файлов в одной папке. Поэтому, если вы поместите 1 миллион файлов сеансов, чтение или запись в файл сеанса будет медленным (очень медленным)И сборка мусора (которая очищает старые файлы) будет ОЧЕНЬ ОЧЕНЬ ОЧЕНЬ ОЧЕНЬ медленной (если она вообще будет работать).
Перехват сеанса уязвимости открыл.Это связано с тем, что чем больше сеансов вы открываете на сайте, тем легче будет угадать действительный идентификатор (благодаря атака на день рождения ).Чем меньше сеансов у вас будет, тем сложнее будет угадать действительный.
Вероятно, есть и другие, но это краткий обзор.Вместо длительных сеансов используйте подписанный токен запомнить, как описано выше.Вы будете в гораздо лучшем положении и в гораздо большей безопасности ...