Лучшие практики для веб-входа в систему / аутентификация?
5 ответов
Шифрование
Вчера был вопрос об этом - « Почему я все равно должен заботиться о хешировании паролей? », который охватывает все причины, почему вы должны сделать этот.
Капча
Я не согласен с Рикардо в отношении точки каптчи - всегда требую капчу, даже спамеры нацеливаются даже на непопулярные сайты. У меня есть блоги, которые я настроил для тестирования некоторых фрагментов кода, на которые я никогда не ссылался нигде, которые были чудесным образом найдены спамерами. Когда спамер наводнит ваш сайт миллионами одинаковых постов о виагре, вы пожалеете, что не потратили лишних 20 минут на установку капчи. reCaptcha имеет несколько плагинов , которые делают его установку довольно простой, и вы можете помочь им оцифровать книги.
Не забывайте, что пользователям с ослабленным зрением понадобится звуковая капча.
Забыли пароль
Если вы подтвердили адрес электронной почты пользователя, вы можете просто сгенерировать случайный новый пароль для него. Обязательно попросите их немедленно сменить пароль, так как люди сразу забудут случайно сгенерированные пароли.
Электронные письма
Не пытайтесь реализовать сложные регулярные выражения, которые охватывают все возможные адреса электронной почты. Выполните простую проверку на наличие символа @, а затем разрешите пользователю щелкнуть ссылку, отправленную на его адрес электронной почты, для подтверждения. Это обычная практика в наши дни, но я все еще сталкиваюсь с людьми, пытающимися быть «умными» в этом.
Проверка формы
Наряду с проверкой на стороне сервера в форме регистрации у вас должна быть проверка на стороне клиента в форме AJAX, чтобы пользователь знал, как он повторное заполнение, выбрано ли выбранное им имя пользователя, приемлем ли их пароль и т. д. Пользователи могут быть разочарованы необходимостью повторной отправки регистрационных форм несколько раз.
Сама аутентификация
Приятно позволить людям входить в систему либо под своим именем пользователя, либо по адресу электронной почты, поскольку люди с большей вероятностью запоминают адреса электронной почты, чем имена пользователей, особенно если они давно не был на вашем сайте.
Если ваш сайт нуждается в дополнительной безопасности (например, если вы продаете вещи, и люди могут получить их, просто войдя в систему), запросите другую часть информации. Запрашивать у них почтовый индекс - хорошая идея, так как ввод текста занимает всего несколько дополнительных секунд и значительно усложняет взлом паролей.
Относительно имени пользователя, это зависит от того, как имя пользователя будет использоваться на сайте (помимо входа в систему). Если ваш сайт основан на контенте, созданном пользователем, и вы отображаете имя пользователя вместе с контентом, дайте пользователю возможность выбрать свое собственное и убедитесь, что это не адрес электронной почты. Кроме того, если имя пользователя будет отображаться, я обычно предоставляю немного предупреждения в форме регистрации, чтобы сообщить пользователю, чтобы они не использовали свое полное имя только для того, чтобы сердиться позже, когда оно отображается на сайте.
Я бы порекомендовал проверить доступность и действительность имени пользователя через какой-либо тип вызова Ajax, пока пользователь находится в форме. Повторная загрузка формы с пропущенным паролем и подтверждением пароля - просто придумать новое имя пользователя и повторно ввести данные - это боль.
Другие вещи, которые следует учесть, - это установить минимальную / максимальную длину и некоторые правила для паролей ... хотя не усложняйте регистрацию. Также примите специальные символы в пароле. У меня есть пара очень надежных паролей, которые я люблю использовать, и многие сайты не позволяют мне их использовать, поэтому моя учетная запись оказывается менее безопасной, чем я бы сделала сама.
CAPTCHA - хорошая идея, просто убедитесь, что это не очень сложно понять, это тоже может расстраивать.
Есть много вещей для рассмотрения и несколько вариантов для каждого, но, надеюсь, это поможет вам начать.
Пожалуйста, также убедитесь, что ваша страница входа защищена с помощью SSL. Если вы этого не сделаете, то имя пользователя и пароль в любом случае будут отправлены через Интернет в виде открытого текста. Остальная часть вашего сайта не нуждается в защите с помощью SSL, если нигде нет конфиденциальной информации.
Я бы сказал, что вы используете многие из общедоступных API социальных сетей, чтобы выполнить работу за вас. При этом вы сможете полностью избавить свою страницу от множества недостатков безопасности с точки зрения входа в систему и аутентификации пользователя (считывание паролей и пользовательских данных) и передать ее в стабильные руки указанных социальных сетей.
И так как весь процесс может быть завершен нажатием одной кнопки, это также делает ваш UX лучше и может быть плавно интегрирован в ваш интерфейс.
Некоторыми примерами таких API могут быть Facebook, Google, LinkedIn, Twitter, Dribbble. Выберите свою в соответствии с вашим представлением о базе пользователей, на которую вы будете ориентироваться.
Кроме того, в моем недавнем опыте инфраструктура hello.js делает эту задачу довольно простой.
MSDN опубликовал статью, которая затрагивает некоторые из этих проблем; копия доступна здесь здесь . Большинство предложений отражают идеи здесь; Еще одна идея этой статьи - «отслеживать трафик через вашу регистрационную воронку». Отслеживайте попадания в области ошибок, предупреждений и восстановления системы, чтобы узнать, нужно ли вам внести некоторые улучшения в удобство использования.