2010-01-02 2 views
0

хранящую пользователя & пароль пользователя в куки хорошая практика? Я действительно хочу знать, как большие веб-сайты (Facebook, digg, twitter) справляются с этим. Мой код так:Безопасный Вход для зарегистрированных пользователей Использование Cookies

<?php 

$username = mysql_real_escape_string($_POST['username']); 
$password = md5($_POST['password']); 

?> 

После каждого успешного входа в систему я хранить $username и $password (md5) в куки. И регенерировать идентификатор сессии с session_regenerate_id()


И для аутентификации пользователя я проверить, если Войти сеанс существует, в противном случае я аутентифицировать печенье.

Любые идеи? Спасибо

ответ

2

Я немного смущен - вы используете PHP-сессии или файлы cookie?

Если вы храните данные в сеансе ($_SESSION['username'] = 'Tom' и т. Д.), Эти данные не сохраняются в пользовательском cookie.

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

autologins 
---------- 
key (random hash) 
user_id 
expires 
+0

Я аутентифицирую файл cookie, а затем задаю сеанс. Если сеанс уже установлен, я использую его напрямую. Идея вашего автолога хорошая. Благодарю. – MoeAmine

0

Просто md5 недостаточно, вы должны хотя бы включить случайную «соль» (небольшую случайную строку символов), которую вы храните в своей базе данных.

Редактировать: Btw, вы сохранили пароль обычного текста или зашифрованы? Это может быть большим риском для безопасности.

+0

Хорошо, у меня есть идея соления. Но достаточно ли его хранить в печенье? – MoeAmine

+0

Сохраняется только в MD5. но я собираюсь изменить эту стратегию. – MoeAmine

0

Стандартная практика заключается в предоставлении пользователю идентификатора сеанса в файле cookie либо самостоятельно, либо с использованием сеансов PHP. Хранение хэша имени пользователя и пароля в файле cookie по-прежнему выполняется на некоторых сайтах, но я предпочитаю первый. Это позволяет вам больше контролировать своих пользователей, чтобы они могли видеть, сколько сеансов у них есть и какой из них они, например, - см. GMail для хорошего примера.

Что касается солей и хеширования, вы должны хранить хэши паролей в базе данных, соленые. В идеале соль должна быть разной для каждого пользователя. В случае, если ваша база данных будет украдена или выставлена, это сделает LOT более трудным для злоумышленника для получения паролей (если все они используют ту же соль, они могут генерировать таблицы радуги для этой соли, что занимает много времени, но позволит они быстро перерывают пароли). Для безопасности соль также должна содержать некоторые не буквенно-цифровые символы, например% $ & ^.

+0

У меня нет каких-либо предпосылок о том, чтобы иметь дело с идентификатором sesion в файлах cookie, но проект, над которым я работаю, не требует, чтобы он предоставлял пользователю их ip, сеансы и т. Д., Как вы сказали. Спасибо за объяснение стратегии соления. – MoeAmine

0

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

Например, используйте хэш IP-адреса пользователя и соль, обеспечивает дополнительную защиту от того, кто крадет или обнюхивает cookie безопасности пользователя.

Я подозреваю, что TWitter использует что-то вроде этого, поэтому вы можете быть только навсегда войти в Twitter с одного компьютера за раз.

Смежные вопросы