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

[Romantik]

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

Приветствую всех и с наступающим.

Вот тут возник спор, вернее не спор, а вывод, что хранить пароли в базе что в открытом виде что его ХЕШ, уверенной защиты не дает.
Суть хешей в базе, что при получении доступа к базе воспользоваться паролями невозможно
Приведу пример:
Злоумышленник получает доступ к базе данных-
ему ничего не стоит создать создать через сайт нового пользователя, увидеть СВОЙ ХЕШ, заменить его в базе другим пользователям и входить на сайт с чужим логином и своим паролем.
Понятно, что имеет смысл хешировать, когда будет получен не доступ к базе, а дамп таблиц.
Но по сути своей хеширование не увеличивает секурность в моем примере.
Да, можно рассуждать, что получив доступ к базе, можно вообще все "поломать", но данный топик не об этом.
Просто он возник в результате того, что заказчик хочет "напоминание пароля", а не "генерировании нового" и собственно доказать что первый метод- лажа мне так и не удалось...

 

[Cougar]

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

 

[Сергей123]

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

 

[Vinny]

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

В больших базах типа Oracle или MS SQL server можно закрыть все так что при логине и пароле кроме админского ты ничего не сделаешь...

ЗЫ: сорри, пароль передается AS IS если не ввести криптование до посыла формы, например, JavaScript-ом, так что хеширование на стороне сервера не спасает от перехвата трафика...

 

[si]

Да, можно рассуждать, что получив доступ к базе, можно вообще все "поломать", но данный топик не об этом.

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

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

P.S. если и код сайта доступен, то тут только сушить весла

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

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

 

[f1]

заказчик хочет - сделай

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

 

[si]

В больших базах типа Oracle или MS SQL server можно закрыть все так что при логине и пароле кроме админского ты ничего не сделаешь...

а что мешает это сделать для mysql ?

 

[Romantik]

Cougar

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

Мы берем стандартную ситуацию, которая есть на многих сайтах.
Бресь Сергей

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

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

Хеш нужен для того чтобы не перехватили трафик

Трафик идет при заполнении формы, где проще перехватить пароль, чем при запросе к базе.
si

он не должен этого хотеть

Собственно топик создан с целью, что ХЕШ пароля в базе не достаточно, что бы давать гарантию, даже не 20 процентную.

-~{}~ 29.12.04 18:56:

f1

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

Вот в данном случае объясни полезность хеширования?
Админ хостинга имеет ПОЛНЫЙ доступ к сриптам и базе.

 

[Vinny]

Originally posted by si
а что мешает это сделать для mysql ?

На заре начала роботы программером я делал в MS SQL Server так... Была таблица хранящая "сесионные ключи"... Залогинился на сайте, получил сесионный ключ... Все запросы идут только через хранимые процедуры которым передается сесионный ключ... Доступ к базе ограничивается вызовом хранимок, все остальное закрыто... Так что обязательным условием доступа к базе является владение правильным сесионным ключом... Сесионный ключ можно получить только у другой хранимке при вводе правильного логина и пароля...

Муська пока кажется не дружит с хранимками... Как такую схему можно реализовать на муське?

 

[f1]

Автор оригинала: Vinny
ЗЫ: сорри, пароль передается AS IS если не ввести криптование до посыла формы, например, JavaScript-ом, так что хеширование на стороне сервера не спасает от перехвата трафика...

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

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

 

[Vinny]

Romantik

Трафик идет при заполнении формы, где проще перехватить пароль, чем при запросе к базе.

ага, поправил свой пост одновременно с твоим

 

[si]

Собственно топик создан с целью, что ХЕШ пароля в базе не достаточно, что бы давать гарантию, даже не 20 процентную.

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

 

[f1]

f1

Вот в данном случае объясни полезность хеширования?
Админ хостинга имеет ПОЛНЫЙ доступ к сриптам и базе.

Админ хостинга имеет доступ ко всему что ты разместил на нем
Хеш помешает рассылать твои пароли налево и направо.
И только это

 

[si]

Вот в данном случае объясни полезность хеширования?
Админ хостинга имеет ПОЛНЫЙ доступ к сриптам и базе.

там в твоем случае ему не надо даже 1 минуты, при использовании sha к примеру ему будет сложно получить чейто пароль сложнее qwe? зачем ему упрощять жизни ?

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

для этого есть https

P.S от админа со злыми намерениями защитится очень сложно, в рамках нашего разговора я бы сказал не реально.

 

[Vinny]

f1

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

Встречал я систему где заявляли - мы не передаем пароль в открытом виде, передаем md5 от пароля (md5 получали яваскриптом). Перехваченный хеш, отлично принимался сервером [/B]

каким образом? Есть база с юзерами, есть форма логина, где:

select ... from ... where login=\''.$login.'\' and password=\''.md5($password).'\'

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

 

[Romantik]

si
Я столкнулся однажды, что заполучив доступ к базе, человек мог входить под кем угодно и писать что угодно от любого имени (открытые пароли)
Именно "гадить" на сайте. =)
предложив хеширование, я был уверен, что это спасет сайт, а вот сегодня понял, что ему достаточно подправить хеш юзера, зайти под его именем и продолжать гадить- притом песпардонно, так как настоящий юзер на сайт просто не зайдет- не его пароль.
Здесь все же отслаживается не полное уничтожение, а мелкие пакости, которые сведут рейтинг сайта в ноль!

 

[f1]

Автор оригинала: Vinny
f1

каким образом? Есть база с юзерами, есть форма логина, где:

select ... from ... where login=\''.$login.'\' and password=\''.md5($password).'\'

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

Мой пост был не про то, о чем ты пишешь. Прочти внимательнее.

 

[Screjet]

Именно "гадить"

Один знакомый сисадмин за это забанил бы не только "гаденыша", но и весь его регион

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

В 70% проблем безопасности, проблемы именно в людях, остальные 30% в дырявости логики/скриптов.

 

[si]

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

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

 

[Screjet]

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