KeePass: використовувати файл ключа або звичайний пароль?

17

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

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

— RCIX
джерело

17

Щодо можливості використання ' key files' з KeePass .

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

Нещодавно виявлена атака проти SHA-1 не впливає на безпеку SHA-256. SHA-256 як і раніше вважається дуже безпечним .

(є ще одне нещодавнє оновлення , але я думаю, такі новини тут не актуальні ).
До речі ,

Виведення ключа :
Якщо використовується лише пароль (тобто немає файлу ключів), пароль та 128-бітна випадкова сіль хешируються за допомогою SHA-256 для формування остаточного ключа (але зауважте, що є деяка попередня обробка: Захист від атакових словників). Випадкова сіль запобігає атакам, які ґрунтуються на попередньо обчислених хешах.

Під час використання як пароля, так і ключа ключа, остаточний ключ виводиться наступним чином: SHA-256 (SHA-256 (пароль), вміст ключового файлу), тобто хеш головного пароля з'єднується з байтами ключового файлу та отриманим байтом рядок повторно хешируется з SHA-256 . Якщо файл ключових файлів не містить точно 32 байти (256 біт), вони також хешируются разом із SHA-256 для формування 256-бітного ключа. Вищезгадана формула змінюється на: SHA-256 (SHA-256 (пароль), SHA-256 (вміст ключового файлу)).

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

— нік
джерело

Я поглянув на коментар Стіва Гібсона до цього питання: grc.com/sn/sn-182.txt

— jasonh

@jasonh, вау! ти голосуєш за те, що я пропонував забезпечити двофакторну безпеку, з Gibsonпосиланням на інтерв'ю, яке ви взяли з його власного сайту (так, я раніше Лео чув, чудово). Будь ласка, додайте тут свої бали як нову відповідь, щоб люди могли отримати користь.

— nik

7

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

— Jasonh

2

Другий фактор корисний у прикладі футболу PayPal. У цьому випадку у вас є фізичний пристрій і пароль. Якщо ваш пароль стає порушеним, немає підстав вважати, що ваш футбол одночасно відсутній. Для порівняння, якщо товари - це база даних паролів, а механізм захисту - це просто ще один файл, який знаходиться поруч із самою базою даних, що це добре? Жоден.

— Jasonh

2

+1 для використання ключа ключа та основного пароля. Тож навіть якщо вони отримують файл db та key, ви просто повинні запам'ятати 1 довгий пароль. Вони поки не можуть зламати мізки, тому натомість пройдуть тренування щодо протидії катуванням.

— Пьотр Кула

5

Вся справа в тому, щоб захистити ваші паролі, тож це не просто: «пароль». Якщо ви використовуєте файл ключових даних і втрачаєте контроль над своєю базою даних паролів, всі ваші паролі будуть відкриті.

— ясон
джерело

4

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

— Сем

1

При одночасному використанні пароля і ключового файлу , остаточний ключ визначається наступним чином : SHA-256(SHA-256(password), key file contents). Доступ до файлу самостійно марний. Але знання пароля без вмісту файлу робить його складніше. Файл також додає saltваші паролі.

— nik

1

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

— Павка
джерело

1

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

— Torbjørn

0

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

— dotnetspec
джерело

1

Це не дає відповіді на (дуже конкретне) запитання.

— Мокубай

-1

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

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

Нарешті, я завантажую KeePass і встановлюю його на ПК, використовую ключ і .kdbx разом із моїм паролем бази даних, і все!

Звичайно, я видаляю як .kdbx, так і файл ключів на використаному ПК.

— Роджер Джонсон
джерело

10

Я вважав би цю погану практику безпеки на багатьох рівнях.

— kluka

1

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

— nanker

@nanker як ти тоді використовуєш свій особистий пароль db на своєму робочому ноутбуці? У вас є ключ файлів і база даних на ключі usb?

— RED_

2

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

— nanker