Шифрование пароля в Delphi - PullRequest
       232

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

17 голосов
/ 25 сентября 2008

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

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

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

Ответы [ 15 ]

17 голосов
/ 25 сентября 2008

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

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

16 голосов
/ 25 сентября 2008

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

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

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

8 голосов
/ 25 сентября 2008

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

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

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

3 голосов
/ 13 октября 2010

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

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

3 голосов
/ 27 сентября 2008

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

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

3 голосов
/ 25 сентября 2008

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

2 голосов
/ 25 сентября 2008

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

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

2 голосов
/ 25 сентября 2008

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

1 голос
/ 29 сентября 2008

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

Так хранить:

  1. init_str: = 5 случайных байтов
  2. новый_пароль: = соль + пароль // соль: = имя_базы + имя_пользователя
  3. crypted_password = xor_bytes (init_str + new_password, «моя ключевая фраза»)
  4. crypted_password: = init_str + crypted_password
  5. хранить crypted_password в конфигурации, так как это будут байты, которые вы можете шестнадцатеричные или base64 это

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

  1. разделение данных, считанных из конфигурации, на init_str и crypted_password
  2. new_password = xor_bytes (init_str + crypted_password, «моя ключевая фраза»)
  3. пароль: = удалить (имя_базы + имя_пользователя) из нового пароля_1024 *
1 голос
/ 28 сентября 2008

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

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

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

...