Лучшие практики для входа в систему / аутентификации? - PullRequest
23 голосов
/ 14 ноября 2008

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

Какие еще полезные советы или требования предъявляются к пользовательской части сайта? Например, должны ли имена пользователей выбираться пользователем или они должны быть адресами электронной почты? Есть подводные камни для регистрации пользователя? (CAPTCHA, вероятно, сами по себе стоят целой темы.) Есть ли подводные камни для части сброса пароля? Что-нибудь еще?

Edit:

Здесь несколько повторяется: страницы с рекомендациями для входа в систему

Ответы [ 5 ]

20 голосов
/ 14 ноября 2008

Шифрование

Вчера был вопрос об этом - " Почему я все равно должен заботиться о хешировании паролей? ", который охватывает все причины, почему вы должны это сделать.

Защитный код

Я не согласен с Рикардо в отношении точки, обозначенной капчей - всегда требуются капчи, даже спопмеры получают даже очень непопулярные сайты. У меня есть блоги, которые я настроил для тестирования некоторых фрагментов кода, на которые я никогда не ссылался нигде, которые были чудесным образом найдены спамерами. Когда спамер наводнит ваш сайт миллионами одинаковых постов о виагре, вы пожалеете, что не потратили лишних 20 минут на установку капчи. reCaptcha имеет несколько плагинов , которые значительно упрощают его установку, и вы можете помочь им оцифровать книги.

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

Забыли пароль

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

Письма

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

Проверка формы

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

Сама аутентификация

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

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

3 голосов
/ 14 ноября 2008

В теме имени пользователя это зависит от того, как имя пользователя будет использоваться на сайте (помимо входа в систему). Если ваш сайт основан на контенте, созданном пользователем, и вы отображаете имя пользователя вместе с контентом, дайте пользователю возможность выбрать свое собственное и убедитесь, что это не адрес электронной почты. Кроме того, если имя пользователя будет отображаться, я обычно предоставляю небольшое предупреждение в форме регистрации, чтобы сообщить пользователю, чтобы они не использовали свое полное имя только для того, чтобы сердиться позже, когда оно отображается на сайте. 1001 *

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

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

CAPTCHA - хорошая идея, просто убедитесь, что это не сложно определить, это тоже может расстраивать.

Есть много вещей, которые нужно рассмотреть, и несколько вариантов для каждого, но, надеюсь, это поможет вам начать.

2 голосов
/ 31 октября 2016

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

И так как весь процесс может быть завершен одним щелчком мыши Кнопка, он также делает ваш UX лучше и может быть плавно интегрирован в ваш пользовательский интерфейс.

Примерами таких API могут быть Facebook, Google, LinkedIn, Twitter, Dribbble. Выберите свою в соответствии с вашим представлением о базе пользователей, на которую вы будете ориентироваться.

Кроме того, по моему недавнему опыту, hello.js framework делает это задача довольно простая.

2 голосов
/ 14 ноября 2008

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

0 голосов
/ 18 ноября 2008

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...