Я хочу, чтобы у вас была опция автоматического входа в систему. В основном это означает, что cookie будет храниться на стороне клиента.
Теперь вопрос в том, как я могу его защитить, поэтому cookie не может быть подделан / изменен.
Один из моих друзей предлагает иметь таблицу db, которая хранит session_id, IP-адрес пользователя, информацию обозревателя и т. Д., А затем сравнивает всю эту информацию после повторного перехода пользователя на сайт.
Мне кажется, что у меня есть отдельная таблица, и это слишком много неприятностей. Есть ли другой способ сделать это? Может быть, с жетонами или что-то в этом роде?
Чем безопаснее вы хотите этот печально известный файл cookie, тем больше проблем вы будете делать. Если ваши пользователи должны быть особенно безопасными, вам придется пойти с самым трудным подходом.
Вы должны принимать этот файл cookie только с https, если хотите быть как можно более безопасным. Если cookie принимается через http, его можно обнюхать и украсть.
Я бы рекомендовал, чтобы файл cookie не имел пользовательских данных (маркер, как вы сказали). Это, к сожалению, потребует другой таблицы. Когда пользователь входит в систему и выбирает «продолжать вход в систему», создайте запись в этой таблице. Запись может быть любым бессмысленным значением (например, md5(uniqid('', true)); . Этот токен может быть уникальным в БД и сопоставлен с идентификатором пользователя.
Когда пользователь посещает ваш сайт, вы можете проверить значение этого файла cookie и получить принадлежащего ему пользователя и войти в систему. В этот момент вы уничтожаете старый токен и создаете новый. «Уничтожить» может означать много вещей. Вы можете полностью удалить его из базы данных или иметь флаг, который отключает токен. Возможно, вы захотите, чтобы один и тот же токен использовался несколько раз в случае получения cookie, но по какой-то причине аутентификация не проходит, но я думаю, что это небезопасно. Вы также можете сохранить временную метку токена и только принять его, если это был ограниченный период времени (например, 30 дней).
Как указывает ваш друг, вы можете хранить другую информацию, такую как пользовательский агент, IP-адрес и т. Д., Но это может измениться даже при использовании того же браузера (особенно с мобильным телефоном), и если постоянный вход пользователя не принят из-за этого , это может быть затруднительным и неудобным для них.
Если вы действительно не хотите создавать другую таблицу, вам придется сохранить способ получения идентификатора пользователя из значения cookie. Это менее безопасно.
Для большинства автоматических логинов, которые я знаю, есть отдельная таблица для хранения сеансов в режиме входа. Каждому сеансу автоматической регистрации назначается хешированный ключ в качестве идентификатора, ключ значительно длинный и практически невозможно подделать. Если вы не хотите, чтобы пользователи регистрировались в 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; }
Привяжите это значение к файлу пользователя при входе в систему. Затем сохраните это в db:
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 или ident. Тем не менее, получение двух 32-символьных случайных сгенерированных строк должно быть таким же, как и ранее созданное, является довольно тонким шансом.
То, как я это делал ранее, это хранить хеш MD5 пароля, а не фактический пароль.
На стороне сервера вам нужно проверить, поступает ли логин из файла cookie, а затем проверить, совпадает ли этот хэш с паролем в вашей базе данных после его удаления через MD5
Таким образом, если кто-то взломает компьютер пользователя, он никогда не сможет узнать значение пароля, однако он все равно сможет использовать этот файл cookie для аутентификации только на вашем сервере.
Вы можете сделать это более безопасным, заставив файл cookie истекать через x дней, поэтому, если cookie украден, theif может получить доступ только за этот период.
В конце дня больше всего? безопасный метод – каждый раз вводить имя пользователя