[web, mysql]Есть ли смысл хранить пароли в md5?
Единственное неудобство - не сможешь забытый пароль выслать. Зато оградишься от людей, которым по пьянке сболтнешь свой пароль от базы
Зато оградишься от людей, которым по пьянке сболтнешь свой пароль от базыИ от тех, у кого есть физический доступ к серверу.
+ от тех, кто воспользуется какой-нибудь дыркой в mysql (а дырки время от времени обнаруживаются везде).
А лучше что-то типа md5($login.'some$ecr3tkey'.$password);
Такого в словарях нет да и подбирать подольше придётся.
А лучше что-то типа md5($login.'some$ecr3tkey'.$password);А ещё затравку рандомизировать тоже неплохо.
а проверять потом как будешь?

Чем плох login в качестве затравки?Если пользователь меняет пароль на тот же самый, то по хешу можно догадаться, что он не изменился. Это всё же некоторая дополнительная информация о пароле пользователя. Что она даёт или не даёт - это другой вопрос.
а проверять потом как будешь?Как и все - затравка хранится открытым текстом рядом с хешем обычно.
Ещё неудобство логина-затравки - нельзя поменять логин не "сбросив" пароль.
Собственно, что я хотел сказать своим постом, это то, что md5 от чистого пароля это плохая идея. А улучшать её можно разными способами.

Что-то не часто я встречал сайты на которых можно сменить логин. Но, в принципе согласен.

Если сопровождать систему не нужно, можно действительно так и оставить.
Или банально перенести пароль из другого места под другой логин тоже может не получитьсяИ не надо!
А то поломает какой-нибудь Вася Пупкин базу, сделает себе пароль "вася" и перенесёт его к руту

А то поломает какой-нибудь Вася Пупкин базу, сделает себе пароль "вася" и перенесёт его к рутуОн и так руту новый пароль сделать сможет с тем же успехом.
Он и так руту новый пароль сделать сможет с тем же успехом.Но, если у него нет исходников скриптов - он не сможет от рута зайти.
Но, если у него нет исходников скриптов - он не сможет от рута зайти.В большинстве случаев либо исходники доступны, либо доступа к базе вполне хватит, только если она не слишком сложная для понимания.
Я так навскидку не скажу - есть ли примеры, когда можно сделать SQL-injection в приложениях с закрытыми исходниками?
Я так навскидку не скажу - есть ли примеры, когда можно сделать SQL-injection в приложениях с закрытыми исходниками?Если дырка есть - найти её можно; просто пытаешься засунуть что-то нехорошее по очереди во все параметры, которые от тебя приходят, и смотришь на реакцию.
Наверняка кто-то и автоломалки уже написал.
есть, есть
все реквизиты доступа лежат себе в файле config.php или db_config.php, или ещё как, открытым текстом и никого из владельцев этих сайтов это не напрягает

а почему ни одна CMS-система не шифрует пароли к БД ?А как их предлагаешь шифровать?
В config.php хранить encrypted_password и key_to_decrypt?
а напрягать это будет тебя, когда ты будешь выяснять, почему их подефейсили
собственно проблемы со сменой пароля базы самим владельцем возникают гораздо чаще чем взлом
и решаются они с открытым паролем конечно проще
может поэтому?
а если файл создается и редактируется PHP-скриптом, он может где-то ещё лежать?


Да по-любому, где бы не лежал, если есть способ просмотреть файло на сервере (взлом админки -> свой скрипт пихнуть туда -> доступ к базе то пиши гг.
пароль открыт, потому что должен же скрипт его где-то взять, чтобы использовать базу
можно предложить заводить двух юзеров в базе и давать права на админские манипуляции только второму, чей пароль шифровать ключём, который нужно будет вводить с админки, но сдаётся мне, для типичного cms разграничить так полномочия не получится
Tut delo ne tolko v tipichnyj/netipichnyj,razgranichenie dostupa - odna iz osnovnykh zadach cms,a db obychno sluzhit tolko effektivnym sposobom hraneniya0informacii, i normalnogo sposoba razgranicheniya prav na urovne db (dazhe esli zabyt,chto v realnoj zhizni est ne tolko admio/user) v terminah insert,select,updatde ya ne vizhu. Est,konecho,drugaya krajnost - ispolzovat krutuyu db,vsyu logiku perenesti v hranimye procedury,a php-skripty sdelat lish obolochkami djkya ih vyzovov,no eto - sovsddm drugaya istoria
> владельцем возникают гораздо чаще чем взлом
Я не понял, откуда проблема при смене пароля.
По-моему, он одинаково легко меняется как без шифрования,
так и с таковым.
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
В мускуле то?
---
...Я работаю антинаучным аферистом...
Скрипт с мускулом общается.
---
...Я работаю антинаучным аферистом...
И авторизуется в мускуле.
обязательно хранить пароли в открытом виде.
---
...Я работаю антинаучным аферистом...
А кто с этим спорит?
Оставить комментарий
iakobi91
Ведь все равно подбор - дело времени, + огромные словари есть. Да и ваще, есть ли целесообразность любого шифрования?