Ищете безопасный портативный способ хранения паролей

Вы можете использовать базу данных SQLite. Поскольку это всего лишь файл, вы можете использовать стандартные права доступа к файлам, чтобы ограничить доступ. например chmod 600 foo.dbs ограничит доступ к файлу, чтобы только владелец мог читать и писать в него.

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

Ходят слухи, что существует коммерческая версия SQLite, которая шифрует весь файл базы данных. Однако это не должно быть заменой хранения хешированных паролей, а просто дополнением к хешированию.

изменить: вот ссылка на коммерческая версия sqlite с поддержкой шифрования всей БД.

Для входа в систему вы хотите сохранить повторный соленый хэш пароля, а не сам пароль. Две возможности:

• bcrypt — модифицированная форма иглобрюха, увеличивающая коэффициент работы.
• PBKDF2 — функция из спецификации PKCS#5, которая использует HMAC с хеш-функцией и случайной солью для многократного повторения пароля.

Однако это не будет работать с вашими требованиями:

• Поддержка удаленного восстановления пароля

Я надеюсь, вы сможете убедить клиента, что на самом деле он имеет в виду сброс пароля, и в этом случае вы все равно можете использовать хэш пароля.

• Поддержка извлечения данных при случайном/преднамеренном удалении

Это требование сложнее обойти, и вам потребуется ослабить безопасность, сохранив зашифрованные пароли в базе данных, чтобы их можно было отменить. Для этого вы должны использовать мастер-ключ, зашифровать каждый пароль случайным IV, используя шифр, такой как режим AES/CBC или AES/CTR. Вы должны регулярно менять главный ключ и заново шифровать все пароли. Затем вам понадобится механизм для определения того, когда разрешить извлечение пароля (например, девичью фамилию матери и т. д.).

Чтобы использовать пароль для шифрования данных, используйте функцию PKDF2 из PKCS#5 для создания ключа из пароля.

Никогда не сохраняйте сам пароль. Хэшируйте пароль с помощью соли и сохраните его.

Я не совсем уверен, что полностью понимаю ваш вопрос. Но в любом случае. Как насчет настройки пользователя «FooUser» (при условии, что ваш продукт «Foo»). Сохраните файл/базу данных в месте с разрешениями на чтение/запись только для пользователя FooUser. Доступ к файлу/базе данных через сервис/демон, выдающий себя за FooUser.

Прежде всего, никогда не храните пароль в текстовом виде, а храните его хэш. Использование соли также является хорошей идеей, если вы ожидаете, что количество пользователей станет достаточно большим, чтобы иметь конфликты паролей.

Вам действительно нужно хранить пароли во всех системах, или вы можете обойтись централизованным сервером паролей? Если решение на основе сервера приемлемо, то приличная схема ответа на запрос может аутентифицировать людей, не раскрывая их пароль. или его хеш. Защищайте связь с сервером с помощью сертификатов, чтобы затруднить подделку, а затем просто не разрешайте доступ к хранилищу паролей на сервере с помощью любых подходящих средств, которые могут зависеть от ОС, поскольку существует только один, или просто не разрешайте пускать людей на сервер.

Я думаю, что правильный путь:

• в памяти вы объединяете имя пользователя + пароль + какой-то файл cookie (скажем, меган фокс»).

Затем вы применяете к нему коммерческий хеш-алгоритм. Я использую SHA (System.Security.Cryptography.SHA1CryptoServiceProvider) из .NET Framework, но я уверен, что это не проблема заставить его работать на C++ или, возможно, получить его для C++.

Таким образом, даже если кто-то просматривает сохраненный хэш, он никак не может узнать пароль. Если он захочет сравнить идентичные пароли, он ничего не получит из-за конкатенации имени пользователя и файла cookie. Ваш код входа должен создать хэш и сравнить его с сохраненным.

Проблема в том, что вы не можете восстановить пароль. Но я думаю, что это что-то хорошее.

Надеюсь это поможет.