Хеш пароля в базе. Надежно ли?

[Romantik]

откуда у него такой доступ к базе ?

все та же проблема- был не запароленный mysqladmin.

 

[ONK]

Romantik, а вы пробовали закрыть mysqladmin?

 

[si]

все та же проблема- был не запароленный mysqladmin.

"Это пиз..., а пиз.. мы не лечим"

 

[Alexandre]

Romantik
лично я делал так:
запоминал хешированный psw юзера
вставлял вместо него свой хешированный psw
входил под своим логином

что-то писал ....

востанавливал хешированный psw юзера.

Проходило нормально -

 

[si]

Romantik

Romantik
лично я делал так:
запоминал хешированный psw юзера
вставлял вместо него свой хешированный psw
входил под своим логином

что-то писал ....

востанавливал хешированный psw юзера.

согласись это гораздо сложнее чем просто использовтаь пароль юзера, к томуже он (пароль) очень часто используется больше чем в 1 месте.

 

[Romantik]

Alexandre
Вот я и о том же =)
si
В принципе это показательный топик- враг не дремлет! =)

 

[Span]

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

А если вспрыли базу - тушите свет =)

 

[Romantik]

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

По этому поводу: имеющий доступ (хостер к примеру), может получить этот самый пароль без труда и воспользоваться им в других местах =)

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

 

[Frol]

Не спец в этом, но чёт я как-то думал, что это ещё и для предохранения от узнавания пароля, которым пользователь может польз-ся и в др. местах.

Собственно это меня как разработчика не должно интересовать.

как никого, а тебя это должно интересовать.

По этому поводу: имеющий доступ (хостер к примеру), может получить этот самый пароль без труда и воспользоваться им в других местах =)

он может получить без труда хеш, а не пароль.

Вообщем выводы:

мм да.
от разговора "надежно ли" перешли к правилам безопасности.

 

[Romantik]

он может получить без труда хеш, а не пароль.

Что ему помешает сделать маленький скриптик, который просто выведет $_POST массив?

 

[Alexandre]

По этому поводу: имеющий доступ (хостер к примеру), может получить этот самый пароль без труда и воспользоваться им в других местах =)

Romantik
хостеру - доступтно все, в том числе и пароли БД, т.к. он сидит под root.

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

Для серьезных проектов спасает только выделенный сервак

 

[Frol]

согласен.
узко подумал.

 

[Alexandre]

возможно, ZEND ENCODER спасает ситуацию, но тут я несоветчик, т.к. практики с ENCODERом не имел.

 

[Yurik]

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

 

[SelenIT]

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

 

[Yurik]

в случае хранения паролей с возможностью восстановления этот посторонний сможет ими воспользоваться

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

 

[SelenIT]

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

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

 

[ABORIGEN]

Автор оригинала: Screjet
Да. Еще вспомним случай с вальюхостом. Когда через (в превого взгляда) невинную брешь в коде (организации хостинга) стянули аккаунты потребителей.

Очень интересно, ничего по этому поводу не слышал. Можно подробнее ?

 

[Vasya]

Да. Еще вспомним случай с вальюхостом.
...
Очень интересно, ничего по этому поводу не слышал. Можно подробнее ?

http://www.xakep.ru/post/24136/
"Как был взломан ValueHost"

 

[Bred Vilchec]

>http://www.xakep.ru/post/24136/

Пожалуйста, не будем в серьезном вопросе упоминать фантазии обкуренных подростков...

Кстати, не забываем, что md5 и прочие хеши в принципе не так уж и сложно подобрать...
Есть, например, библиотеки для Pascal 'я (царство ему небесное) (и на С, я уверен, есть) генерящие md5, написать с ними прогу, с неплохой скоростью подбирающую пароли очень просто.
Помнится, был опыт по подбору md5 на PHP, если не ошибаюсь, строка из семи знаков подобралась за пару дней.
Соответственно, на более низком уровне скорость на порядок выше...