Keepass2, как разделить ключ и БД на устройствах типа iPhone?

406
CodeRogier

Самый безопасный способ использования keepass - это разделение файла ключа и БД.

Моя первая идея состояла в том, чтобы использовать USB / флэш-карту с файлом ключа, как обычный ключ (и БД в Dropbox), но Apple не любит внешние устройства хранения.

Таким образом, могут использоваться только облачные или интернет-решения. После аутентификации в iOS обычно любой может получить доступ к Dropbox, Google Drive и т. Д., Поскольку эти учетные записи обрабатываются iOS (по крайней мере, если вы хотите, чтобы ваш мобильный опыт был хотя бы немного проще)

Мой рабочий процесс сейчас небезопасен, оба файла находятся в Dropbox. Использование SFTP-сервера в моей локальной сети будет работать, но насколько я знаю, это слишком хлопотно для доступа к нему из Интернета (без фиксированного IP), и я бы предпочел вообще не открывать свою локальную сеть для Интернета.

После такого длинного вступления мой практический вопрос: знает ли кто-нибудь хороший безопасный рабочий процесс для базы данных keepass2 и файлов ключей для всех настольных компьютеров и мобильных устройств (iPhone / ipad)?

Решение, где мне не нужно много паролей для входа в сервисы, чтобы получить мои пароли.

РЕДАКТИРОВАТЬ:

Я перечитал некоторые документы keepass: http://keepass.info/help/base/security.html

Для генерации 256-битного ключа для блочных шифров используется алгоритм Secure Hash SHA-256. Этот алгоритм сжимает пользовательский ключ, предоставленный пользователем (состоящий из пароля и / или файла ключа), в ключ фиксированного размера в 256 бит. Это преобразование является односторонним, то есть вычислительно невозможно инвертировать хеш-функцию или найти второе сообщение, которое сжимается в тот же хеш. Вывод ключа: если используется только пароль (т.е. без файла ключа), пароль плюс 128-битная случайная соль хэшируются с использованием SHA-256 для формирования окончательного ключа (но обратите внимание, что есть некоторая предварительная обработка: защита от атак по словарю). Случайная соль предотвращает атаки, основанные на предварительно вычисленных хэшах.

При использовании файла пароля и ключа окончательный ключ получается следующим образом: SHA-256 (SHA-256 (пароль), содержимое файла ключа), т. Е. Хэш мастер-пароля объединяется с байтами файла ключа и полученным байтом. строка снова хешируется с помощью SHA-256. Если файл ключа не содержит ровно 32 байта (256 бит), они также хэшируются с помощью SHA-256, чтобы сформировать 256-битный ключ. Затем приведенная выше формула меняется на: SHA-256 (SHA-256 (пароль), SHA-256 (содержимое файла ключа)).

Если я правильно понимаю оба пути, только пароль и файл пароль + ключ, то получится один 256-битный ключ / хэш. Таким образом, сила БД одинакова, если у вас есть хороший пароль. Таким образом, дополнительная сила проистекает из того факта, что злоумышленнику нужен ваш ключевой файл для завершения 256 бит.

Кроме того, учитывая упоминание в ссылке мер противодействия атакам по словарю, могу ли я заключить, что при правильном пароле дополнительная защита от файла ключа не перевешивает неудобства в данном конкретном случае?

0
Зачем использовать ключевой файл в первую очередь? Daniel B 7 лет назад 1
Вы задаете не по теме вопрос. Пожалуйста, прочтите [On-Topic] (https://superuser.com/help/on-topic), [Как мне задать хороший вопрос?] (Https://superuser.com/help/how-to-ask) и [Какие типы вопросов мне следует избегать?] (https://superuser.com/help/dont-ask) DavidPostill 7 лет назад 0
http://apple.stackexchange.com/ (и удалите этот вопрос) DavidPostill 7 лет назад 0
Насколько я прочитал, комбинация двух наиболее безопасна. Если это не тот случай, то почему файл ключа на первом месте. И если вы правильно, то это действительно будет хорошим решением. CodeRogier 7 лет назад 0
извините, это не просто яблоко, это проблема для всех устройств, которые не поддерживают внешнее хранилище, например USB или флэш. У меня просто есть яблочный продукт. но проблема все еще держится. CodeRogier 7 лет назад 0
Я сталкиваюсь с одной и той же проблемой, и ключ, и база данных находятся на моем Dropbox. Однако я говорю себе, что это немного лучше, чем просто иметь пароль, потому что злоумышленнику все равно придется найти файл ключа в моем раскрывающемся списке. Несомненно, поиск `* .key` нашел бы это довольно быстро, но случайный идиот, который получает доступ к моему телефону, мог бы не думать об этом ... хотя мой пароль довольно безопасен, он безумно длинный и больше нигде не используется, и Я обновляю его ежегодно (всякий раз, когда KeePass начинает пилить меня ... :)) KEK 7 лет назад 0

0 ответов на вопрос

Похожие вопросы