Божественний підхід до аутентифікації

Я закінчив курс в університеті Вірджинії в 1992 році за темою «Комп'ютерні науки у спрощеному вигляді». Причина, по якій я вибрав саме спрощений курс, була в тому, що звичайний курс CS в університеті Вірджинії вимагає проходження інженерної школи і я був абсолютно не готовий до такої кількості математики і фізики. Краса спрощеного курсу була в тому, що я міг відвідати всі цікаві мені предмети, пропустивши інші.

Одним з моїх улюблених предметів, принаймні він запам'ятався мені найбільше, був «Алгоритми». Я завжди кажу людям, які мене запитують про це, що цей предмет вплинув на моє становлення, як програміста, найбільше. Я точно не знаю чому, але кілька років тому в мене з'явилося дивне передчуття, і я чомусь перейшов на сторінку Ренді Пауша автор тієї самої книги). З подивом для себе я виявив, що він набирає студентів до себе на курс. Час було ідеальним: університет Вірджинії, осінь 1991, CS461 Аналіз алгоритмів і 50 студентів на курсі. Я був одним з них.

І без сумнівів я був вражений цей курсом. Пауш був настільки блискучим і харизматичним вчителем, що ти розумієш сенс старого прислів'я про те, що спочатку потрібно вибрати вчителя, а потім вже те, що вчити, якщо ви взагалі повинні будете робити цей вибір. Це настільки сильно відображає дійсність.

І тому комбінація з чудового вчителя і теми зробили свою справу, адже алгоритми це одна з найважливіших частин програмування, якщо не сама. Не те, щоб ми винаходили нові алгоритми, але ми повинні були зрозуміти код існуючих, оцінити швидкість їх виконання при різних вхідних даних і визначити коректний алгоритм для нашої задачі. Це були цілі нашого курсу.

І одна із самих крутих речей, якої нас навчив Ренді Пауш, була необхідність поставити собі таке питання перед вибором алгоритму:
А який би алгоритм вибрав Бог?




Зрозуміло, що Бог не вибрав би сортування бульбашкою, швидке сортування та сортування шелла, як ми смертні, при впорядкуванні списку. Він би просто негайно помістив би всі елементи в правильному порядку. За один крок. Нижньою межею часу виконання було б O(1). Не певний час, а просто один крок. За один момент. Адже ти ж Бог.

Подібні роздуми підірвали мій мозок у той час.

Я завжди підозрював, що люди стають справжніми програмістами тому, що їм потрібно грати роль бога. Ренді Пауш взяв цю концепцію і наочно показав, як за допомогою неї встановлювати межі завдання і ставити собі складні питання про те, що ти робиш і навіщо.

Саме тому, коли ми робили вікно для аутентифікації Discourse, я повернувся до того, з чого я навчався на даному курсі і задав собі питання:
Як реалізував би дане вікно Бог?


І відповідь, звичайно ж, очевидна — Бог не став би зв'язуватися з розробкою даного вікна. Навіщо? Він же Бог і, одного разу зареєструвавшись у його застосуванні, він завжди зрозуміє хто ви.

Це по очевидним причин ситуація, що не реалізується завдання для нас, тому що Бог не є одним з наших інвесторів.

Але наскільки близько ми можемо наблизитися до реалізації божественного підходу до аутентифікації? Це, безумовно, благородна і стоїть досягнення ціль.



Хіба не Білл Гейтс одного разу запитав чому кожен програміст пише одне і те ж вікно для вибору файлів знову і знову? Це питання можна віднести і до аутентифікації. Навіщо? Я вже давно кажу, що краще вікно аутентифікації — його повна відсутність і я абсолютно підтримую ідею аутентифікації за допомогою ваших мережевих драйверів в будь-якій ситуації, коли це можливо. Тому наша команда повністю солідарна з вами, якщо ви реалізуєте можливості входу на ваш ресурс через інші сервіси.



Але сьогодні я б хотів акцентувати вашу увагу на найголовнішому способі пройти аутентифікацію: імені користувача (далі логін) та пароль. Це основний спосіб попадання на сайт поки ви не реалізували інших методів.

Форма аутентифікації з двома полями, двома кнопками і посиланням виглядає досить просто, правильно? Це стандарт. Щоправда до тих пір, поки у вас не виникли проблеми зі входом. Давайте подумаємо.

Дайте користувачеві можливість увійти за допомогою пошти
Критичною помилкою OpenID, незважаючи на те, що цей сервіс мені дуже сподобався, як спосіб входу на сайт, було те, що вони припускали, що користувачі могли використовувати URL в якості ідентифікатора. Це дивне і неправильно рішення і послужило в довгостроковому періоді причиною того, що OpenID так і не став майбутнім стандартом.

Ідентифікатором користувача при вході може служити тільки електронна пошта. Просто і зрозуміло. Що відбувається, коли ви забуваєте пароль? Ви використовуєте електронну пошту для його відновлення, правильно? Вона і є вашим ідентифікатором. Деякі люди навіть пропонують зробити її єдиним способом аутентифікації.



Мати унікальне ім'я користувача це, звичайно, добре, але завжди давайте користувачам вибір способу входу на сайт: або з допомогою електронної пошти, або за допомогою унікального імені. Я це вам кажу тому, що зі 100% ймовірністю можу стверджувати, що коли користувачі забувають пароль, то їм у будь-якому випадку доведеться використовувати пошту для скидання або відновлення. Пошта і пароль — це сильно пов'язані поняття, які використовуються разом. Завжди!

(І хочу висловити своє фу тим сервісами, які не дозволяють мені використовувати свою пошту в якості унікального ідентифікатора. Я стежу за вами.)

Скажіть користувачеві про те, коли аккаунта з його поштою не існує
Добре, тепер ми знаємо, що пошта де-факто є стандартом ідентифікації для більшості людей, і це логічний і необхідний стан речей. Але яку з своїх численних електронних пошт я повинен використовувати на вашому сайті?

Це послужило причиною великої обговорення на Discourse про те, чи варто показувати персональні дані інших користувачів чи ні, коли вони вводять пошту у формі відновлення пароля. На багатьох сайту після введення пошти у форму для відновлення пароля, ви побачите таке повідомлення:
Якщо аккаунт з даними адресою існує, то інструкції з відновлення паролю було надіслано вам на пошту.


Ключовим у цьому питанні є якщо слово, яке повністю виключає можливість розкриття персональних даних користувачів ресурсу.

Ми серйозно ставимося до подібних речей при розробці Discourse і тому розкриття даних вашої пошти стороннім особам вам не загрожує. Але після того як багато користувачів, що намагаються вгадати свою пошту, отримують повідомлення «Яку пошту ви введете на цей раз?», ми прийшли до висновку, що в певних випадках дружність інтерфейсу набагато важливіше, ніж безпека.



Тому було вирішено показувати в повідомленнях пошту, якої не існує в нашому сервісі. Це рішення одночасно є цілком безпечним і дружнім до користувача. При бажанні ви можете заборонити подібні маніпуляції з вашою поштою у налаштуваннях нашого сервісу.

Дозвольте користувачам перемикатися між формами Вхід і Реєстрація в будь-який час, коли вони захочуть
Дуже багато сайтів показують кнопки входу і реєстрація поруч один з одним. Це мене здивувало, адже процеси ідентифікації та реєстрації є абсолютно різними речами.

Добре, з точки зору користувача може це і не зовсім так. Форма входу на сайті усім відомого журналу The Verge показує наскільки близькими можуть бути форми входу та реєстрації.



Ми визнаємо наявність певної схожості між цими процесами і тому ми зробили обидві форми доступними в один і той же час, реалізувавши їх через перемикачі.



Обидві ці форми реалізовані через спливаюче вікно і легко можуть бути прибрані з екран або показані знову при натисканні кнопок входу або реєстрації.



Вибирайте прості слова
Це велика проблема мови. У нас є дуже багато слів, що позначають одні й ті ж речі:
  • Sign in (Вхід або Увійти)
  • Log in (Аутентифікація)
  • Sign up (Підписатися)
  • Register (Зареєструватися)
  • Join [site] (Приєднатися)
  • Create account (Створити обліковий запис або створити обліковий запис)
  • Get Started (Приступити до використання)
  • Subscribe (Підписатися. Але більшості випадків означає платну підписку)


Яке з цих слів є найбільш підходящим? Результати дослідження користувальницьких даних і їх (користувачів) поведінки теж можуть бути неправильно інтерпретовані і привести до подальших помилок.

Я віддаю перевагу використовувати найбільш короткі слова при будь-якій можливості, тому що я шанувальник стислості й лаконічності. Але ці речі дуже часто залежать від обставин і користувацьких переваг.



Sign in (Вхід або Увійти) зустрічається найбільш часто і інтуїтивно більше підходить для нашої задачі, хоча Log in(Аутентифікація) має історично склався і специфічне значення, властиве комп'ютерних систем і тому дане слово теж є цінним.

Пару років тому я робив опитування найпопулярніших сайтів США і Британії про те, які слова вони використовують. Я помітив, що кількість використання Sign in (Вхід) переважає і постійно збільшується. І особливо це помітно на популярних сайтах.



Працюйте з менеджерами паролів популярних браузерів
Кожна форма аутентифікації, яку ви створюєте, повинна бути на сумісність і працездатність з менеджерами паролів популярних браузерів, таких як:


Це необхідний мінімум. При наступній спробі аутентифікації в одному з браузерів ви будете бачити поля ідентифікатора користувача і пароля заповненими.



Користувачі покладаються на ці, вбудовані в браузер, речі і будь-яка реалізація аутентифікації повинна поважати даний факт і реалізовуватися з його урахуванням. Наприклад, в HTML коді полі пароль повинно мати наступний атрибут: type = password і ім'я, яке ідентифікує поле, як поле для введення пароля.

Також дуже багато сторонніх менеджерів паролів, таких як LastPass, але в основному варто орієнтуватися на роботу з вбудованими менеджерами популярних браузерів. Якщо ваша форма буде працювати з ними, то найбільш імовірно, що вона буде працювати і з іншими менеджерами.

Обробляйте найбільш зустрічаються власні помилки
Користувач вводить свій пароль з Caps Lock'ом? Попередьте його про це.



Він ввів свою пошту використовуючи name@gmail.co замість name@gmail.com? А може бути замість name@hotmail.com він написав name@hotmail.cm? Ви також повинні виправляти ці помилки і попереджати користувача про це.

(Я також великий фанат функції підглядання паролю, так як з її допомогою користувач може переконатися правильно він ввів пароль. Тільки Internet Explorer і, мені здається, Safari підтримують цю функцію, але на мій погляд інші теж повинні її підтримувати.)

Допомогти користувачам вибрати правильний пароль
Існує дуже багато методик, які вчать правильні ненадійні вибирати паролі, які не є складною і складними, такі як: password123, Iloveyou і так далі.

Існує прості методики вимірювання надійності пароля під час його введення. І ми рекомендуємо і вам її застосовувати.
Це хороша ідея, але на деяких сайтах це виглядає нав'язливо. Реалізація цього теж залишає бажати краще, так як критерії надійності пароля визначає сам сервіс. На одному сайті пароль може бути надійним, а на іншому з ним навіть не пустять на поріг.



Тому з Discourse ми вирішили вчинити інакше. Ми зробили мінімальну довжину пароля рівною 8 символів і за його хешу визначаємо не входить він в 10 000 найбільш популярних у світі паролів.



Не забувайте про клавіатурі
Користувачі, що використовують клавіатуру для взаємодії з сайтом, вимирають, але для тих з них, які ще живі, все ж варто зробити можливість переходити з елементів форми за допомогою клавіатури.



І переконливе прохання упевнитися в тому, що це працює так, як це було задумано.

Обмежуйте кількість спроб на всі можливі дії

Ви повинні обмежувати кількість спроб користувача здійснювати будь-які можливі дії на вашому сайті. Особливо це стосується форми аутентифікації.

Якщо хтось забув свій пароль і зробив 3 спроби увійти на сайт або відновити пароль, то це нормально. Але якщо хтось зробив це 1000 раз, то це досить дивно. Я навіть ризикну припустити, що це не людина.



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

Я вважаю, що хорошим тоном є використовувати стандартні паузи з помірно збільшується інтервалом на спроби входу або відновлення пароля з одного і того ж IP адреси. І ми так і вчинили на своєму сайті.

Речі, про які я забув згадати
Я постарався запам'ятати все, через що ми пройшли при розробці нашої ідеально форми для Discourse, але я впевнений, що ми щось забули або щось не розповіли досить докладно. Наш проект Discourse на всі 100% відкритим і постійно розвивається. Ви можете подивитися його реалізацію і протестувати її.

Вікно аутентифікації всього містить просту форму з двома полями, посиланням і двома кнопками. І все ж після прочитання всього того, що було написано вище, я думаю, ви погодитеся з тим, що ця простота оманлива. Вашим кращим рішенням буде не розробляти форму аутентифікації з нуля, а покладатися на сторонні джерела аутентифікація при будь-якій можливості.

Дана стаття є перекладом. Оригінал статті ви можете знайти на цим посиланням.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.