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

Я закінчив курс в університеті Вірджинії в 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 (Вхід) переважає і постійно збільшується. І особливо це помітно на популярних сайтах.

Працюйте з менеджерами паролів популярних переглядачів

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

• Internet Explorer
• Chrome
• Firefox
• Safari

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

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

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

Опрацьовуйте найбільш вади користувача

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

Він ввів свою пошту використовуючи Ця електронна адреса захищена від спам-ботів. Вам необхідно увімкнути JavaScript, щоб побачити її. замість Ця електронна адреса захищена від спам-ботів. Вам необхідно увімкнути JavaScript, щоб побачити її.? А може бути замість Ця електронна адреса захищена від спам-ботів. Вам необхідно увімкнути JavaScript, щоб побачити її. він написав Ця електронна адреса захищена від спам-ботів. Вам необхідно увімкнути JavaScript, щоб побачити її.? Ви також повинні виправляти ці помилки і попереджати користувача про це.

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

Допоможіть користувачам вибрати правильний пароль

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

Існує прості методики вимірювання надійності пароля під час його введення. І ми рекомендуємо і вам її застосовувати.

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

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

Не забувайте про клавіатуру

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

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

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

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

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

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

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

Речі, про які я забув згадати

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

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

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