Багатофакторна аутентифікація. Як тестувати?

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

Що таке багатофакторна аутентифікація?

Автентифікація – це процес підтвердження особи в системі. Щоб увійти на веб-сайт, користувач повинен мати логін (ім’я користувача) та пароль. Але зловмисники прагнуть різними методами отримати доступ до даних автентифікації.

Двофакторна аутентифікація (2FA) забезпечує додатковий рівень захисту. ЇЇ можна виконати багатьма способами: відповіді на секретні запитання, розпізнавання обличчя чи голосу, повідомлення на електронну пошту, SMS або дзвінок, відбиток пальця тощо. Навіть, якщо логін/пароль було зламано, хакери не можуть отримати доступ до вашого мобільного телефону. Таким чином, вони не пройдуть другий рівень безпеки та не авторизуються в системі. 

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

Типи двофакторної аутентифікації

Способи, якими можна підтвердити свою особу, можна умовно поділити на три типи («фактори»):

- дещо, що ви знаєте (базується на знаннях користувача). Наприклад, пароль чи відповідь на секретне запитання;

- те, що у вас є (залежить від того, чим володіє користувач). Наприклад, код з повідомлення чи відповідь на дзвінок;

- щось, що ви є (біометричні дані). Наприклад, розпізнавання обличчя/голосу чи відбиток пальця.

Як працює багатофакторна аутентифікація?

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

Найпоширеніша схема двофакторної аутентифікації виглядає приблизно так:

1. Користувач вводить логін та пароль.
2. Програма надсилає одноразовий код на телефон/електронну пошту.
3. Користувач вводить одноразовий код у вікні перевірки системи.
4. Якщо код правильний, тоді доступ надано. В іншому випадку програма пропонує повторно надіслати одноразовий код (однак, кількість повторних спроб є обмеженою).

Більшість варіантів реалізації двофакторної аутентифікації використовують фактор «те, що у вас є», тому його розглянемо детальніше. Існує декілька загальних реалізацій.

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

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

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

Код, надісланий іншим носієм. Деякі двофакторні служби використовують SMS або код, надісланий електронною поштою, щоб підтвердити, що у вас є доступ до номера телефону чи електронної адреси. Це більш ризиковано, оскільки відносно легко перенаправити SMS-повідомлення (за допомогою атак на SS7 або будь-яким іншим методом). А електронна пошта часто використовується для скидання пароля (це означає, що зловмисник, який має доступ до вашої електронної пошти, може як скинути ваш пароль, так і обійти запит 2FA).

Push-підтвердження. Альтернативним підходом до кодів OTP (One-Time Passwords) є надсилання push-сповіщень на мобільний телефон користувача, яке він може прийняти або відхилити. Цей метод є менш поширеним, оскільки вимагає від користувача інсталяції автентифікатора для конкретної програми.

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

Тестування двофакторних систем

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

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

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

Перевірити це можна за вихідним кодом або за допомогою спеціальних плагінів (все залежить від структури самої системи).

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

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

«Запам'ятати цей комп'ютер». Не всі додатки підтримують таку функцію. Як правило, це лише довготривалий файл cookie з випадково згенерованим значенням, яке зберігається в базі даних, але важливо переконатися, що це значення справді безпечно згенеровано випадковим чином і відрізняється для кожного користувача (в ідеалі токен також буде різним для кожного комп’ютера).

Якщо ж хтось випадково встановить прапорець «запам’ятати цей комп’ютер» на спільному комп’ютері, слід перевірити, чи можна його потім видалити (так як протягом його дії кіберзлочинець може скопіювати цей токен та обійти двофакторну аутентифікацію).

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

Вимкнення двофакторної аутентифікації. В даному кейсі перевіряється, чи потрібно знову вводити пароль та підтверджувати поточні дії перед вимкненням двофакторної аутентифікації. Слід зазначити, що зазвичай, перед вимиканням 2FA потрібно вводити пароль. В протилежному випадку зловмисник, який отримав доступ до облікового запису, зможе увімкнути/вимкнути її самостійно та фактично заблокувати жертву.

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

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

Перевірити це просто – отримати код повідомленням або електронною поштою, спробувати відновити пароль через імейл.

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

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

Якщо є можливість переглянути вихідний код, важливо переконатися, що ключ безпеки генерується з надійного генератора випадкових чисел, а не встановленого за замовчуванням, так як стандартні генератори у більшості мов програмування швидкі, але передбачувані. Тобто зловмисники можуть з’ясувати, які ключі було призначено яким користувачам. До того ж, вони повинні мати довжину 20 байтів (довші – добре, але може викликати проблеми сумісності), коротших слід уникати з міркувань безпеки.

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

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

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

Введення декількох неправильних кодів поспіль (вгадування кодів). Має бути певний механізм для обмеження швидкості (або кількості) введення кодів. В даному випадку CAPTCHA може бути корисною. Але користувач все одно має бути повідомлений якимось чином, оскільки це, ймовірно, означає, що його пароль було зламано. Більшість реалізацій двофакторної реалізації вимагають правильного пароля перед запитом другого фактора.

Щоб це перевірити, спробуйте увійти з неправильним кодом. Робіть це кілька разів протягом короткого періоду часу. Якщо програма починає запитувати CAPTCHA або повністю блокує вас, вона не вразлива. Особливо чутливим програмам слід ретельно подумати про те, щоб сповіщати користувача після будь-якої невдалої спроби аутентифікації, оскільки неправильна спроба все одно означає, що зловмисник міг отримати пароль користувача.

Час, який код є актуальним для поточної сесії. Проміжок часу, за який поточний код є дійсним, має бути достатнім для комфортного введення користувачем. Але водночас, цей проміжок не має бути занадто довгим для того, щоб кіберзлочинець встиг його перехопити та використати в своїх інтересах. Загальний діапазон дійсності становить близько п’яти хвилин у будь-якому напрямку від часу, встановленого на сервері, хоча скорочення до двох-трьох хвилин – теж допустимо. Та головне питання полягає в тому, скільки кодів є дійсними одночасно: проміжок валідності, поділений на час між новими кодами.

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

Обхід блокування через cookie або IP-адресу. Іноді дані про блокування відстежуються в файлі cookie сеансу або його відстеженням IP-адреси. Зловмисник може легко обійти даний механізм блокування. Будь-які дані відстеження блокування мають бути пов’язані з обліковим записом у базі даних, а не передаватися клієнту або відстежуватися на основі будь-якої ідентифікації клієнта, оскільки будь-яке з них можна змінити.

Спробуйте очистити файли cookie, якщо буде втрачено доступ до облікового запису або якщо буде запропоновано ввести CAPTCHA. Та найкраще перевірити, як інформація про блокування відстежується на сервері, і, ймовірно, вимагатиме перегляду вихідного коду.

Сертифікати та смарт-карти. Безпека транспортного рівня (TLS) зазвичай використовується для шифрування трафіку між клієнтом і сервером, а також для надання клієнту механізму для підтвердження ідентичності сервера. Однак, він також може забезпечити механізм для підтвердження сервером ідентичності клієнта, відомий як автентифікація сертифіката клієнта або взаємний TLS (mTLS). Ключовим принципом є те, що користувач представляє цифровий сертифікат (зберігається на його машині або на смарт-картці), який перевіряється сервером.

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

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

Висновки

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