Перейти до вмісту
Цю сторінку перекладено автоматично; можливі неточності.Переглянути оригінал англійською

KeeChallenge для YubiKey і чому його варто уникати

KeeChallenge — це плагін, який додає підтримку YubiKey до KeePass 2. Однак він має низку проблем. У цій статті ми розглянемо ці проблеми та альтернативні рішення.

Як працює KeeChallenge

KeeChallenge шифрує базу паролів секретним ключем HMAC (S). Цей ключ зберігається в YubiKey і використовується для генерування відповідей. Крім того, KeeChallenge шифрує S за допомогою попередньо обчисленої пари «виклик-відповідь» і зберігає зашифрований секрет та виклик у допоміжному XML-файлі.

Коли ви розблоковуєте базу паролів:

  1. KeeChallenge завантажує виклик C з XML-файлу і надсилає його до YubiKey
  2. YubiKey перетворює виклик (використовуючи секрет S, що зберігається в ключі) і повертає відповідь R
  3. Відповідь R використовується для розшифрування секрету Senc, що зберігається в XML-файлі.
  4. Розшифрований секрет S використовується для розшифрування бази паролів. Важливо, що це той самий секрет, який зберігається в YubiKey.
  5. KeeChallenge повторно генерує XML-файл (створює новий випадковий виклик C, обчислює нову відповідь R, шифрує S за допомогою R' і зберігає оновлені C та Senc у XML-файлі)

Докладніше дивіться на повній діаграмі робочого процесу.

Проблеми KeeChallenge

Підхід KeeChallenge має кілька проблем з безпекою:

  • Секретний ключ ніколи не змінюється, він лише перешифровується. З погляду KeePass, KeeChallenge нічим не відрізняється від статичного файла-ключа, який щоразу надає ті самі байти.
  • Як наслідок, KeeChallenge повністю відкритий для атаки повторного відтворення. Будь-який із попередніх XML-файлів можна використати для розшифрування бази паролів. Тобто рандомізація виклику та перешифрування секрету не мають жодного сенсу — це театр безпеки.
  • Секрет ніколи не повинен залишати YubiKey — у цьому й полягає суть апаратного ключа, доступного лише для запису. KeeChallenge порушує цей принцип, передаючи секрет на комп'ютер. Теоретично зловмисник може скопіювати S з пам'яті процесу, клонувати YubiKey власника без його відома і розшифрувати будь-яку майбутню версію бази паролів (оскільки секрет статичний).

Крім того, є кілька пов'язаних проблем:

  • Розробник з Yubico повідомив про проблему безпеки ще у 2016 році. Станом на 2024 рік проблема досі не вирішена.
  • KeeChallenge виглядає покинутим — суттєвих оновлень не було з 2016 року.
  • Супровідник проєкту не відповідає на повідомлення про проблеми.

Краща альтернатива

Альтернативний підхід було запроваджено в KeePassXC, і його підтримують усі сумісні застосунки:

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

Цей підхід має кілька важливих переваг перед KeeChallenge:

  • Ключ, отриманий від YubiKey, є динамічним — він змінюється під час кожного збереження бази паролів. (У KeeChallenge ключ шифрування залишається незмінним, фактично імітуючи статичний файл-ключ.)
  • Секрет HMAC ніколи не залишає апаратний ключ, тому YubiKey неможливо непомітно клонувати.
  • Немає допоміжного XML-файлу — лише сама база паролів.
  • Цей підхід підтримують кілька активних команд розробників.

З описаних вище причин KeePassium реалізує підхід KeePassXC. Підтримка баз паролів, зашифрованих за допомогою KeeChallenge, не планується.

Якщо ваша база паролів захищена KeeChallenge — розгляньте перехід на KeePassXC і KeePassium. Ця комбінація забезпечить вам безпечніше, суміснішe рішення, що активно підтримується.

Дивіться також