Штатные средства шифрования mysql+php
Нужны функции вида:
code = coding(password, text);
text = decode (password, code);
В идеале, чтобы шифрование проводила сама mysql
Существуют?
Нужны функции вида:
code = coding(password, text);
text = decode (password, code);
В идеале, чтобы шифрование проводила сама mysql
Насчет декода не знаю, но очень хорошь кодинг md5
Насчет декода не знаю, но очень хорошь кодинг md5
MD5() самый хороший алгоритм и функций для декодирования у него нет
MD5() самый хороший алгоритм и функций для декодирования у него нет
А давайте не будем путать дайджесты с шифрованием.
Mcrypt Encryption Functions
Introduction
This is an interface to the mcrypt library, which supports a wide variety of block algorithms such as DES, TripleDES, Blowfish (default), 3-WAY, SAFER-SK64, SAFER-SK128, TWOFISH, TEA, RC2 and GOST in CBC, OFB, CFB and ECB cipher modes. Additionally, it supports RC6 and IDEA which are considered "non-free".
P.S. md5 уже поимели. Читаем последние новости.
md5 уже поимели. Читаем последние новости
Какой тогда есть лучший поддерживаемый алгоритм в PHP?
Какой тогда есть лучший поддерживаемый алгоритм в PHP?
Так. Средства муски - md5, sha, aes, des
Первые два - дайджесты, последние два - шифруют.
По поводу надежности - мое личное мнение, возможно никем не разделенное и никому мною не навязываемое - для шифрования использовать как минимум тандем. Из выстоявших на данный момент - RSA+RC4
То есть сжимаем текст, rsa(rc4(zip(plaintext), rc4_pwd), rsa_closed_key);
Расшифровываем соответственно:
unzip(rc4(rsa(chiper_text, open_key), rc4_pwd))
То есть если взнесут один алгоритм, пока доберутся до второго есть время пропатчится.
Всмысле функции реализовывать самому.
Так. Средства муски - md5, sha, aes, des
Первые два - дайджесты, последние два - шифруют.
По поводу надежности - мое личное мнение, возможно никем не разделенное и никому мною не навязываемое - для шифрования использовать как минимум тандем. Из выстоявших на данный момент - RSA+RC4
То есть сжимаем текст, rsa(rc4(zip(plaintext), rc4_pwd), rsa_closed_key);
Расшифровываем соответственно:
unzip(rc4(rsa(chiper_text, open_key), rc4_pwd))
То есть если взнесут один алгоритм, пока доберутся до второго есть время пропатчится.
Всмысле функции реализовывать самому
Этим алгоритмом можно шифровать номера кредиток или еще что-нибудь подобное
MD5() можно вполне использовать для хранения, например, паролей юзеров на сайте
З.Ы: Сколько же это ресурсов на RSA + RC4 надо
Этим алгоритмом можно шифровать номера кредиток или еще что-нибудь подобное
MD5() можно вполне использовать для хранения, например, паролей юзеров на сайте
З.Ы: Сколько же это ресурсов на RSA + RC4 надо
Согласен.
Вам бы сударь в банке работать.
Согласен.
Вам бы сударь в банке работать
Кому? %|
Кому? %|
C тобой согласен. Чигевару бы в банке работать с такими алгаритмами.) Или вообще на провительство США.
C тобой согласен. Чигевару бы в банке работать с такими алгаритмами.) Или вообще на провительство США
"Это молодой Чегевара....
Крокодил мировых революций"
Какая-то песня
эээ .... непонял зачем такие муки. если сервак защищён и смертный не может получить доступ к мускулю то хранить пароли и нэймы можно даже без шифрования
Да, но разве это справидливо по отношению к самим пользователям, которые оставляюст свои кровные пароли, которые используют везде?
На мой взгляд и мнение пользователя зарегившегося на вашем сайте нужно уважать, и не довать соблазн себе тоже иметь возможность видить их пароли.
Да, но разве это справидливо по отношению к самим пользователям, которые оставляюст свои кровные пароли, которые используют везде?
На мой взгляд и мнение пользователя зарегившегося на вашем сайте нужно уважать, и не довать соблазн себе тоже иметь возможность видить их пароли
Согласен
Да, но разве это справидливо по отношению к самим пользователям, которые оставляюст свои кровные пароли, которые используют везде?
На мой взгляд и мнение пользователя зарегившегося на вашем сайте нужно уважать, и не довать соблазн себе тоже иметь возможность видить их пароли.
у меня например никогда даже желания не возникало посмотреть в саму базу ...
да и у любого админа(который имеет доступ к базе данных) есть возможность вскрыть сей пароль даже афигенно закодированный
MD5() можно вполне использовать для хранения, например, паролей юзеров на сайте
З.Ы: Сколько же это ресурсов на RSA + RC4 надо
Народ, ну зачем вы так упорно путаете шифрование с дайджестами.
Не сможете вы хранить пароли при помощи md5.
А поскольку речь шла именно о шифровании, то есть в том числе с возможностью восстановить plain-text из chiper-text-а, то все однонаправленные функции идут лесом.
В плане ресурсов - rc4 один из(если не самый) самых легких алгоритмов. RSA - да, согласен, отъест. А шифровать при помощи RSA симметричный ключ, которым зашифровывается весь текст - не выход, теряем преимущество тандема. Хотя в pgp именно так и сделано.
В общем был вопрос, я высказал свое мнение, подчеркнув что это МОЕ мнение. Вот и все.
у и у любого админа(который имеет доступ к базе данных) есть возможность вскрыть сей пароль даже афигенно закодированный
Гипотетическая. Поскольку хранятся в базе не пароли а их хэши, то админу придется подобрать такой пароль, который дает требуемый хэш. Сложностью такого подбора и меряется устойчивость и надежность хэша. md5 действительно был один из лучших.
Посмотрим что еще предложат математики.
у меня например никогда даже желания не возникало посмотреть в саму базу ...
да и у любого админа(который имеет доступ к базе данных) есть возможность вскрыть сей пароль даже афигенно закодированный
Тачняк, особенно прибегнув к просмотру всяческих логов и т.п. Это как .. как его.. недавно по телеку передачу показывали, мол все у нас в конституции с пресечением жилищных преступлений путем, только вот сами те, кто должен эти дела пресекать (нотариусы и т.п.) - нередко оказываюцца козлами;) С админами так же, если человек свинья и эта свинья в должности, то хоть убейся, пока его не выкинули ничем от его жирного пятака не в тех щелях не избавишься. Но, все же, хэшировать пароли это хорошо. В тех же лвс, где никакой толком изоляции траффа одного юзера от траффа другого нет (была у нас такая), и можно сниффать все что проходит мимо твоей сетевухи, а проходит много чего - там эти самые хэши пригодятся. Чем сложнее хэш, тем дольше его вскрывают, ну а там.. в конце концов пароль может уже успеть смениться, до того как его подберут, или же за это время необзодимость в этом самом вскрытии (точнее в том, что можно впоследствии обрести) так же может отпасть. Где-то в сети видел в какой-то дессертации или как это называется описание интересного алгоритма хэширования. Ну, вот там хорошо по этой тематике все было разжевано.
Я сам на каждый новый ресурс приходя тычу новый пасс потому как действительно нынче админам доверять нельзя вообще. Если вспомнить кто нередко на эту профессию идет - люди без образования и совести (не в обиду будет сказано профам и людям этим живущим, я имею ввиду случаи получения должности кротом не с того огорода по блату или же нелепой случайности), лентяи (бывает) и т.п. Лишние сложности тому кто решит разгрести мою инфу с почтовика и т.п. эта мера все же добавит, хотя бы по минимуму. Конечно, стопроцентно защититься сложно, но и забивать на это дело нельзя. Да и опять-таки.. воровством пасс'ов занимаются, наверное по большей части остолопы, т.к. я вот сомневаюсь что человек вложившийся в свое образование, понимающий какой это труд, ну, вообще зрелый гражданин своего гос-ва врядли такой лабудой станет заниматься. Не без исключений конечно;)
Простой пример - я пользую виртуальный хостинг. За машиной где я хостюсь следит админ. Я этого админа не знаю и в нем не уверен. Мой ресурс представляет собой какой-нить feedback ресурс, к примеру, от такой-то больницы (нет, ну а что.. это не предел, многие серьезные заведения любят экономить на IT). Ну и в общем переписка между пациентом, или же пациентом в перспективе и врачом штука сугубо личная, где может проскальзывать такая информацию, которую человек даже родной бабушке не скажет. В общем к чему я клоню. Админ хостинга вполне может оказаться каким-нить юным придурком (ну ведь в большей степени это именно для околоюношества характерно) и вполне может подарить какому-нибудь своему "другу детства" пасс от базы моего хостинга. Возможно, в его понимании этот пасс ничего не стоит, но вот его товарищ может хорошенько поиметь деньги на шантаже, грозясь кому-нибудь из клиентов моего feedback-ресурса распространить его инфу личного характера.. А в итоге, виноваты в этом не только админ да его дружище будут, но и я, т.к. не защитил должным образом свое творение.
В общем по-максимуму вкладываемся в ЗИ, чтоб не попало ненароком от пострадавших;)
эээ .... непонял зачем такие муки. если сервак защищён и смертный не может получить доступ к мускулю то хранить пароли и нэймы можно даже без шифрования
1. Абсолютно защищённой системы не бывает.
2. Ты полностью уверен, что твой сайт не подвержен sql инекции?
Вывод? Шифровать хоть чем, но надо обязательно (если не хочешь людям жизнь облегчить:)).
PS. Совет при шивровании md5() использовать несколько раз эту функцию, скажем так md5(md5(pass)). Теперь попробуйте это скормить любому бруту:)))
Кстати, чтоб лишний раз не лазать. md5 страдает коллизиями независимо от длины хэшируемой строки, или все ж хэши строк длиной меньше 33-ёх символов можно не проверять на уникальность?
Меньше 33 совпадать не должны. Если кому интерестно, то я тут на трейд наткнулся http://forum.dobroe.ru/lofiversion/index.php/t1277.html
Гипотетическая. Поскольку хранятся в базе не пароли а их хэши, то админу придется подобрать такой пароль, который дает требуемый хэш. Сложностью такого подбора и меряется устойчивость и надежность хэша. md5 действительно был один из лучших.
Посмотрим что еще предложат математики.
Интересно а как в таком случае реализовать услугу "Забыли пароль"...? Как по мне если пользователь забудет пароль, а это оочень распространенно, и админ не сможет выслать юзверб пароль, разве это не болшее неуважение? А обьяснять юзверю, извините мы шыфруем ваши пароли дабы мы их сами не могли посмотреть, поэтому шувулите своей черепушкой и впоминайте... весело:D
Интересно а как в таком случае реализовать услугу "Забыли пароль"...? Как по мне если пользователь забудет пароль, а это оочень распространенно, и админ не сможет выслать юзверб пароль, разве это не болшее неуважение? А обьяснять юзверю, извините мы шыфруем ваши пароли дабы мы их сами не могли посмотреть, поэтому шувулите своей черепушкой и впоминайте... весело:D
Сможет. В этом случае, пароль просто сбрасывается и устанавливается новый, который и высылается юзеру.
Сможет. В этом случае, пароль просто сбрасывается и устанавливается новый, который и высылается юзеру.
Вот именно.
Сможет. В этом случае, пароль просто сбрасывается и устанавливается новый, который и высылается юзеру.
Дать юзверю новый пароль и выслать ему его старый пароль две разные вещи...
Дать юзверю новый пароль и выслать ему его старый пароль две разные вещи...
Так лучше все-таки иметь услугу "Забыли пароль" и высылать новый пароль, чем ничего не иметь.
(хотя будет использоваться шифрование или нет это будет зависеть от конкретных задач и ессно от самогог программера)
а если это форум любителей телепузиков то простите на кой хрен там шифрование ???
Дать юзверю новый пароль и выслать ему его старый пароль две разные вещи...
тем самым показывая юзверям: "Мы такие крутые, знаем ваш пароль, а вы свой же пароль нехера не знаете..." Ну эт ненормально ИМХО.
на мой взляд всё просто - если ты клипаешь какой то совершенно новый продукт, заточенный под определённые задачи, то шифровать стоит
(хотя будет использоваться шифрование или нет это будет зависеть от конкретных задач и ессно от самогог программера)
а если это форум любителей телепузиков то простите на кой хрен там шифрование???
В начале кто-то писал что если юзер использует один и тот же пароль во многих местах то....
И т.д
2Fenyx
Во многих службах так и делается как сказал 3D Bob, т.е берется контрольный вопрос, если отвечаешь на него - можешь сменить пароль, старый тебе не скажут
Народ, ну зачем вы так упорно путаете шифрование с дайджестами.
Не сможете вы хранить пароли при помощи md5.
Простите этого не понял, а что же тогда все делают? Может фраза построена не так? типа - не пароли хранить, а хэши от них?
Простите этого не понял, а что же тогда все делают? Может фраза построена не так? типа - не пароли хранить, а хэши от них?
Дайжесты(типа MD5()) кодируют строку в другую строку(хэш, hash)
Их стойкость в том, что что бы узнать пароль нужно перебрать все варианты и найти совпадаюшие хэши
Функций для дешифрования у них нет
Шифрование преобразовывает строку в другую строку с помощью пароля
Зная пароль можно раскодировать строку
Некоторые функции даже если пароль не верный все равно раскодируют, "повредив" исходную строку
Преимущество второго в том что если примерно не знаешь содержания всей исходной строки или ее части, то не сможешь сделать прогу для автоматического раскодирования, т.к данные будут выглядеть верными во многих случаях
Дайжесты(типа MD5()) кодируют строку в другую строку(хэш, hash)...
это я знаю, я имею ввиду почему нельзя хранить хэши в базе?
Не сможете вы хранить пароли при помощи md5 - я по поводу этой фразы
Простите этого не понял, а что же тогда все делают? Может фраза построена не так? типа - не пароли хранить, а хэши от них?
Когда я храню варенье а кладовке, я знаю что всегда могу достать его и сьесть.
Когда я храню деньги в банке, я знаю что могу взять банку, достать деньги и ушатать их по усмотрению.
Когда я храню md5 хэш от пароля в базе, я знаю что могу достать хэш из базы.
НО!!! Я не могу достать пароль из хэша, тяжело это будеть выглядеть и долго. Поэтому я и говорю, что ХРАНИТЬ пароль в md5 не получится.
md5 - это не шифрование, это однонаправленная функция, необратимая...
Когда я храню деньги в банке...
Во-во;) Сила-то в банках:o
По мне так самое удобное— хранить хэши, а если уж страшно за авторизацию и т.п., дык по ssl её, или еще как там. Снифферы работают далеко не везде.. А где работают там вспоминаем о том что с тем же успехом пароль может быть получен не путем прослушивания и анализа юзерского траффика, но и тыканья по нужным кнопкам на самом компе этого юзера, подсаживания к нему трояна, взлома его через какие-нить telnet-оподобные интерфейсы, применения физического насилия к этому юзеру (или еще кому, кто владеет необходимой инфой) с целью получения пароля и т.п. и т.д. Как аналогия— сколько бы почтовики (физ.) не гарантировали успешность доставки вашей бандероли в пункт назначения, всегда может найтись "хмырь" среди персонала почты и увести добро тем или иным способом..
Задача состоит в том, чтобы заюзать нужную связку крипто- и хэшо- алгоритмов и.. и заюзать правильно, то есть не дурнуть с механизмом обмена хэшыми или что там будет на выходе между юзверем и серваком.
Да кстати, про восстановление пароля. Далеко ходить не надо— я по несколько раз (2,3,5.. больше) в месяц восстанавливаю пароль.. на codenet.ru, то есть здесь ;) запоминать его впадлу, opera wand logins все эти дела хранят достаточно удобно. Ну а как обнуляю оперу, так click по "восстановить", пара писем в ящик/переходов и все готово. Нафига мне старый пароль? Ну если только в качестве пароля я юзал д.р. своей любимой бабушки, которое будет в близжайшие n-дней, а когда именно не помню.. Кхе.. Ну нельзя делать из паролей sticker'ы.. А про один пасс на несколько ресурсов я уже писал. Если все делать правильно, то врядли этот самый "пасс в оригинале" понадобится.
Во-во...
и я о том же, в большинстве случаев восстанавливать старый пароль нафик не нужно.
Еще можно использовать пару(ключей в виде хэша), на клиенте и в базе, ключ-хэш на клиенте будет допустим от кодовой фразы, а в базе хэш от обоих хэшей :D ...нда, а где же тогда хранить хэш от пароля?
я тут подумал - это скорее к сессиям
По мне так самое удобное— хранить хэши, а если уж страшно за авторизацию и т.п., дык по ssl её, или еще как там. Снифферы работают далеко не везде.. А где работают там вспоминаем о том что с тем же успехом пароль может быть получен не путем прослушивания и анализа юзерского траффика, но и тыканья по нужным кнопкам на самом компе этого юзера, подсаживания к нему трояна, взлома его через какие-нить telnet-оподобные интерфейсы, применения физического насилия к этому юзеру (или еще кому, кто владеет необходимой инфой) с целью получения пароля и т.п. и т.д.
Об этом уже пусть юзер заботится
Наше дело закодить пароль на сервере что бы его никто не знал, а юзеру надо поставить файерволлов и всяких Касперских :)
Задача состоит в том, чтобы заюзать нужную связку крипто- и хэшо- алгоритмов и.. и заюзать правильно, то есть не дурнуть с механизмом обмена хэшыми или что там будет на выходе между юзверем и серваком
Ты предлагаешь кодировать пароли прямо на клиенте что ли?
Вообще-то нет, но и такое возможно. В таком случае мы гарантировано защищаемся от перехвата именно пароля. Все-таки хэш хэшем, но его еще нужно подобрать;) Правда если глянуть на производительность js в браузерах, то слабо верится что получится заюзать без проблем (для юзера) даже что-то отдаленное, не говоря уже о самих функциях хэширования
Если встроить нормальный MD5(), например, в IE, то что такого долгого в том что бы просто захэшировать?
Другое дело, что браузеры значительно медленнее обновляются, в отличии от серверных языков, и пока они обновятся, этот алгоритм уже устареет
З.Ы: в About в IE написано "стойкость шифра"(Cipher strength). Это имеется ввиду для HTTPS(SSL), что ли?