Я використовую пропуск для обробки всіх своїх паролів. Вони шифруються за допомогою GPG за допомогою ключа 4096 біт, використовуючи алгоритм SHA256. Я використовую інший пароль для кожного входу в свій магазин паролів.

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

Тоді чи безпечно перенести сховище pass git до приватного сховища GitHub? Якщо ні, то яка слабка ланка?

Термінова відповідь

Добре ставити пропускний рето github.

Докладна відповідь

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

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

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

Ще дві речі, які слід розглянути

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

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

Це буде безпечно, але наражає на вас додаткові ризики порівняно з тим, щоб не розміщувати зберігання паролів у громадському місці.

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

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

Ви коли-небудь розміщували приватну парольну фразу у вікні чату випадково, що вискакувало? Я знаю купу людей, яка це зробила, в тому числі і я.

Це гарне запитання, оскільки в минулому це була проблема, коли хтось ставив приватний пароль у загальнодоступному сховищі.

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

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

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

Редагувати: Я думав про програми в деяких своїх публікаціях, тому я підрізав це, щоб краще відповісти на ваше запитання.

Одним із цікавих особливостей пропуску є те, що все зберігається в папці з приємною ієрархією, яка ідеально підходить для налаштування репортажу git

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

(пропуск навіть забезпечує цю здатність)

Якщо це зробити, використовуючи можливість пропуску. Можливо, це безпечніше. Але вам потрібно відновити свій магазин, використовуючи "pass git init".