Автентифікація (веб)
Автентифікàція (англ. Authentication) — це перевірка достовірності пред'явленого користувачем ідентифікатора.
Автентифікація вимагається при доступі до таких інтернет сервісів, як:
- електронна пошта;
- вебфоруми;
- соціальні мережі;
- інтернет-банкінг;
- платіжні системи;
- корпоративні сайти;
- інтернет-магазини.
Позитивним результатом автентифікації є авторизація користувача, тобто надання йому прав доступу до ресурсів, визначених для виконання його завдань. Залежно від важливості ресурсу, для доступу до нього можуть застосовуватися різні методи автентифікації.
Залежно від міри довірчих стосунків, структури, особливостей мережі і віддаленості об'єкта перевірка може бути односторонньою або взаємною. Також розрізняють однофакторну і строгу (двофакторну) автентифікації. В однофакторних системах, найпоширенішими в цей час є парольні системи автентифікації.
У користувача є ідентифікатор і пароль, тобто секретна інформація, відома тільки користувачеві (і можливо — системі), яка використовується для проходження автентифікації. Залежно від реалізації системи, пароль може бути одноразовим або багаторазовим. Далі розглянуто основні методи автентифікації за принципом наростаючої складності.
Базова автентифікація — найпростіший спосіб обмеження доступу до вебдокументів. Основна перевага — простота реалізації і використання. Однак, разом з перевагою, цей засіб автентифікації отримав і цілий ряд недоліків. Механізм автентифікації включається в той момент, коли браузер запрошує у сервера захищений документ, не надаючи при цьому даних для ідентифікації. У відповідь на такий запит сервер посилає заголовок:
401 Unauthorizedі пропонує спосіб для ідентифікації.
Бачачи подібну відповідь, браузер формує вікно, в якому пропонується ввести ім'я користувача і пароль. Після введення своїх даних, браузер відправляє новий запит на сервер, в який він додає рядок для автентифікації.
Персональні дані не передаються в явному вигляді. Вони кодуються за технологією Base64. З одного боку це виглядає досить безпечним, але з іншого, для розкодування такого рядка, необхідно скористатися однією функцією. Ця функція включена, у різноманітні мови програмування.
У механізму базової автентифікації існує цілий ряд особливостей. Перш за все це кешування даних браузером. Робиться це для «полегшення» роботи користувача, немає необхідності повторно вводити свої дані, з іншого боку це може призвести до перехоплення персональних даних. Робота IIS з базовою автентифікацією, теж не проста. За стандартом потрібно, щоб у системі був зареєстрований користувач, з таким же ім'я користувача і паролем, і з правами на вхід в систему. Так само варто відзначити простоту роботи базової автентифікації з проксі-серверами. Завдяки простоті, вона легко проходить через проксі-сервер.
Дайджест автентифікація є просунутішим і складнішим видом автентифікації, ніж базова автентифікація. Головною відмінністю тут є те, що логін-пароль користувача пересилаються через мережу не у відкритому виді, а шифруються за алгоритмом MD5 (хешуються). Налаштування дайджест автентифікації схоже на налаштування базової автентифікації. Основні кроки залишаються колишніми:
- створити файл з паролями;
- прописати ресурс, що захищається, в конфігурацію Apache (у файлі httpd.conf або у файлі .htaccess);
- створити файл для роботи з групами і настроїти груповий доступ (цей пункт не є обов'язковим).
Дайджест-автентифікація підтримується всіма популярними серверами й браузерами.
Протокол HTTPS дозволяє шифрувати усі дані, що передаються між браузером і сервером, а не тільки імена користувачів і паролі. Власне кажучи, HTTPS не є окремим протоколом, але є комбінацією нормальної взаємодії HTTP через SSL або TLS. Це гарантує помірний захист від підслухування і від атаки «людина-посередині».
Типовим TCP портом HTTPS є 443 (для HTTP типове значення 80).
Щоб підготувати вебсервер для прийняття https транзакцій адміністратор повинен створити сертифікат з відкритим ключем для вебсервера. Цей сертифікат повинен бути підписаним уповноваженим на видачу сертифікатів який засвідчує, що власник сертифікату — той самий, що стверджується у сертифікаті.
браузери розповсюджуються з сертифікатами уповноважених на видачу сертифікатів верхнього рівня, таким чином браузери можуть перевірити сертифікати підписані ними. Організації можуть також мати їх власні уповноважені на видачу сертифікатів, особливо якщо вони відповідальні за конфігурацію браузерів, що мають доступ до їхніх власних сайтів, оскільки вони можуть тривіально додати свого власного сертифіката до браузера. Деякі сайти використовують самостійно підписані сертифікати. Їхнє використання забезпечує захист проти підслуховування, але є ризик атаки «людина-посередині».
Система може також використовуватися для клієнтської автентифікації, для того, щоб дозволяти доступ до вебсервера тільки зареєстрованим користувачам. Для цього адміністратор сайту створює сертифікати для кожного користувача, які завантажуються в їхній браузер. Ці сертифікати звичайно містять ім'я і електронну пошту зареєстрованого користувача і автоматично перевіряються сервером при кожному повторному підключенні. Введення паролю не потрібне. Рівень захисту залежить від коректності запровадження браузерного і серверного програмного забезпечення і підтримуваних криптографічних алгоритмів.
Механізми автентифікації із застосуванням цифрових сертифікатів, як правило, використовують протокол із запитом і відповіддю. Сервер автентифікації відправляє користувачеві послідовність символів, так званий запит. Відповіддю виступає запит сервера автентифікації, підписаний за допомогою закритого ключа користувача.
Автентифікація з відкритим ключем використовується як захищений механізм автентифікації в таких протоколах як SSL. Вона також може використовуватися як один з методів автентифікації у рамках протоколів Kerberos і RADIUS.
Не зважаючи на те, що криптографія з відкритим ключем згідно зі специфікацією Х.509 може забезпечувати строгу автентифікацію користувача, сам по собі незахищений закритий ключ подібний до паспорта без фотографії. Закритий ключ, що зберігається на твердому диску комп'ютера власника, уразливий відносно прямих і мережевих атак. Досить підготовлений зловмисник може викрасти персональний ключ користувача і за допомогою цього ключа представлятися цим користувачем. Захист ключа за допомогою пароля допомагає, але недостатньо ефективно — паролі уразливі відносно багатьох атак. Поза сумнівом, вимагається безпечніше сховище. Смарт-картки — пластикові картки стандартного розміру банківської картки, що мають вбудовану мікросхему. Вони знаходять усе ширше застосування в різних областях, від систем накопичувальних знижок до кредитних і дебетових карток, студентських квитків і телефонів стандарту GSM.
Для використання смарт-карток в комп'ютерних системах потрібний пристрій читання смарт-карток. Незважаючи на назву — пристрій, більшість подібних крайових пристроїв, або пристроїв сполучення (IFD), здатні як прочитувати, так і записувати інформацію, якщо дозволяють можливості смарт-картки та права доступу. Пристрої читання смарт-карток можуть підключатися до комп'ютера за допомогою послідовного порту, слоту PCMCIA або USB. Пристрій читання смарт-карток також може бути вбудований в клавіатуру. Як правило, для доступу до захищеної інформації, що зберігається в пам'яті смарт-картки, вимагається пароль, званий PIN-кодом.
USB-ключі досить привабливі, оскільки USB став стандартним портом для підключення периферійних пристроїв і організації не потрібно купувати для користувачів спеціальні зчитувачі. Автентифікацію на основі смарт-карток і USB-ключів найскладніше обійти, оскільки використовується унікальний фізичний об'єкт, яким повинна володіти людина, щоб увійти до системи. На відміну від паролів, власник швидко дізнається про крадіжку і може відразу прийняти необхідні заходи для запобігання її негативним наслідкам. Крім того, реалізується двохфакторна автентифікація.
Мікропроцесорні смарт-картки і USB-ключі можуть підвищити надійність служб: смарт-картка може використовуватися для безпечного зберігання закритих ключів користувача, а також для безпечного виконання криптографічних перетворень. Безумовно, ці пристрої автентифікації не забезпечують абсолютну безпеку, але надійність їхнього захисту набагато перевершує можливості звичайного настільного комп'ютера.
Для зберігання і використання закритого ключа розробники використовують різні підходи. Найпростіший з них — використання пристрою автентифікації як захищеного носія автентифікаційної інформації: при необхідності картка експортує закритий ключ, і криптографічні операції здійснюються на робочій станції. Цей підхід є не найдосконалішим з точки зору безпеки, зате що відносно легко реалізовується і пред'являє невисокі вимоги до пристрою автентифікації. Два інші підходи безпечніші, оскільки припускають виконання пристроєм автентифікації криптографічних операції. При першому користувач генерує ключі на робочій станції і зберігає їх у пам'яті пристрою. При другому користувач генерує ключі за допомогою пристрою. У обох випадках, після того, як закритий ключ збережений, його не можна витягнути з пристрою і отримати будь-яким іншим способом.
Безліч різних сайтів використовують як засіб автентифікації cookies, до них належать чати, форуми, ігри. Якщо cookie вдасться викрасти, то, підробивши його, можна автентифікуватись замість іншого користувача.
У разі, коли дані, що вводяться, погано фільтруються або не фільтруються зовсім, викрасти cookies стає не дуже складно. Щоб якось поліпшити ситуації використовується захист за IP-адресою, тобто cookies сесії зв'язуються з IP-адресою, з якого спочатку користувач авторизувався в системі. Проте IP-адресу можна підробити використовуючи IP-спуфінг, тому сподіватися на абсолютний захист за IP-адресою теж не можна.
Механізм використання cookies наступний:
- користувач вводить ім'я користувача і пароль в текстових полях сторінки входу і відправляє їх на сервер;
- сервер отримує ім'я користувача і пароль, перевіряє їх і, при їхній правильності, відправляє сторінку успішного входу, прикріпивши cookies з деяким ідентифікатором сесії. Ці cookies можуть бути дійсними тільки для поточної сесії браузера, але можуть бути налагоджені і на тривале зберігання;
- щоразу, коли користувач запрошує сторінку з сервера, браузер автоматично відправляє cookies з ідентифікатором сесії серверу. Сервер перевіряє ідентифікатор у своїй базі ідентифікаторів і, за наявності в базі такого ідентифікатора, «пізнає» користувача.
Цей метод широко використовується на багатьох сайтах, наприклад на Yahoo, у Вікіпедії, в Facebook.
Багато браузерів (зокрема Opera, FireFox), шляхом редагування властивостей cookies, можуть управляти поведінкою вебсайтів. Змінивши термін використання непостійних (сесійних) cookies можна, наприклад, отримати формально-необмежену сесію після авторизації на якому-небудь сайті. Скориставшись такими механізмами, наприклад як JavaScript, користувач може змінити файл cookies. Більше того, існує можливість замінити сесійних cookies — постійними (з вказанням терміну придатності). У цей час більшість браузерів використовують cookies з прапором HTTPonly, який забороняє доступ до cookies різним скриптам.
Виділяють такі види децентралізованої автентифікації:
- OpenID. Відкрита децентралізована система автентифікації користувачів. OpenID дозволяє користувачеві мати один логін-пароль для різних вебсайтів. Безпека забезпечується підпискою повідомлень. Передача ключа для цифрового підпису заснована на використанні алгоритму Діффі — Хеллмана, також можлива передача даних за HTTPS. Можливі уразливості OpenID :
- схильний до фишінгових атак. Наприклад, шахрайський сайт може перенаправити користувача на підроблений сайт OpenID провайдера, який попросити користувача ввести його секретний логін і пароль;
- уразлива перед атакою «людина посередині».
Автентифікація за OpenID зараз активно використовується і надається такими гігантами, як BBC, Google, IBM, Microsoft MySpace, PayPal, VeriSign, Yandex і Yahoo.
- OpenAuth. Використовується для автентифікації AOL користувачів на вебсайтах. Дозволяє їм користуватися сервісами AOL, а також будь-ким іншими надбудованими над ними. Дозволяє проходити автентифікацію на сайтах, що не належать до AOL, при цьому не створюючи нового користувача на кожному сайті. Протокол функціонує схожим на OpenID образом. Також прийняті додаткові заходи безпеки :
- сесії (у тому числі інформація про користувача) зберігаються не в cookies;
- cookies автентифікації шифруються алгоритмом PBEWithSHAAnd3-KeyTripleDES-CBC;
- доступ до cookies автентифікації обмежений певним доменом, так що інші сайти не мають до них доступу (у тому числі сайти AOL).
- Oauth. OAuth дозволяє користувачу дозволити одному інтернет-сервісу отримати доступ до даних користувача на іншому інтернет-сервісі. Протокол використовується в таких системах, як Twitter, Google (Google також підтримує гібридний протокол, що об'єднує в собі OpenID і OAuth).
Одним з головних мінусів таких систем є те, що злом дає доступ відразу до багатьох сервісів.
Багато в чому безпека користувачів в Інтернеті залежить від поведінки самих користувачів. Так наприклад, Google показує з якої IP-адреси включені призначені для користувача сесії, логірує авторизацію, також дозволяє здійснити такі налаштування:
- передача даних тільки за HTTPS;
- Google може детектувати користувача, якщо зловмисник використовує ваш акаунт (друзі вважають ваші листи спамом, остання активність відбувалася в нехарактерний для вас час, деякі повідомлення зникли…);
- відстежування списку третіх сторін, що мають доступ до використовуваних користувачем продуктів Google.
Частенько користувачеві повідомляється з якої IP-адреси він останній раз проходив автентифікацію.
Для підвищення безпеки на практиці використовують декілька чинників автентифікації відразу. Проте, при цьому важливо розуміти, що не всяка комбінація декількох методів є багатофакторною автентифікацією. Використовуються чинники різної природи :
- Властивість, яку має суб'єкт. Наприклад, біометрія, природні унікальні відмінності: особа, відбитки пальців, веселкова оболонка очей, капілярні візерунки, послідовність ДНК;
- Знання-інформація, яку знає суб'єкт. Наприклад, пін-код;
- Володіння — річ, яку має суб'єкт. Наприклад, електронна або магнітна картка, флеш-память.
У основі одного з найнадійніших на сьогодні методів багатофакторної автентифікації лежить застосування персональних апаратних пристроїв — токенів. Токени дозволяють генерувати і зберігати ключі шифрування, забезпечуючи тим самим строгу автентифікацію. Використання класичних «багаторазових» паролів є серйозною уразливістю при роботі з чужих комп'ютерів, наприклад в інтернет-кафе. Це підштовхнуло провідних виробників ринку автентифікації до створення апаратних генераторів одноразових паролів. Такі пристрої генерують черговий пароль або за розкладом (наприклад, кожні 30 секунд), або за запитом (при натисненні на кнопку). Кожен такий пароль можна використовувати тільки один раз. Перевірку правильності введеного значення на стороні сервера перевіряє спеціальний сервер автентифікації, що обчислює поточне значення одноразового пароля програмно. Для збереження принципу двохфакторності автентифікації окрім згенерованого пристроєм значення користувач вводить постійний пароль.
| API для автентифікації | |
|---|---|
| Протоколи автентифікації[en] | |
| Програми | |
| Див. також | |
