С точки зрения пользователя процесс идентификации и аутентификации выглядит довольно просто — ввел данные, нажал на кнопку. Но аналитику нужно учитывать множество подводных камней при формулировании требований к этим задачам. В этой статье мы расскажем о минимальных требованиях к парольной аутентификации с точки зрения передачи и хранения пароля для обеспечения безопасности данных. А также о требованиях к самой форме аутентификации с целью формирования положительного пользовательского опыта. Материал будет полезен бизнес- и системным аналитикам.

Формирование требований к идентификации

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

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

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

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

Также стоит использовать электронный адрес или номер телефона для передачи одноразовой ссылки для завершения регистрации.

Формирование требований к аутентификации

Аутентификация — это проверка подлинности предъявленного пользователем идентификатора.

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

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

Факторы аутентификации

1. Фактор знания

Это то, что знает конкретный человек — пароль или PIN-код. В информационных системах обычно используется в паре с логином, идентифицирующим конкретного пользователя.

2. Фактор обладания

Это некий материальный объект, которым обладает конкретный человек — аппаратный токен, смарт-карта или карта доступа. В информационных системах чаще всего служит для многофакторной аутентификации совместно с фактором знания. Например, операции в банкомате, когда фактором обладания является банковская карта, а фактором знания — PIN-код. Или при двухфакторной (двухэтапной) аутентификации на ресурсе, когда после ввода пароля необходимо провести дополнительные манипуляции со своим смартфоном или аппаратным токеном.

3. Фактор свойства

Биометрия — использование биологических особенностей пользователя для идентификации и аутентификации. Простой пример — сканер отпечатков пальца (TouchID) и лица (FaceID). Остальные способы (например, сканирование сетчатки глаза) очень экзотичны и встречаются редко. Также стоит отметить такие вещи, как работа с клавиатурой и тачскрином устройства. Эти особенности могут анализироваться системой после авторизации пользователя и, если они не соответствуют ранее сформированным шаблонам, система предположит, что пользователь ненастоящий, пароль скомпрометирован, и примет решение о блокировке данного пользователя.

Выбор метода аутентификации

1. Аутентификация по паролю.

2. Децентрализованная аутентификация (OpenID, OpenAuth, OAuth).

3. Биометрическая аутентификация.

4. Аутентификация с помощью аппаратных носителей.

Ниже мы подробнее рассмотрим требования к парольной аутентификации.

Требования к форме аутентификации

1. Маскирование пароля

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

Поэтому можно добавить элемент управления, делающий видимым пароль, как на форме регистрации, так и на форме аутентификации:

2. Логин и пароль — на одной странице

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

Неприемлемый вариант:

Удачный вариант:

3. Двухфакторная или двухэтапная аутентификация

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

4. Беспарольная аутентификация

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

5. Одноразовые пароли

При использовании одноразовых паролей, высылаемых на электронную почту или по SMS, а также последних цифр номеров телефона, необходимо разблокировать форму ввода пароля после нажатия кнопки «Прислать пароль». Далее укажите пользователю, откуда его стоит ждать, включая время жизни пароля:

6. Восстановление доступа

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

7. Обязательность заполнения полей

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

8. Многократное нажатие на кнопку «Вход»

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

9. Невидимые символы

При вставке логина и/или пароля из буфера может возникнуть необходимость переноса пробелов в начале или конце строки, невидимых символов (табуляция, перенос строки и др.). Предупредите пользователя о наличии таких символов в полях ввода:

Требования к паролю, его передаче и хранению

1. Ограничение на количество попыток ввода пароля

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

2. Передача пароля методом POST

Нежелательно применять метод GET для передачи пароля на сервер, для этой цели подойдет метод POST, поскольку:

• не кэшируется и, как следствие, пароль и логин не попадут в кэш поисковых систем;

• не остается в истории браузера;

• не сохраняется в логах сервера;

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

3. Запрет на хранение пароля в открытом виде на сервере

В базе данных необходимо хранить хэш пароля. Избежать подбора пароля с помощью радужных таблиц поможет динамически генерируемая соль. Недопустимо использовать в качестве алгоритмов хэширования md5, SHA-1/SHA-256.

4. Требования к паролю

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

• Пароль должен содержать не менее 8 символов.

• Ограничение на максимальную длину пароля должно быть не менее 64 символов.

• Как минимум одна заглавная и одна строчная буква.

• Должна быть как минимум 1 цифра.

• Допускается наличие следующих символов: ~ ! ? @ # $ % ^ & * _ - + ( ) [ ] { } > < / \ | " ' . , :

• Пароль не должен включать в себя легко вычисляемые сочетания символов (имена, фамилии и т. д.), а также общепринятые сокращения (USER, ADMIN, ALEX и т. д.), пароли от скомпрометированных ресурсов, словарные слова, состоящие из повторяющихся или последовательных символов, контекстно-зависимые слова (имя службы, имя пользователя и производные от него).

• Верификаторы не должны позволять абоненту хранить «подсказку», доступную неаутентифицированному заявителю, а также верификаторы не должны побуждать абонентов использовать определенные типы информации при выборе паролей.

• Верификатор должен принудить изменить пароль, если есть доказательства его компрометации.

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

5. Подсказки

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

6. Повторение пароля

Сделайте второе поле для повторения ранее введенного пароля — это поможет избежать ошибок, при его заведении:

Резюме

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

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

Спасибо за внимание!

Полезные материалы для разработчиков и аналитиков мы также публикуем в наших соцсетях – ВК и Telegram.