Почему менеджеры паролей игнорируют поля ввода?

Менеджеры паролей ищут ряд атрибутов в формах и полях ввода: «автозаполнение», «заполнитель» и «тип». Но самое главное, они будут распознавать поля «имя пользователя» и «пароль», только если поле «пароль» имеет тип = «пароль».

Я работал над страницей входа в свой последний сайд-проект [SPRITSTAT] (https://sprit.thga.at), когда наткнулся на частую проблему с полями входа.

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

Без сомнения, безопасность паролей — это то, что нельзя игнорировать в любом текущем веб-приложении, и одна из основных рекомендаций — [использовать отдельные пароли для каждого веб-сайта] (https://www.cisa.gov/uscert/ncas/current-activity/ 27.03.2018/Creating-and-Managing-Strong-Passwords), что на самом деле возможно только в том случае, если вы используете менеджер паролей.

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

Теперь есть [несколько хороших руководств] (https://hiddedevries.nl/en/blog/2018-01-13-making-password-managers-play-ball-with-your-login-form) подробно о том, как настроить форму входа в систему таким образом, чтобы менеджеры паролей могли найти, а затем заполнить поля имени пользователя и пароля. На самом деле это не так сложно, и для простых форм входа все сводится к следующим правилам:

1. не усложняйте и следуйте рекомендациям, например, не используйте динамические поля/идентификаторы/…, не используйте запросы GET для входа в систему.

1. Используйте стандартные формы

1. используйте атрибут placeholder по назначению

1. используйте атрибут автозаполнения – "username" для полей username и "current-password"/"new-password" для полей password

1. используйте атрибут правильного типа – "текст"/"электронная почта" для полей имя пользователя и "пароль" для полей пароль

Это был последний пункт в сочетании с исправлением юзабилити, который я думал реализовать, что вызвало у меня довольно сильную головную боль. После того, как я выполнил все рекомендации в [руководстве] (https://hiddedevries.nl/en/blog/2018-01-13-making-password-managers-play-ball-with-your-login-form), по-прежнему не работал ни на одном из моих устройств, менеджеры паролей просто игнорировали поля «имя пользователя»/«пароль».

К настоящему времени мы привыкли к маленькому значку глаза в полях пароля, который позволяет нам показать или скрыть пароль. Эта функция была лучшей практикой на протяжении многих лет и, безусловно, является одним из самых значительных улучшений удобства использования, которые мы видели с паролями с момента появления Интернета. Обычно пароль скрыт по умолчанию и отображается только при нажатии кнопки с изображением глаза. Хотя это работает хорошо, на самом деле нет веских причин, по которым пароль не должен отображаться по умолчанию, как [Якоб Нильсен отметил более десяти лет назад] (https://www.nngroup.com/articles/stop- маскировка пароля/). Большую часть времени рядом нет никого, кто действительно мог бы увидеть пароль, и даже если это редкая порода, которая могла бы мгновенно вспомнить разумный пароль в течение нескольких секунд, необходимых для его ввода. С этой мыслью я создал кнопку скрыть/показать и установить для атрибута type поля ввода значение "text", что позволит отображать пароль в виде обычного текста. Если кнопка нажата, тип меняется на "пароль", пароль автоматически маскируется. Только по прошествии большего количества времени, я хотел бы признать, я случайно заметил, что менеджер паролей действительно позволяет мне автоматически заполнять поля «имя пользователя» / «пароль», когда пароль скрыт.

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

Я должен признать, что стоит внимательно прочитать ваши ресурсы — следующее предложение в руководстве я заметил только после моего испытания: * «избегайте имитации поля пароля с обычным полем, чтобы вы могли делать такие вещи, как показ последнего символа. *

Если вам понравилась эта история и вы хотите узнать больше от меня, вы можете подписаться на меня в Twitter/LinkedIn. Кроме того, если вы заинтересованы в [SPRITSTAT] (https://sprit.thga.at/), это открытый исходный код, и вы можете найти код на моем [Github] (https://github.com/tgamauf/spritstat). ).

Рекомендуемое изображение от Markus Spiske на Unsplash.

Также опубликовано [Здесь] (https://www.trialbyfire.tech/2022/03/31/why-password-managers-ignore-input-fields/)