Пожалуйста, оцените мои попытки аутентификации PHP

Question

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

Логический поток:

1 - Пользователь регистрируется с использованием электронной почты в качестве имени пользователя, «имени сайта», которое затем образует часть любого URL-адреса, к которому он будет иметь доступ, и пароля длиной не менее 6 символов, который должен содержать буквы и цифры (я знаю, это может быть сильнее)

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

3 - Когда пользователь входит в систему, я беру пароль, который он ввел, и соединяю его с солью, создаю хэш md5 и сравниваю его с тем, что я сохранил в базе данных - если они совпадают, пользователь ввел правильный пароль, и его имя пользователя записано в сеансе

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

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

Прежде чем кто-либо обвинит меня в халатности, кстати, это личный проект для обучения - я не раскрываю данные клиентов!

Answer 1

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

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

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

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

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

Вы также можете изучить CAPTCHA для ограничения регистрации по сценарию.

Answer 2

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

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

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

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

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

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

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

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

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

Answer 5

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

Что касается зашифрованных БД, я позволю кому-то еще с этим справиться. : -)

Answer 6

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