Менеджер паролів допомагає генерувати зберігати та вводити складні паролі із зашифрованої бази даних Менеджери паролів м

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

онлайн-сервісів;
локально встановленого програмного забезпечення;
апаратних пристроїв.

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

Типи

Локально встановлене програмне забезпечення

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

Онлайн-сервіси

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

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

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

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

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

Апаратні пристрої

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

Переваги

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

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

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

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

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

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

Недоліки

Вразливості

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

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

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

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

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

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

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

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

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

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

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

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

Див. також

Список менеджерів паролів

Посилання

Price, Rob (22 лютого 2017). . Business Insider (англ.). Архів оригіналу за 27 лютого 2017. Процитовано 29 квітня 2017.
. GitHub (англ.). Архів оригіналу за 6 липня 2017. Процитовано 28 травня 2017.
Li, Zhiwei; He, Warren; akhawe, Devdatta; Song, Dawn. (PDF). 2014. Архів оригіналу (PDF) за 5 лютого 2015. Процитовано 25 грудня 2014.
Adida, Ben; Barth, Adam; Jackson, Collin. (PDF). 2009. Архів оригіналу (PDF) за 9 грудня 2017. Процитовано 25 грудня 2014.
Mic, Wright (16 липня 2015). . Архів оригіналу за 1 серпня 2015. Процитовано 26 липня 2015.
Reeve, Tom (15 липня 2015). . Архів оригіналу за 24 липня 2015. Процитовано 26 липня 2015.
Cox, Joseph (26 липня 2015). . Архів оригіналу за 26 лютого 2019. Процитовано 26 липня 2015.
. Архів оригіналу за 19 лютого 2019. Процитовано 26 липня 2015.
Hunt, Troy (15 травня 2014). . Архів оригіналу за 29 березня 2016. Процитовано 26 липня 2015.
(PDF). Архів оригіналу (PDF) за 13 травня 2016. Процитовано 26 липня 2015.
. Архів оригіналу за 19 лютого 2019. Процитовано 26 липня 2015.
Sharwood, Simon (9 квітня 2014). . Архів оригіналу за 31 липня 2015. Процитовано 26 липня 2015.
. Архів оригіналу за 6 листопада 2018. Процитовано 26 липня 2015.

[1] Price, Rob (22 лютого 2017). . Business Insider (англ.). Архів оригіналу за 27 лютого 2017. Процитовано 29 квітня 2017.

[2] . GitHub (англ.). Архів оригіналу за 6 липня 2017. Процитовано 28 травня 2017.

[emperorsmanager-3] Li, Zhiwei; He, Warren; akhawe, Devdatta; Song, Dawn. (PDF). 2014. Архів оригіналу (PDF) за 5 лютого 2015. Процитовано 25 грудня 2014.

[javascriptenv-4] Adida, Ben; Barth, Adam; Jackson, Collin. (PDF). 2009. Архів оригіналу (PDF) за 9 грудня 2017. Процитовано 25 грудня 2014.

[5] Mic, Wright (16 липня 2015). . Архів оригіналу за 1 серпня 2015. Процитовано 26 липня 2015.

[sc-6] Reeve, Tom (15 липня 2015). . Архів оригіналу за 24 липня 2015. Процитовано 26 липня 2015.

[wired-7] Cox, Joseph (26 липня 2015). . Архів оригіналу за 26 лютого 2019. Процитовано 26 липня 2015.

[8] . Архів оригіналу за 19 лютого 2019. Процитовано 26 липня 2015.

[troy-9] Hunt, Troy (15 травня 2014). . Архів оригіналу за 29 березня 2016. Процитовано 26 липня 2015.

[paper-10] (PDF). Архів оригіналу (PDF) за 13 травня 2016. Процитовано 26 липня 2015.

[11] . Архів оригіналу за 19 лютого 2019. Процитовано 26 липня 2015.

[12] Sharwood, Simon (9 квітня 2014). . Архів оригіналу за 31 липня 2015. Процитовано 26 липня 2015.

[13] . Архів оригіналу за 6 листопада 2018. Процитовано 26 липня 2015.