Шифрование паролей в Delphi

Мне нужно хранить пароли базы данных в файле конфигурации. По очевидным причинам я хочу их зашифровать (желательно с AES). Кто-нибудь знает реализацию Delphi, которую легко внедрить в существующий проект s > 10000 строк исторически выращенного (URGH!) Исходного кода?

Уточнение: простота означает добавление единицы в проект, добавление макс. 5 строк кода, где файл конфигурации читается и выполняется с ним. Не требуется более 15 минут.

Еще одно пояснение. Пароль необходим для создания соединения с db, а не для поддержки схемы управления пользователями для приложения. Поэтому использование хешей не помогает. Драйвер db проверяет, действительно ли пароль, а не приложение.

Ответ 1

Вторые рекомендации для David Barton библиотека DCPCrypt. Я использовал его успешно в нескольких проектах, и это не займет больше 15 минут после того, как вы прочитали примеры использования. Он использует лицензию MIT, поэтому вы можете свободно использовать ее в коммерческих проектах и в противном случае. DCPCrypt реализует ряд алгоритмов, включая Rijndael, который является AES.

Существует много автономных (одноуровневых) реализаций для googlable - вопрос заключается в том, кому вы доверяете, если только вы не готовы самостоятельно проверить исправление конкретной библиотеки.

Ответ 2

Для типичной проверки подлинности вам не нужно хранить пароли, вам нужно только проверить правильность введенного пользователем пароля. Если это ваш случай, вы можете просто сохранить хеш-подпись (например, MD5) и сравнить ее с сигнатурой введенного пароля. Если две подписи соответствуют введенному паролю, это правильно.

Сохранение зашифрованных паролей может быть опасным, потому что, если кто-то получает ваш "главный" пароль, они могут извлекать пароли всех ваших пользователей.

Если вы решите использовать MD5, вы можете использовать MessageDigest_5.pas, который поставляется с Delphi (по крайней мере, он включен в мою копию Delphi 2007). Существуют также другие реализации с исходным кодом Delphi, который вы можете выбрать.

Ответ 3

Я думаю, что Turbopower LockBox - отличная библиотека для криптографии:

http://sourceforge.net/projects/tplockbox/

Я не знаю, слишком ли он для ваших целей, но он очень прост в использовании, и вы можете зашифровать строку с помощью 5 строк кода. Это все в примерах.

Ответ 4

Тондрей имеет правильный подход. Вы никогда не должны хранить пароль, используя обратимый cypher. Как было правильно указано, если ваш "главный" ключ был взломан, вся система скомпрометирована. Использование нереверсивного хэша, такого как MD5, намного более безопасно, и вы можете сохранить хешированное значение как чистый текст. Просто введите введенный пароль и затем сравните его с сохраненным хешем.

Ответ 5

Я всегда пользовался TurboPower Lockbox. Он хорошо работает и очень прост в использовании. Я фактически использую его точно так же, сохраняя пароль в текстовом файле конфигурации.

http://sourceforge.net/projects/tplockbox/

Ответ 6

TurboPower LockBox 3 (http://lockbox.seanbdurkin.id.au/) использует автоматическое засоление. Я рекомендую против Barton DCPCrypt, потому что IV не соленые. В некоторых ситуациях это очень серьезный недостаток в зрелости.

В отличие от более раннего набора, реализация AES LB3 полностью соответствует стандарту.

Ответ 7

Я использовал эту библиотеку, очень быстро добавленную. Но wiki показывает несколько других решений.

Ответ 8

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

То, что вы хотите, это односторонний хеш.

Ответ 9

Просто напоминание.

Если вам не нужно взаимодействовать с другими crypt libs, тогда DCP или LockBox выполнили бы эту работу.

НО

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

Ответ 10

Как указывали другие, для целей аутентификации вам следует избегать хранения паролей с использованием обратимого шифрования, т.е. вы должны хранить хэширование пароля и проверять хэш пароля, предоставленного пользователем, в отношении сохраненного вами хэша. Однако этот подход имеет недостаток: он уязвим для rainbow table, если злоумышленник завладеет вашей базой данных хранилища паролей.

Что вам нужно сделать, это сохранить хэши предварительно выбранного (и секретного) значения соли + пароль. I.e., Соедините соль и пароль, хэш-результат и сохраните этот хеш. При аутентификации выполните то же самое - соедините значение соли и пароль пользователя, хэш, затем проверьте равенство. Это делает невозможным использование радужных столов.

Конечно, если пользователь отправляет пароли по сети (например, если вы работаете с веб-или клиент-серверным приложением), вам не следует отправлять пароль в виде открытого текста, поэтому вместо хранения хэша (соль + пароль), вы должны хранить и проверять хеш (соль + хеш (пароль)), а клиент должен предварительно ввести пароль пользователя и отправить его по сети. Это также защищает ваш пароль пользователя, если пользователь (как многие из них) повторно использует один и тот же пароль для нескольких целей.

Ответ 11

Я рекомендую использовать какой-то тип соли. Не храните crypt (пароль) в файле конфигурации, но инсталлируется в этом склепе магазина (соль + пароль). Как "соль" вы можете использовать то, что требуется для открытия базы данных, например. db_name + user_name. Для функции криптографии вы можете использовать какой-то известный алгоритм AES, Idea, DES или что-то такое же простое, как xoring каждый байт с байтом из какой-либо другой строки, эта строка будет вашим ключом. Чтобы сделать его более разным, вы можете использовать некоторые случайные байты и хранить их.

Итак, чтобы сохранить:

init_str: = 5 случайных байтов
new_password: = соль + пароль//соль: = имя_базы + имя_пользователя
crypted_password = xor_bytes (init_str + new_password, 'my keyphrase')
crypted_password: = init_str + crypted_password
хранить crypted_password в config, так как это будут байты, которые вы можете использовать hexify или base64.

И для подключения:

разделять данные, считанные из config, в init_str и crypted_password
new_password = xor_bytes (init_str + crypted_password, 'my keyphrase')
password: = удалить (db_name + имя_пользователя) из new_password

Ответ 12

Ник, конечно, прав - я просто предполагаю, что вы знаете, что делаете, когда говорите, что хотите потратить все 15 минут на реализацию решения безопасности. Библиотека DCPCrypt также реализует ряд алгоритмов хеширования, если вы решите пройти этот (лучший) маршрут.

Ответ 13

Несколько решений:

Не храните пароль вообще. Если база данных поддерживает интегрированные аутентификации, используйте его. Процесс может быть настроен на запуск с определенным идентичность и автоматически заверенная базой данных
Использовать хранилища сертификатов Windows и сертификат для шифрования вашего пароля. Если вы храните ключ, используемый для шифрования ваш пароль в вашем приложении, в любом случае у вас очень мало безопасности, вы также должны защитить ключ.

Ответ 14

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

В принципе есть два способа сделать это:

Сохраните его в зашифрованном файле EFS.
Сохраните его в защищенном локальном хранилище.

Internet Explorer использует 2. Но если вы можете получить локальный доступ, вы можете расшифровать как 1., так и 2. если у вас есть правильный главный ключ и алгоритм (например, iepv может получить пароли Internet Explorer).

Итак:
Если можно, не храните пароли.
Сначала найдите альтернативы (например, аутентификация Windows, службы каталогов и т.д.).

- Йерун

Ответ 15

Простая, но для большинства приложений достаточно сильная система предоставляется этой демонстрацией Embarcadero: https://edn.embarcadero.com/article/28325