Криптография данных в БД

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

Всем рейтинг.

читай книжки там все написано
юзай md5

Я не программист и мои знания программирования заканчиваются только названиями языков. Я пробывал читать. Всё что там написано для меня китайская грамота

Каковы + и - md5?
И что по поводу множества скриптов, которые лежат в инете и крякают захешенные md5 пароли? Например http://passcracking.ru/ru/

скажу одно md5 надежен!

по поводу тех скриптов, они не крякают md5 они работают перебором по словарю, т.е. если у тебя пароль простое слово из 2-4х букв найдут быстро перебором по словарю md5 хэшей простых паролей.

Просто нужно использовать длинные пароли...
http://xpoint.ru/forums/internet/security/thread/16323.xhtml
http://www.google.ru/search?sourceid=navclient&ie=UTF-8&rls=GGLJ,GGLJ:2006-46,GGLJ:en&q=md5+%d0%bd%d0%b0%d0%b4%d0%b5%d0%b6%d0%bd%d0%be%d1%81%d1%82%d1%8c

bleed писал:

скажу одно md5 надежен! http://www.google.ru/search?sourceid=navclient&ie=UTF-8&rls=GGLJ,GGLJ:2006-46,GGLJ:en&q=md5+%d0%bd%d0%b0%d0%b4%d0%b5%d0%b6%d0%bd%d0%be%d1%81%d1%82%d1%8c

Ответ
http://www.google.ru/search?hl=ru&newwindow=1&rls=GGLJ%2CGG…BA&lr=

Я не пытаюсь говорить что это плохо. Я пытаюсь объективно посмотреть на вещи.

+1 за MD5

DeniF писал:

Ответ http://www.google.ru/search?hl=ru&newwindow=1&rls=GGLJ%2CGG…BA&lr= Я не пытаюсь говорить что это плохо. Я пытаюсь объективно посмотреть на вещи.

кинь прямой линк, плиз, я пьяный в гугле шарится ломает...

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

Вообще-то md5 это необратимая функция.
Со всеми втекающими и вытекающими последствиями, не позволяющими

Цитата:

Но если зайти через админку, что бы пароль мог отображаться.

Обычно пароли не хранятся в "чистом" виде, а производится обработка односторонней функцией, подобной md5. Восстановить пароль, то есть подобрать такое х чтобы
md5(x)=md5(пароль)
достаточно сложно, однако методы существуют.

Вообще топикстартер, на подобные вопросы должны отвечать люди, которые будут проектировать тебе систему

для md5 возможна коллизия, т.е. другая строка с таким же мд5.

ghood писал:

Вообще-то md5 это необратимая функция. Со всеми втекающими и вытекающими последствиями, не позволяющими Обычно пароли не хранятся в "чистом" виде, а производится обработка односторонней функцией, подобной md5. Восстановить пароль, то есть подобрать такое х чтобы md5(x)=md5(пароль) достаточно сложно, однако методы существуют. Вообще топикстартер, на подобные вопросы должны отвечать люди, которые будут проектировать тебе систему

Наконец-то хоть кто-то прочитал внимательно первоначальный пост
Давайте на примере:

Например генерируется пароль вида: Lsu39Cc2 (8 символов, большие, малые буквы и цифры, без спец. символов). Этот пароль хранится в зашифрованном виде в базе данных (если не дай Бог базу сопрут, то прочесть будет не возможно). Если пользователь при входе в систему вводит пароль Lsu39Cc2, то система пароль принимает и пропускает в админку. С другой стороны, если админ системы, просматривает профайл пользователя через браузер, он должен видеть ЯВНОЕ отображение пароля, то есть Lsu39Cc2.
Иными словами - шифровка только в БД. И дешифровка при отображении информации через браузер.

mcrypt - рыть в эту сторону.

DeniF писал:

С другой стороны, если админ системы, просматривает профайл пользователя через браузер, он должен видеть ЯВНОЕ отображение пароля, то есть Lsu39Cc2.

нахера?

Stek писал:

для md5 возможна коллизия, т.е. другая строка с таким же мд5.

на сколько я знаю это еще никто не доказал опытным путем но и не опроверг...

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

Много букв на русском
http://www.nestor.minsk.by/sr/2005/04/sr50416.html
на анлицком
http://www.schneier.com/blog/archives/2005/03/more_hash_funct.html

Последний раз редактировалось: Stek (18/03/07 в 07:21), всего редактировалось 1 раз

DeniF писал:

С другой стороны, если админ системы, просматривает профайл пользователя через браузер, он должен видеть ЯВНОЕ отображение пароля, то есть Lsu39Cc2. Иными словами - шифровка только в БД. И дешифровка при отображении информации через браузер.

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

Stek писал:

на анлицком http://www.schneier.com/blog/archives/2005/03/more_hash_funct.html

читал на англицком, вникал, думал, и тут последний камент отжог просто, валялся под стулом

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

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

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

bleed писал:

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

Блин, кто-нибудь будет читать то, что я пишу?

Я написал что это ПРИМЕР!. Ок. Должны быть зашифрованы Имя и Фамилия клиента, его индентификационные данные (номера ID или паспорта) и номер его сотового телефона для sms банкинга. Имя и Фамилию клиента, а так же его ID надо для возможного изменения из админки, номер телефона для изменения самим клиентом.
Функции изменения и просмотра таких данных будет только у 2-х людей в компании, а не у "простого" в нашем понимании админа.

DeniF писал:

Блин, кто-нибудь будет читать то, что я пишу? Я написал что это ПРИМЕР!. Ок. Должны быть зашифрованы Имя и Фамилия клиента, его индентификационные данные (номера ID или паспорта) и номер его сотового телефона для sms банкинга. Имя и Фамилию клиента, а так же его ID надо для возможного изменения из админки, номер телефона для изменения самим клиентом. Функции изменения и просмотра таких данных будет только у 2-х людей в компании, а не у "простого" в нашем понимании админа.

шифрование можно сделать на стороне явы... например при помощи JCE: http://java.sun.com/products/jce/

DeniF писал:

Блин, кто-нибудь будет читать то, что я пишу? Я написал что это ПРИМЕР!. Ок. Должны быть зашифрованы Имя и Фамилия клиента, его индентификационные данные (номера ID или паспорта) и номер его сотового телефона для sms банкинга. Имя и Фамилию клиента, а так же его ID надо для возможного изменения из админки, номер телефона для изменения самим клиентом. Функции изменения и просмотра таких данных будет только у 2-х людей в компании, а не у "простого" в нашем понимании админа.

ну и юзай тогда шифрование с симметричным ключом... главное чтоб ключ не увели тогда вместе с базой

bleed писал:

на сколько я знаю это еще никто не доказал опытным путем но и не опроверг...

к счастью, некоторым для этого достаточно только теории (в гугл посылать не стану, а вот на вики можешь слегка почитать), а не просиживать штанов для подтверждения аксиомы...
http://en.wikipedia.org/wiki/MD5 (даже с примерами на пыхе, и ссылками на тот же взлом)
http://ru.wikipedia.org/wiki/MD5 (офигенно урезанный вариант на русском, но кому-то может будет проще)

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

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

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

Heavy писал:

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

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

DeniF писал:

Какую лучше использовать БД и чем лучше шифровать? Вопрос не в стоимости, а в удобстве, быстроте и секюритности

если речь вести об Оракле, то всегда стоит вопрос стоимости из-за этого многие пишут софт, способный работать на разных БД, в том числе и фришных.

Simplex писал:

если речь вести об Оракле, то всегда стоит вопрос стоимости из-за этого многие пишут софт, способный работать на разных БД, в том числе и фришных.

Не знаю сколько стоит нужная мне версия Оракула, но если нужен покупной софт (БД и шифрование), то бюджет на него может составлять в пределах 2К (это конечно же без учёта стоимости написания)

DeniF: если ты html от php не можешь отличить, зачем ты тут спрашиваешь о вещах о которых ты представления не имеешь?
Не пробывал найти разработчика(ов) заплатить им хорошие деньги и поверь мне и без твоего в принципе бесполезного труда, тебе сделают хорошо защищенную систему, но не гарантирующую 100% защищенности если только сервер не будет стоять в бункере на глубине 2 км, т.к. выше уже сразу тебе написали, что админов еще некто не отменял и имея доступ к серверу все это слить можно как два пальца об асфальт.
А то получается - я сам нечего не знаю, но с удовольствием расскажу Вам как это сделать.

xreload писал:

DeniF: если ты html от php не можешь отличить, зачем ты тут спрашиваешь о вещах о которых ты представления не имеешь? Не пробывал найти разработчика(ов) заплатить им хорошие деньги и поверь мне и без твоего в принципе бесполезного труда, тебе сделают хорошо защищенную систему, но не гарантирующую 100% защищенности если только сервер не будет стоять в бункере на глубине 2 км, т.к. выше уже сразу тебе написали, что админов еще некто не отменял и имея доступ к серверу все это слить можно как два пальца об асфальт. А то получается - я сам нечего не знаю, но с удовольствием расскажу Вам как это сделать.

Правильно. Я в этом нифига не понимаю. Я нашёл разработчиков. Вроде бы куча сертификатов у них есть. КАК я могу знать, что они мне сделают так, как я прошу, а не всучат копеечную работу за 10К.
Поэтому я и хотел бы определиться на каком языке лучше писать, какую БД использовать и какой метод шифрования приминить. И это передать разработчикам.