Я нахожусь в середине кодирования «запомненной мной» формы входа в систему, и до сих пор учебные пособия, которые я прочитал (частично, чтобы убедиться, что я делаю это правильно), все говорят, чтобы хранить зашифрованный пароль в cookie вдоль с именем пользователя. Затем каждый раз, когда PHP проверяет, не текут ли текущий пользователь, проверьте их файлы cookie и найдите эти значения. Если имя пользователя совпадает с паролем, вы находитесь.
Для меня это зияющая дыра в безопасности. Если кто-то должен взломать базу данных или каким-то образом получить доступ к зашифрованным паролям, их даже не нужно будет взламывать. Просто установите свои собственные файлы cookie и идите. Правильно ли я, или просто параноик?
Моя система входа в систему использует сеансы для отслеживания текущего идентификатора пользователя и 1/0 для быстрой регистрации / выхода из системы. Пользователь не может редактировать сеансы AFAIK, поэтому это безопасно (если это не так, сообщите мне). Я думал просто хранить идентификатор сеанса в файле cookie, чтобы позже возобновить его, но это также небезопасно.
Я очень забочусь о безопасности своих пользователей, как я могу правильно защитить их информацию, сохраняя при этом действующий веб-сайт?
Обычно, когда серверу требуется запомнить пользователя , он выдает дополнительный файл cookie рядом с обычным файлом cookie сеанса, и эта новая строка содержит имя пользователя и разумное количество случайных символов, которые делают его неопровержимым. Это, очевидно, сохраняется в базе данных (по соображениям безопасности вы можете обращаться с ним как с паролем и, следовательно, с солью и хешем), и в следующий раз, когда пользователь подключится к тому же браузеру (при условии, что старый сеанс истек), приложение получает случайная строка, проверяет базу данных, и если есть соответствие, пользователь аутентифицируется.
Альтернативой является перемещение времени окончания сеанса перед некоторой суммой.
Какие здесь дыры в безопасности? Если вы используете хороший случайный генератор, единственное, что может случиться, это то, что пользователь обращается к приложению из общего браузера и вручную не выходит из системы, когда он заканчивается.
Обычные правила всегда применяются, так как вы находитесь на небезопасном канале: используйте HTTPS, иначе любой, кто находится между вашим компьютером и сервером, может украсть файлы cookie (либо сеансовый, либо один-на – один) и действовать так, как если бы вы были.
Бонус, это должно быть прочитано Джеффом Этвудом
Никогда не сохраняйте пароли каким-либо образом (зашифрованный пароль, который может использоваться для входа в систему, по-прежнему является паролем) на клиенте.
Используйте случайно сгенерированный ключ, безопасно сохраненный на сервере. Эти ключи можно отменить позже, в отличие от зашифрованных паролей, которые будут действительны до изменения.
Используя php, вы можете генерировать случайный ключ, подобный этому md5(uniqid(mt_rand(), true)) . Для лучшего хранения безопасности он солен и хэширован в дБ.
Пример таблицы:
login_keys ( user_id int, key char(40), # sha1 salt char(15) )
Также обратите внимание, что вы должны включить опцию cookie только для HTTP .
Если вы хотите, чтобы это было безопасно, не позволяйте своим пользователям держать их в системе.
При настройке сеанса обязательно привязывайте ipaddress к идентификатору сеанса, так что, если кто-то заберет сеанс позже, это может быть сделано только с одного и того же адреса Ip. Yo может сделать это, сохранив базу данных с (хэшированной) сессией ids + hashed ipaddresses. Я использую функцию phps http://php.net/manual/en/class.sessionhandler.php, чтобы установить обработчик сеанса и сопоставить сеансы с ipaddresses.
Я столкнулся с этой же проблемой при работе на моем собственном веб-сайте, лучшим способом, который я нашел для решения, было просто не запоминать пароли, а только имена пользователей, обеспечивая более быстрый журнал, но не менее безопасный. Дело в том, что нет надежного способа защиты паролей. Кроме того, в новых браузерах пользователь может запомнить их браузер.
Но если у вас должен быть сохраненный пароль, попробуйте следующее:
У вас есть несколько файлов cookie, 2 – самый простой и использовать один для зашифрованного пароля, а другой – ключ шифрования. Пароль в базе данных будет содержать еще один зашифрованный пароль, полученный с помощью сохраненного ключа (ов) шифрования. Когда вы будете готовы проверить пароль, извлеките значения и зашифруйте пароль.
Надеюсь, это было полезно. Удачи!
Изменить: Возможно, я неправильно понял это, если пользователь все еще зарегистрирован, рекомендуется хранить переменную сеанса.