Шифрование данных в таблице алгоритмом Blowfish
Автор osmor   
26.05.2010 г.

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

 

В примере представлен один из способов шифрования данных с использованием  криптографического алгоритма Blowfish, реализующего блочное симметричное шифрование.

Шифрование и расшифровка данных производится ключем сгенерированным на основе пароля введенного пользователем. Никакой авторизации в данном примере не предусмотрено умышленно, что бы показать работу именно механизма шифрования. В случае введения неверного пароля данные будут показаныв зашифрованном виде.

Есть процедура смены пароля.

Внимание!

При смене пароля нет проверки на правильность ввода старого пароля, если его ввести неверно данные будут испорчены.

 

В реальном приложении можно/нужно предусмотреть авторизацию и проверку пароля при смене на основании хеша правильного пароля который можно получить используя этот же алгоритм.

 

При разработке примера использованы материалы сайта http://www.di-mgt.com.au/crypto.html. На указанном сайте очень много материалов посвященных различным алгоритмам шифрования и их реализациям на различных языках программирования.

 

 

 

Download now

Просмотров: 16159

  Коментарии (17)
 1 Написал(а) Алексей, в 09:43 28.05.2010
Пример впечатлил, только не понятно, допустим я хочу применить другой пароль как это можно изменить?
 2 Написал(а) Алексей, в 12:16 28.05.2010
Иными словами как сгенерировать новый ключ на основании другого пароля
 3 Написал(а) osmor, в 06:02 31.05.2010
Алексей, для смены пароля нужно расшифровать данные старым ключем, затем зашифровать новым и сохранить в таблице, сделать это можно запросом на обновление
 4 Написал(а) Алексей, в 11:19 31.05.2010
Что-то не получилось у меня. (простите за бестолковость). Если я правильно понял, то меняется аргумент функции SetKey. Если у уважаемого автора будет время и желание, может дополните пример. Заранее спасибо.
 5 Написал(а) osmor, в 13:57 31.05.2010
Добавил процедуру смены пароля
 6 Написал(а) Алексей, в 05:31 01.06.2010
Спасибо !!!
 7 Написал(а) Алексей, в 11:56 09.06.2010
Непонятно, возможно ли полностью снять шифрование с данных, что бы иметь возможность видеть в таблице первоначально введенные незашифрованые данные
 8 Написал(а) osmor, в 11:59 09.06.2010
Алексей, можно. Это происходит при смене пароля. А зачем? В чем тогда смысл?
 9 Написал(а) Алексей, в 12:40 09.06.2010
Да я тоже так понял, что при смене пароля данные первоначально дешифруются. 
 
Дело в том, что я не смог в примере увидеть в таблице чистые дешифрованные данные. В связи с этим и вопрос. В перспективе думаю использовать этот метод при авторизации пользователей на предмет разделения прав просмотра информации. Но пока непонятно с таблицей. Не исключено что я сам не до конца понимаю функционал данного примера
 10 Написал(а) osmor, в 12:52 09.06.2010
[b]\"то я не смог в примере увидеть в таблице чистые дешифрованные]данные\"[/b] 
Алексей, в этом и есть задача шифрования, что бы данные хранились в зашифрованном виде. Какой смысл хранить расшифрованные данные? Их сможет увидеть тот кому не положено. 
Если вы не собиратесь шифровать данные, а хотите только хранить зашифрованные пароли, то вам лучше посмотреть вот этот пример: 
http://hiprog.com/index.php?option=com_content&task=view&id=251661648&Itemid=35

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

 

В примере представлен один из способов шифрования данных с использованием  криптографического алгоритма Blowfish, реализующего блочное симметричное шифрование.

Шифрование и расшифровка данных производится ключем сгенерированным на основе пароля введенного пользователем. Никакой авторизации в данном примере не предусмотрено умышленно, что бы показать работу именно механизма шифрования. В случае введения неверного пароля данные будут показаныв зашифрованном виде.

Есть процедура смены пароля.

Внимание!

При смене пароля нет проверки на правильность ввода старого пароля, если его ввести неверно данные будут испорчены.

 

В реальном приложении можно/нужно предусмотреть авторизацию и проверку пароля при смене на основании хеша правильного пароля который можно получить используя этот же алгоритм.

 

При разработке примера использованы материалы сайта http://www.di-mgt.com.au/crypto.html. На указанном сайте очень много материалов посвященных различным алгоритмам шифрования и их реализациям на различных языках программирования.

 

 

 

Download now

Просмотров: 16159

  Коментарии (17)
 11 Написал(а) Алексей, в 14:02 09.06.2010
Спасибо за комментарии. Вроде разобрался
 12 Написал(а) Алексей, в 09:40 10.06.2010
А если режим многопользовательский. Таблицы с зашифрованными данными лежат на сервере, В клиентской части они как присоединенные. Я правильно понимаю что каждый клиент также при запуске Приложения и вводе пароля может с ними работать и при этом добавляемые им данные будут корректно видеться на машинах других пользователей ?
 13 Написал(а) Алексей, в 11:34 10.06.2010
Простите, а как мне правильно использовать функцию DecryptString в запросе если каждое поле таблицы у меня зашифровано своим собственным паролем
 14 Написал(а) osmor, в 12:49 10.06.2010
Алексей, задавайте вопросы в форуме. 
По вопросу 12. 
Да данные будут видны нормально, они будут расшифровываться запросом. 
По вопросу 13.  
Можно сделать несколько функций. но это будет сильно тормозить, т.к. постоянно будет вычисляться новый набор клбчей по паролю, а это медленная операция
 15 Написал(а) Этот e-mail защищен от спам-ботов. Для его просмотра в вашем браузере должна быть включена поддержка Java-script , в 20:26 10.06.2010
Доброго времени суток. А где на форуме ? У меня вопрос: если база многопользовательская (у каждого свой пароль, разделение прав) - как сделать шифрование (сделать составной пароль: часть одинаковая для всех для шифровки, и часть разная ?). Сохранение пароля в базе - не вариант (легко можно прочитать). Пароли пользователей сохраняются в хеше. 
PS. Большое спасибо за модули - очень выручили.
 16 Написал(а) osmor, в 07:19 11.06.2010
форум - http://hiprog.com/forum 
IMHO, для Вас предложенный вариант не очень подходит, Вам лучше посмотреть в сторону систем с ассимитричным шифрованием (с открытым ключем). 
Вообще стоит подумать нужно ли шифровать данные которые находятся в той части которая одинаковая для всех. Поскольку шифрование это дополнительная нагрузка, то можно выбрать компромисное решение, шифровать только часть данных. Например не нужно шифровать все 3 поля ФИО, достаточно только фамилию. В адресе только улицу.
 17 Написал(а) Этот e-mail защищен от спам-ботов. Для его просмотра в вашем браузере должна быть включена поддержка Java-script , в 11:51 11.06.2010
Данные нужно защитить от сторонних (в случае получения доступа к таблицам). Посмотрел ассиметричное шифрование - все равно нужно будет держать в базе секретные части ключа; и как его реализовать, если введенные одним пользователем данные должны читатать и редактировать все ?

Добавить коментарий
Имя:
E-mail
Коментарий:



Код:* Code