Де браузер зберігає паролі та чи безпечно довіряти автозаповненню?

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

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

Де фізично лежать збережені паролі

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

Де зберігаються паролі в різних браузерах і як вони синхронізуються

Шлях до профілю Chrome можна побачити на сторінці chrome://version у полі «Шлях до профілю». Саме цей спосіб описано в офіційній документації Chromium. У Firefox достатньо відкрити about:support і знайти «Теку профілю», як пояснюється в довідці Mozilla. Це допомагає зрозуміти, чому на одному комп’ютері два профілі можуть мати різні списки збережених логінів. Переглядати й редагувати самі записи зручніше через вбудований менеджер паролів. Наприклад, на пристроях Apple для цього передбачено окремий застосунок «Паролі».

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

Не менш важливо, де саме зберігається ключ шифрування. У сучасному Chrome для Windows технологія App-Bound Encryption прив’язує захист ключа до браузера, ускладнюючи доступ до нього стороннім програмам. На macOS зашифровані записи Chrome зберігаються у профілі браузера, тоді як ключ захищається системним Keychain. Тому Chrome і Safari на одному Mac можуть використовувати механізми Keychain, але зберігати самі паролі по-різному. Особливості такого захисту детально пояснюються в документації Chromium із безпеки. У Firefox додатковий рівень захисту забезпечує Основний пароль, який захищає доступ до ключа шифрування в key4.db. Його можна налаштувати за офіційною інструкцією Mozilla. Це особливо важливо, якщо хтось отримає копію всього профілю. Системний запит PIN-коду або біометрії перед показом пароля теж створює додатковий бар’єр, хоча захист інтерфейсу та шифрування файлів виконують різні завдання.

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

Як браузер вирішує, куди підставити пароль

Браузер визначає адресу відкритого сайту й шукає відповідні записи серед збережених облікових даних. Потім аналізує форму входу, щоб розпізнати поля логіна та пароля. Розробники сайтів можуть полегшити цей процес за допомогою HTML-атрибутів. Наприклад, autocomplete="current-password" підказує браузеру, що поле призначене для введення чинного пароля. Детальніше цей механізм описано в документації MDN Web Docs. Якщо для одного сайту збережено кілька облікових записів, менеджер може запропонувати вибрати потрібний. А коли авторизація відбувається у два етапи, спочатку може з’явитися лише поле логіна. Водночас автозаповнення працює не завжди: результат залежить від структури сторінки, налаштувань браузера та самого менеджера. Зокрема, у довідці Google Chrome пояснюється, чому браузер іноді не розпізнає поля входу й не пропонує збережені паролі.

Уяви дві майже однакові сторінки авторизації. Перша розташована за адресою login.example.com, а друга за login.example.net. Якщо пароль збережено для першого сайту, зовнішня схожість другої сторінки ще не означає, що менеджер запропонує на ній ті самі облікові дані. Для зіставлення записів використовуються правила перевірки адрес, які можуть враховувати піддомени, пов’язані сайти та інші параметри. Наприклад, Bitwarden дозволяє налаштовувати різні способи зіставлення URL, від перевірки базового домену до точного збігу адреси. Тому якщо після переходу з електронного листа чи месенджера звичний логін раптом не з’являється, варто уважніше перевірити адресу сайту. Проте відсутність автозаповнення сама по собі не доводить фішинг: сайт міг змінити форму входу, ти міг відкрити інший профіль браузера або просто вимкнути відповідні підказки.

Автозаповнення стає особливо корисним, коли менеджер створює довгий унікальний пароль для кожного сайту. Його не потрібно запам’ятовувати, вводити вручну чи постійно копіювати через буфер обміну. До того ж компрометація одного сервісу не дасть зловмисникам готового пароля до інших акаунтів. Ще далі пішла технологія ключів доступу, або passkeys, яку активно розвиває FIDO Alliance. Замість передавання пароля серверу вона використовує криптографічну пару ключів: приватний залишається під контролем користувача, а сайт перевіряє цифровий підпис за допомогою відкритого ключа. Такий механізм прив’язаний до справжнього домену сервісу, тому підроблена сторінка на сторонньому сайті не може просто виманити той самий секрет через звичайну форму входу.

Окремої уваги потребує зміна пароля. Коли користувач натискає «Змінити пароль», сайт може попросити ввести стару комбінацію для підтвердження, а менеджер запропонує згенерувати нову. Після успішної зміни важливо переконатися, що сховище оновило запис саме для потрібного облікового запису. Інакше під час наступного входу браузер може підставити застарілий пароль, який сайт уже не прийматиме. У налаштуваннях Google Password Manager також можна керувати автоматичним входом, збереженням паролів та іншими параметрами. Зокрема, вимкнення автоматичного входу дозволяє залишити автозаповнення, але вимагати додаткового підтвердження перед авторизацією.

Як пароль опиняється на новому ноутбуці

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

У Chrome паролі можуть зберігатися локально або в обліковому записі Google. Для додаткового захисту передбачено різні механізми шифрування. Зокрема, Google Password Manager підтримує шифрування на пристрої, за якого ключі для розшифрування залишаються під контролем користувача. Для доступу до паролів можна використовувати пароль Google Account або блокування екрана сумісного мобільного пристрою. Окремо Chrome дозволяє створити власну фразу шифрування синхронізованих даних. У такому разі для доступу до них на новому пристрої потрібно знати цю фразу, а перегляд збережених паролів через passwords.google.com стає недоступним. Якщо скинути фразу шифрування, захищені нею дані видаляються із серверів Google, тому перед такою операцією важливо переконатися, що потрібні паролі не будуть втрачені.

У Firefox та Safari наскрізне шифрування використовується відповідно у Firefox Sync та iCloud Keychain. Це означає, що синхронізовані паролі захищені криптографічними ключами, необхідними для їх розшифрування. Водночас механізми відновлення доступу відрізняються. Наприклад, Mozilla попереджає про ризик втрати синхронізованих даних, якщо користувач скине пароль облікового запису без заздалегідь створеного ключа відновлення. У випадку Apple доступ до iCloud Keychain на новому пристрої також передбачає додаткові перевірки, пов’язані з довіреними пристроями та захистом облікового запису. Як пояснюється в документації Apple з безпеки iCloud Keychain, система використовує наскрізне шифрування, щоб захищати паролі навіть під час їх зберігання у хмарі. Тому перед скиданням пароля, зміною пристрою або очищенням старого ноутбука варто перевірити доступність усіх необхідних засобів відновлення.

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

Що станеться, якщо хтось отримає доступ

На питання «чи можуть викрасти всі мої паролі?» немає однозначної відповіді. Усе залежить від того, до чого саме отримав доступ зловмисник. Вимкнений ноутбук, розблокований браузер і захоплений акаунт синхронізації створюють різні ризики, тому й способи захисту відрізняються.

1. Вкрали вимкнений ноутбук. У такій ситуації одним із головних бар’єрів стає шифрування диска. Наприклад, Microsoft BitLocker у Windows та Apple FileVault на Mac захищають інформацію від несанкціонованого читання, поки диск належним чином заблокований. Навіть якщо зловмисник фізично витягне накопичувач і підключить його до іншого комп’ютера, без ключа розшифрування отримати доступ до даних буде значно складніше. Це важливо й для браузерних профілів, адже шифрування окремих паролів не завжди означає, що всі інші файли профілю захищені так само.

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

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

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

Чи вистачить браузера, чи краще взяти окремий менеджер?

Google Password Manager, вбудований менеджер Firefox та Apple Passwords уже мають усе необхідне для повсякденного керування паролями: зберігають облікові дані, пропонують їх під час авторизації та допомагають створювати унікальні комбінації для різних сайтів. Якщо ти переважно користуєшся одним браузером або пристроями Apple, цих можливостей цілком може вистачити. Головне не те, який саме менеджер встановлено, а наскільки правильно ти ним користуєшся. Навіть найзахищеніше сховище не врятує, якщо для пошти, соцмереж і банківських сервісів використовується один пароль.

• Bitwarden або 1Password стануть у пригоді тим, хто працює одразу з кількома операційними системами та браузерами. Наприклад, на роботі використовує Windows і Firefox, удома Mac, а на смартфоні взагалі інший браузер. Окремий менеджер дозволяє користуватися єдиним сховищем незалежно від браузерного профілю та підставляти паролі в різних застосунках. При цьому Bitwarden використовує основний пароль як один із ключових механізмів захисту сховища, а в 1Password додатково застосовується Secret Key, який працює разом із паролем акаунта для шифрування даних. Такий підхід створює додатковий бар’єр для зловмисників, навіть якщо вони отримають доступ до зашифрованої серверної копії сховища.

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

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

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

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