[web, mysql]Есть ли смысл хранить пароли в md5?
Единственное неудобство - не сможешь забытый пароль выслать. Зато оградишься от людей, которым по пьянке сболтнешь свой пароль от базы
Зато оградишься от людей, которым по пьянке сболтнешь свой пароль от базыИ от тех, у кого есть физический доступ к серверу.
+ от тех, кто воспользуется какой-нибудь дыркой в mysql (а дырки время от времени обнаруживаются везде).
А лучше что-то типа md5($login.'some$ecr3tkey'.$password);
Такого в словарях нет да и подбирать подольше придётся.
А лучше что-то типа md5($login.'some$ecr3tkey'.$password);А ещё затравку рандомизировать тоже неплохо.
а проверять потом как будешь?
Чем плох login в качестве затравки? Собственно для этого он там и стоит
Чем плох login в качестве затравки?Если пользователь меняет пароль на тот же самый, то по хешу можно догадаться, что он не изменился. Это всё же некоторая дополнительная информация о пароле пользователя. Что она даёт или не даёт - это другой вопрос.
а проверять потом как будешь?Как и все - затравка хранится открытым текстом рядом с хешем обычно.
Ещё неудобство логина-затравки - нельзя поменять логин не "сбросив" пароль.
Собственно, что я хотел сказать своим постом, это то, что md5 от чистого пароля это плохая идея. А улучшать её можно разными способами.
Что-то не часто я встречал сайты на которых можно сменить логин. Но, в принципе согласен.
Ну такая возможность не должна обязательно пользователю предоставляться. Просто мало ли чего может понадобиться. Или банально перенести пароль из другого места под другой логин тоже может не получиться. Самая маза не только хеш хранить, но и метод хеширования, то тогда вообще удобно.
Если сопровождать систему не нужно, можно действительно так и оставить.
Или банально перенести пароль из другого места под другой логин тоже может не получитьсяИ не надо!
А то поломает какой-нибудь Вася Пупкин базу, сделает себе пароль "вася" и перенесёт его к руту
А то поломает какой-нибудь Вася Пупкин базу, сделает себе пароль "вася" и перенесёт его к рутуОн и так руту новый пароль сделать сможет с тем же успехом.
Он и так руту новый пароль сделать сможет с тем же успехом.Но, если у него нет исходников скриптов - он не сможет от рута зайти.
Но, если у него нет исходников скриптов - он не сможет от рута зайти.В большинстве случаев либо исходники доступны, либо доступа к базе вполне хватит, только если она не слишком сложная для понимания.
Я так навскидку не скажу - есть ли примеры, когда можно сделать SQL-injection в приложениях с закрытыми исходниками?
Я так навскидку не скажу - есть ли примеры, когда можно сделать SQL-injection в приложениях с закрытыми исходниками?Если дырка есть - найти её можно; просто пытаешься засунуть что-то нехорошее по очереди во все параметры, которые от тебя приходят, и смотришь на реакцию.
Наверняка кто-то и автоломалки уже написал.
есть, есть
все реквизиты доступа лежат себе в файле config.php или db_config.php, или ещё как, открытым текстом и никого из владельцев этих сайтов это не напрягает
а почему ни одна CMS-система не шифрует пароли к БД ?А как их предлагаешь шифровать?
В config.php хранить encrypted_password и key_to_decrypt?
а напрягать это будет тебя, когда ты будешь выяснять, почему их подефейсили
собственно проблемы со сменой пароля базы самим владельцем возникают гораздо чаще чем взлом
и решаются они с открытым паролем конечно проще
может поэтому?
а если файл создается и редактируется PHP-скриптом, он может где-то ещё лежать?
В общем я бы в данном случае лучше бы выбрал гибкость, чем маленькую защишённость, т.к. доступ к базе даёт всё же не меньшие права доступа, чем права суперюзера в веб-морде. Хотя, в принципе, бывает и наоборот. Но тут скорее вопрос в том, что нефиг писать дырявые программы.
в ipb, помнится, хранится в md5(md5). К этому словари помогают хуже
Да по-любому, где бы не лежал, если есть способ просмотреть файло на сервере (взлом админки -> свой скрипт пихнуть туда -> доступ к базе то пиши гг.
пароль открыт, потому что должен же скрипт его где-то взять, чтобы использовать базу
можно предложить заводить двух юзеров в базе и давать права на админские манипуляции только второму, чей пароль шифровать ключём, который нужно будет вводить с админки, но сдаётся мне, для типичного 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
Ведь все равно подбор - дело времени, + огромные словари есть. Да и ваще, есть ли целесообразность любого шифрования?