Менеджер паролів

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до навігації Перейти до пошуку

Менеджер паролів допомагає генерувати, зберігати та вводити складні паролі із зашифрованої бази даних[1]. Менеджери паролів можуть бути виконані у формі:

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

Типи[ред. | ред. код]

Локально встановлене програмне забезпечення[ред. | ред. код]

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

Онлайн-сервіси[ред. | ред. код]

Онлайн-менеджер паролів — це вебсайт, який безпечно зберігає облікові дані. Вони часто є вебверсіями звичайних менеджерів паролів, виконаних як локально встановлене програмне забезпечення.

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

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

Існують змішані рішення. Деякі онлайн-менеджери паролів розповсюджують свій вихідний код, який може бути перевірено і встановлено окремо[2].

Використання онлайн-менеджерів паролів є альтернативою технологіям single sign-on, таким як OpenID або Microsoft account (раніше відомий як Microsoft Wallet, Microsoft Passport, .NET Passport, Microsoft Passport Network, та Windows Live ID).

Апаратні пристрої[ред. | ред. код]

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

Переваги[ред. | ред. код]

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

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

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

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

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

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

Недоліки[ред. | ред. код]

Вразливості[ред. | ред. код]

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

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

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

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

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

Менеджери паролів, які не запобігають скиданню своєї пам'яті на диски, дозволяють отримати незашифровані паролі з жорсткого диску комп'ютера. [джерело?] Вимкнення своп-файлу дозволяє запобігти цьому ризику.

Детальне вивчення онлайн-менеджерів паролів, які виконуються всередині веббраузера користувача, викрило наступні можливі недоліки:[3]

  • Недоліки авторизації: Неправильне розуміння автентифікації та авторизації. Зокрема ці недоліки дозволяли користувачам ділитися своїми обліковими даними з іншими користувачами.
  • Недоліки букмарклетів: онлайн-менеджери паролів у загальному випадку покладаються на букмарклети для входу користувачів. Тим не менше, якщо вони невідповідним чином імплементовані, злочинний вебсайт може скористатись цим для викрадення паролів. Основна причина таких вразливостей у тому, що оточення JavaScript зловмисного вебсайта не є довіреним.[4]
  • Недоліки у інтерфейсі користувача: Деякі онлайн-менеджери паролів пропонують користувачу здійснити вхід через iframe. Це навчає користувача вводити майстер-пароль коли URL, який відображається веббраузером, не є URL онлайн-менеджера паролів. Зловмисник за допомогою фішингу може створити підробний iframe і для перехоплення даних входу користувача. Більш безпечно відкривати нову вкладку для, де користувач вводить облікові дані для входу до онлайн-менеджера паролів.
  • Вебнедоліки: Класичні вебвразливості також можуть бути наявні у онлайн-менеджерах паролів. Зокрема, вразливості XSS та CSRF можуть бути експлуатовані хакерами для отримання паролів користувачів.

Блокування менеджерів паролів[ред. | ред. код]

Різноманітні вебсайти намагалися блокувати менеджери паролів, часто відступаючи при публічно оскарженні.[5][6][7] Як причини називалися захист від автоматизованих атак, захист від фішингу, блокування зловмисного програмного забезпечення або просто відмова від сумісності. Клієнтське програмне забезпечення Trusteer від IBM має окрему функцію блокування менеджерів паролів.[8][9]

Таке блокування було розкритиковане фахівцями із захисту інформації, як таке, що робить користувачів менш захищеними.[7][9] Типова реалізація блокування включає встановлення властивості autocomplete='off' у відповідній вебформі введення пароля. Тому ця властивість ігнорується з Internet Explorer 11[6] на сайтах, доступних по HTTPS,[10] Firefox 38,[11] Chrome 34,[12] і у Safari від 7.0.2.[13]

У науковій роботі 2014 року дослідник з Carnegie Mellon University виявив, що в той час як браузери відмовляються автозаповнення, якщо протокол на поточній сторінці входу відрізняється від протоколу в той час, коли пароль був збережений, деякі менеджери паролів виконують небезпечне заповнення паролів, збережених для версії сайту, доступній по HTTPS, у версії сайту, доступній по HTTP. Більшість менеджерів паролів не захищають від атак з використанням iFrame і перенаправлення, і показують додаткові паролі, якщо увімкнена синхронізація паролів між пристроями.[10]

Див. також[ред. | ред. код]

Посилання[ред. | ред. код]

  1. Price, Rob (22 лютого 2017). Password managers are an essential way to protect yourself from hackers — here's how they work. Business Insider (англ.). Архів оригіналу за 27 лютого 2017. Процитовано 29 квітня 2017.
  2. SpiderOak/Encryptr. GitHub (англ.). Архів оригіналу за 6 липня 2017. Процитовано 28 травня 2017.
  3. Li, Zhiwei; He, Warren; akhawe, Devdatta; Song, Dawn. The Emperor's New Password Manager: Security Analysis ofWeb-based Password Managers (PDF). 2014. Архів оригіналу (PDF) за 5 лютого 2015. Процитовано 25 грудня 2014.
  4. Adida, Ben; Barth, Adam; Jackson, Collin. Rootkits for JavaScript Environments Ben (PDF). 2009. Архів оригіналу (PDF) за 9 грудня 2017. Процитовано 25 грудня 2014.
  5. Mic, Wright (16 липня 2015). British Gas deliberately breaks password managers and security experts are appalled. Архів оригіналу за 1 серпня 2015. Процитовано 26 липня 2015.
  6. а б Reeve, Tom (15 липня 2015). British Gas bows to criticism over blocking password managers. Архів оригіналу за 24 липня 2015. Процитовано 26 липня 2015.
  7. а б Cox, Joseph (26 липня 2015). Websites, Please Stop Blocking Password Managers. It’s 2015. Архів оригіналу за 26 лютого 2019. Процитовано 26 липня 2015.
  8. Password Manager. Архів оригіналу за 19 лютого 2019. Процитовано 26 липня 2015.
  9. а б Hunt, Troy (15 травня 2014). The "Cobra Effect" that is disabling paste on password fields. Архів оригіналу за 29 березня 2016. Процитовано 26 липня 2015.
  10. а б Password Managers: Attacks and Defenses (PDF). Архів оригіналу (PDF) за 13 травня 2016. Процитовано 26 липня 2015.
  11. Firefox on windows 8.1 is autofilling a password field when autocomplete is off. Архів оригіналу за 19 лютого 2019. Процитовано 26 липня 2015.
  12. Sharwood, Simon (9 квітня 2014). Chrome makes new password grab in version 34. Архів оригіналу за 31 липня 2015. Процитовано 26 липня 2015.
  13. Re: 7.0.2: Autocomplete="off" still busted. Архів оригіналу за 6 листопада 2018. Процитовано 26 липня 2015.