Есть ли что-нибудь более сложное и увлекательное чем регистрация и авторизация? У меня уже накопилась целая подборка: «Основные ошибки проектирования процесса авторизации», «Пользователь важен для вас? Просто дайте ему зарегистрироваться», «Комментарии open_id, улучшены». Что ж, сегодня я намерена продолжить эту тему.

Пароль должен сохраняться в браузере

Всегда важно предоставлять вашим пользователям пользоваться автоматическим сохранением пароля в браузере. На десктопах это позволяет сэкономить несколько секунд, а на мобильниках несколько минут. Попробуйте например набрать несколько раз пальцем на тачскрине логин типа askme@usabili.ru и пароль типа ">pf,bkbnbvj,bkmybrjd-pkj". Поэтому это очень важный момент. К сохранению в браузере я отношу и плагины менеджеров паролей, типа roboform.

Форма логина должна проверяться без перезагрузки

Когда вы ошибаетесь в наборе логина и пароля — очень раздражает, если каждый раз вам приходится загружать новую страницу на которой написано только то что вы ошиблись, или использовали недопустимый символ. Поэтому логично делать проверку авторизации аяксом, вида form onsubmit="somecheck();return false;".

В самой функции somecheck() делается ajax запрос, проверяется результат, и, в случае успеха, делается редирект в закрытый раздел через self.location="/some".

Пару месяцев назад, мы с коллегами столкнулись с досадным багом в хроме. Хром не предлагает сохранить пароль если onsubmit формы возвращает false. Баг с ноября 2009, уже полгода имеет статус fixed, хотя работает до сих пор. Примеры тут: простой и сложный. В сложном примере на секунду появляется таки запрос сохранения, но тут же пропадает. В dev-версии хрома (18) сложный пример работает как надо.

Решением было обнулять функцию сабмита формы, а затем сабмитить её. Разумеется при этом action формы должен вести куда надо.

document.getElementById('login_form').onsubmit=function(){return true;};
document.getElementById('login_form').submit();

Конечная страница не должна получать лишних POST параметров

 Дело в том, что когда страница содержит данные, переданные методом POST, то при обновлении страницы (например нажав F5) браузер сначала спросит хотите ли вы отправить данные ещё раз. Это ненужный пользователю вопрос. Чтобы этого избежать нужно не сразу посылать пользователя на конечную страницу, а посылать на другую, которая сделает редирект на нужную. В таком случае не будет лишних POST параметров. Пример можно увидеть в действии при авторизации в этом блоге.

Пароль должен быть по-желанию открыт пользователю

Единственной вообще причиной почему нужно маскировать пароли на сайтах — это в том что всякие звёздочки пошли из нативных приложений операционных систем. А те пошли от экранов авторизаций тех времён когда персональные компьютеры были не очень персональными, и чтобы стоящий рядом не подглядывал пароль — звёздочки очень полезны. Кстати многие пользователи верили что звёздочки защитят их пароли от вирусов, троянов и кейлоггеров, многие до сих пор верят.

Якоб Нильсен — один из известнейших юзабилистов в мире, с 1995 года писал о безопасности паролей и человеческом факторе (Human Factors of Password Security), и в 2000 писал (Security & Human Factors), и в 2009 писал (Stop Password Masking). Много всего хорошего о паролях, и в частности о том, что звёздочки у паролей пользователям-то не нужны. Но почему-то никто не воплощает его слова в реальность. Даже в мобильных (!!!) браузерах нет настройки "показать мне все мои пароли", это искренне бесит. А ведь на многих сайтах для регистрации просят "подтвердить пароль" (пожалуйста, не менее 6 символов, используйте цифры и буквы разного регистра) — господи дай этим людям мозгов. В большинстве настроек андроида пароли тоже скрываются, хотя казалось бы...

It's time to show most passwords in clear text as users type them. Providing feedback and visualizing the system's status have always been among the most basic usability principles. Showing undifferentiated bullets while users enter complex codes definitely fails to comply.

Most websites (and many other applications) mask passwords as users type them, and thereby theoretically prevent miscreants from looking over users' shoulders. Of course, a truly skilled criminal can simply look at the keyboard and note which keys are being pressed. So, password masking doesn't even protect fully against snoopers.

More importantly, there's usually nobody looking over your shoulder when you log in to a website. It's just you, sitting all alone in your office, suffering reduced usability to protect against a non-issue.

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

Итак, что тянуть резину, давайте сделаем это! Вот какой концепт получился у меня — http://usabili.ru/labs/browser_bugs/test_visible_passwd.html. Это кроссбраузерная (Chrome, Opera, Firefox) реализация незамаскированного пароля. Важно именно то, что браузер здесь запоминает пароль, хотя пароль может вводиться открытым текстом. Для того чтобы любой браузер вообще предлагал сохранять пароль — необходимо чтобы пароль был полем type="password", при загрузке страницы.

Просто так менять яваскриптом тип поля ввода — нельзя. Чтобы поменять его — необходимо пересоздать весь элемент. Для этого воспользуемся такой функцией:

function changeInputType(oldObject, oType) {
	var newObject = document.createElement('input');
	newObject.type = oType;
	if(oldObject.size) newObject.size = oldObject.size;
	if(oldObject.value) newObject.value = oldObject.value;
	if(oldObject.name) newObject.name = oldObject.name;
	if(oldObject.id) newObject.id = oldObject.id;
	if(oldObject.tabIndex) newObject.tabIndex = oldObject.tabIndex;
	if(oldObject.placeholder) newObject.placeholder = oldObject.placeholder;
	if(oldObject.className) newObject.className = oldObject.className;
	oldObject.parentNode.replaceChild(newObject,oldObject);
	return newObject;
}

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

Однако есть одна особенность. В файрфоксе и опере — вызов .submit() формы — не вызовет диалог сохранения пароля. Однако этот диалог — вызывается если кликнуть по кнопке сабмита данной формы вызвав .click();. Таким образом, для кроссбраузерной реализации, перед сабмитом формы — мы должны кликнуть по кнопке сабмита. Общий алгоритм в вашей аякс-проверке должнен получиться примерно такой:

if(auth_success) {
	changeInputType(document.getElementById('password'), 'password');
	document.getElementById('login_form').onsubmit=function(){return true;};
	document.getElementById('login_button').click();
	document.getElementById('login_form').submit();
	return true;
}

Кнопку переключения маскировки можно оформить иконками, как это предложено Лебедевым. Например так:

Так же проставить полям атрибуты tabindex и placeholder.

На тему споров о целесообразности открытого пароля можно почитать следующие статьи:

• Stop Password Masking (Jakob Nielsen's Alertbox)
• Schneier on Security: The Problem with Password Masking
• Schneier on Security: The Pros and Cons of Password Masking
• Is usability worth more than security?
• Keep an eye on your iPhone | Naked Security
• Usability and security gurus agree that masked passwords should go
• Security guru says he was 'probably wrong' to attack masked passwords
• Password Masking – a Necessary Evil » CounterMeasures
• Apparently we should no longer blank passwords when entered on websites. Thoughts? | Security Active Blog
• about face on bruce schneier | Jahne - Virus and Spyware Removal
• The websecurity June 2009 Archive by thread

А что думаете вы?