Критикуйте мои усилия по аутентификации PHP

Короткий ответ: хорошие взгляды!

Длинный ответ:

1. Да, необходимо позволить более сильные/длиннее пароли, но иначе это в порядке. Просто удостоверьтесь, что Вы принимаете только допустимые символы части URL (я придерживался бы словесных символов PCRE) для названия сайта. Однако "проверяют эту электронную почту" система, было бы соответствующим, чтобы удостовериться, что лицо, получившее патент на самом деле управляет введенным адресом электронной почты.
2. Хорошие взгляды. Мне нравится sha1 лучше, чем md5, все же.
3. Пока Ваши сессии безопасны, можно сохранить больше, чем просто имя пользователя (который был бы довольно дорогим поиском к SQL для каждого запроса страницы - идут вперед и хранят их PK).
4. Хорошие взгляды, но должны быть скорректированы на мои комментарии в № 3

Для проверки Вы обрабатываете свою безопасность сессии правильно, проверяете руководство по PHPSec.

1. Почему 6 символов? Сделайте это больше и потребуйте минимума 6 (или больше) символы. Нет никакого оправдания за ограничение количества символов в пароле к 6.

2. Помещенные больше, чем имя пользователя на сессии. Но сделать это безопасно, необходимо изменить соль каждый вход в систему:

A-От страницы входа в систему: Возьмите имя и пароль, проверяют с существующей солью. Если допустимое обновление пользовательская столовая соль и пароль с новой солью (у Вас есть пароль от пользователя, таким образом, Вы можете md5 это и соль снова). Запишите md5 пароля к сессии. B-От любой другой страницы: сравните пользователя и хешированный пароль против базы данных. Если они не соответствуют, перенаправьте к странице входа в систему.

Дефект с этой идеей является пользователем, не может поддержать логины на нескольких машинах/браузерах.

Вашей системе регистрации нужна работа к. Как Вы знаете, что адрес электронной почты допустим? Как Вы знаете, что пользователь, регистрирующийся, владеет адресом электронной почты? Необходимо послать электронное письмо адресу, содержащему ссылку назад на сайт, который должен быть нажат перед разрешением доступа к счету чему-либо. Иначе кто-то может подписаться под чужим адресом электронной почты, предъявляют мошеннические претензии как того человека или правое дело Ваш сайт для спама того человека, получающего закрытие сайта.

Вы также могли бы хотеть исследовать КАПЧУ для ограничения заданной сценарием регистрации.

• Ограничьте скорость на логинах. Зарегистрируйте каждую попытку для пользователя и заблокируйте их после такого количества неудачных попыток. Поскольку неудачные попытки возрастают, делают блокировку дольше и дольше.

• Добавьте соль в своем коде, который статичен, и используйте его в сочетании с солью от базы данных. Затем, если у Вас, дб взламывается, они все еще, нет соли из кода. Эта соль не может / не должен изменяться.

• Пользователи могут получить пароли / локауты сброса? необходимо будет собрать контрольные вопросы и ответы.

• Когда пользователи изменяют свои пароли, они должны знать исходный?

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

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

Безопасность через мрак является немой, но много уровней безопасности могут помочь.

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

Можно даже повторно создать то соленое значение каждые X страницы представления и хранилище на сессии, чтобы истечь он и сделать кражу им менее полезный со временем. Вы затем сохранили бы два солей в своей базе данных. Один для пароля, один для значения сеанса аутентификации.

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

Если кто-либо следит за представлением формы регистрации затем, у них есть информация, Вы обеспокоены, что они выяснят. Первый шаг: Используйте HTTPS для своих форм.

Что касается зашифрованного материала дб, я позволю кому-то еще не согласиться с ним.:-)

Меня беспокоит, может ли кто-то написать в сеанс и, таким образом, получить доступ к страницам людей, если они знают имя пользователя, с которым они зарегистрировались? Как бы вы предотвратили это?

Я не понимаю, что вы имеете в виду. Как бы кто-нибудь «написал на сеанс»? Сеанс [обычно] представляет собой файл, хранящийся на сервере, который клиент не может просматривать или изменять.

Если вас беспокоит захват сеанса (он же фиксация), вам необходимо включить SSL и отключить идентификаторы сеанса в строке URL. (См. session.use_only_cookies в php.ini)

4 - При каждом запросе я использую имя пользователя, сохраненное в сеансе, для запроса базы данных и чтения имени сайта, связанного с этим пользователем. Затем я сравниваю это с именем сайта в самом URL-адресе, и, если они совпадают, я устанавливаю переменную, доступную для остальной части или сценария (не глобальная переменная, она просто читается моим контроллером, который решает, может ли пользователь видеть конкретная страница), если два имени сайта не совпадают, пользователь перенаправляется обратно на страницу входа в систему

Это звучит как самая большая проблема. Как выглядит название сайта? Как именно вы сопоставляете его с URL-адресом? С регулярным выражением?

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