как реализовать систему входа в систему для веб-приложений?
Я пишу систему входа в систему для веб-сайта, который я создаю.
Вот сущность того, как я реализую систему входа в систему:
У меня есть две таблицы: пользователи и сессии.
users: uid | uname | pass
sessions: sid | uid | ts | ts_expires
Таким образом, пользователь вводит uname/pass комбинацию.
- если комбинация является неправильной, я перенаправляю к "плохой подлинной" странице.
- если комбинация корректна, я:
- генерируйте случайный sessionid (
sid) - вставьте запись в
sessionsпри соединении этого предоставляется sid с uid имени пользователя. - установите названный cookie
sidсо значением случайногоsidпросто вставленный вsessions.
- генерируйте случайный sessionid (
На каждой странице, которой нужен пользователь для входа в систему, я проверяю:
- установлен ли cookie
- если sid допустим
Таким образом, мои вопросы:
- Каковы могли быть потенциальные проблемы с этим механизмом?
- Как польза должна войти в систему быть реализованной?
PS: Я еще не использую защищенный вход в систему SSL. Таким образом, это - единственная проблема, которую я определяю на данный момент. И о, я использую php и mysql, если это релевантно.
Править: Я храню пароли не в простом тексте, но как MD5 имени пользователя, связанного с паролем.
Так, pass = MD5($uname.$pass),так сказать.
4 ответа
] Хэш этот пароль, с солью! Используйте сильный хэш, как на крипте. Если вам нужно использовать MD5/SHA, используйте технику, которая называется растягивание и хэш - это хэши несколько тысяч раз. Пользователю будет все равно, если проверка пароля займет секунду вместо 1/1000, но взломщик грубой силы будет.[
] []Записывать попытки и предотвращать попытки грубой силы.[
] []Будьте очень осторожны с тем, где вы храните учетные данные пользователя, как только он войдет в систему. Вы не хотите, чтобы они его меняли.[
] []И используйте SSL![
].] Обычно хорошая практика - хранить пароль в виде соленого одностороннего хэша фактического пароля, а не в виде чистого текста. Вы не указали, делаете вы это или нет, но если нет, то делайте это.[
] []Убедитесь, что у входа есть период таймаута, чтобы он не длился вечно.[
] []Убедитесь, что при выходе из системы куки-файл удален.[
] []Не забывайте, что пользователь может входить в систему с общедоступного компьютера, а сохранение учетных данных в куки-файле может привести к тому, что последующий пользователь получит доступ через брошенный сеанс.[
].Чтобы замедлить атаку грубой силы, вставьте принудительную задержку после неудачной попытки; то есть, если кто-то выдает вам неправильный пароль, подождите три секунды, прежде чем вывести на экран следующий экран с надписью "password failed" (пароль не удался).
Проектирование и реализация безопасной, надежной, удобной системы входа в систему на самом деле довольно сложно осуществить с первой попытки. Страницы на страницах были написаны на эту тему - слишком обширные, чтобы их можно было правильно обработать, здесь.
Хорошей отправной точкой является www.owasp.org. Тогда привлеките кого-нибудь, с кем вы работаете, кто разбирается в безопасности, заключите контракт с охранной компанией (например, www.matasano.com, veracode.com или neohapsis.com - я работал со всеми тремя, и все три очень хороши), и/или задавайте вопросы в списках рассылки по безопасности (например, в списке безопасности веб-приложений, который находится на securityfocus.com).