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

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

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

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

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

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

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

Для большинства известных мне авто-логинов есть отдельная таблица для хранения авторизованных сессий. Каждому сеансу автоматического входа в систему в качестве идентификатора назначается хешированный ключ, ключ довольно длинный и его практически невозможно подделать. Если вы не хотите, чтобы пользователи входили в систему кросс-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 пользователя при входе в систему. Затем сохраните это в базе данных:

function save_ident($identFromFunctionAbove,$authenticated_user_id){
    //hash this with something unique to the user's 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 или идентификаторов. Тем не менее, получение двух 32-символьных случайных сгенерированных строк, которые будут такими же, как и ранее сгенерированная, является довольно незначительным шансом.

То, как я делал это ранее, заключается в хранении MD5-хэша пароля, а не фактического пароля.

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

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

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

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