Разработка безопасной системы cookie для автозапуска в PHP

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

Теперь вопрос в том, как я могу защитить его, поэтому cookie не может быть подделан/изменен.

Один из моих друзей предлагает иметь таблицу db, которая хранит session_id, пользовательский ip, информацию обозревателя и т.д., а затем сравнивает всю эту информацию после того, как пользователь снова появится на веб-сайте.

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

ОТВЕТЫ

Ответ 1

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

Вы должны принимать этот файл cookie только с https, если хотите быть максимально безопасным. Если cookie принимается через http, его можно обнюхать и украсть.

Я бы порекомендовал, чтобы файл cookie не имел пользовательских данных (маркер, как вы сказали). Это, к сожалению, потребует другой таблицы. Когда пользователь входит в систему и выбирает "продолжать вход в систему", создайте запись в этой таблице. Запись может быть любым бессмысленным значением (например, md5(uniqid('', true));. Этот токен может быть уникальным в БД и сопоставлен с идентификатором пользователя.

Когда пользователь посещает ваш сайт, вы можете проверить значение этого файла cookie и получить принадлежащего ему пользователя и войти в систему. В этот момент вы уничтожаете старый токен и создаете новый. "Уничтожить" может означать много вещей. Вы можете полностью удалить его из базы данных или иметь флаг, который отключает токен. Возможно, вы захотите, чтобы один и тот же токен использовался несколько раз в случае получения cookie, но по какой-то причине аутентификация не проходит, но я думаю, что это небезопасно. Вы также можете сохранить временную метку токена и принять его только в течение ограниченного периода времени (например, 30 дней).

Как указывает ваш друг, вы можете хранить другую информацию, такую ​​как пользовательский агент, IP-адрес и т.д., но это может измениться даже при использовании того же браузера (особенно с мобильным телефоном), и если пользовательский постоянный логин не принят из-за этого он может быть неудобным и неудобным для них.

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

Ответ 2

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

function gen_uniqueIdent($length=32){
    $alphabet = str_split('abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ123456789');
    $key = '';
    for($loop=0;$loop<$length;$loop++){
        $i = mt_rand(0,count($alphabet)-1);
        $key.= $alphabet[$i];
    }
    return $key;
}

Назначьте это значение в файл cookie пользователя при входе в систему. Затем сохраните это в db:

function save_ident($identFromFunctionAbove,$authenticated_user_id){
    //hash this with something unique to the user machine
    $hashed = md5($identFromFunctionAbove . $_SERVER['REMOTE_ADDR']);
    /** Some actions to remember this hash **/
}

сохранить это в базу данных, соответствующую идентичности пользователя, например user_id.

Теперь после проверки cookie пользователя вы можете просто:

function validateCookie(){
    $ident = $_COOKIE['yourCookieName'];
    $hashed = md5($ident . $_SERVER['REMOTE_ADDR']);
    /** Check if this hashed value exists in db, if it does, authenticate user **/
}

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

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

Ответ 3

Как я уже делал это, это сохранение хеша MD5 пароля, а не фактического пароля.

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

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

Вы можете сделать это более безопасным, заставив файл cookie истекать через x дней, поэтому, если cookie украден, theif может получить доступ только за этот период.

В конце дня больше всего и только? безопасный метод - каждый раз вводить имя пользователя