ksnk, я так и не понял где кто кого ломает. 

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

ksnk, Да, допустим если вам выдать все данные, то логин уже и не нужен.
Но а кто сказал что вы выдрать сессию сможете или куки у пользователя своровать если сам сайт грамотно написан?

Собственно с моей точки зрения итоги спора такие:

1. Взломать если очень хотеть и есть дыры в безопасности - не проблема
2. проверять пароль или нет, если взломают сервер - значение не имеет
3. если можно перехватывать данные опять же не важно как и что хранить
4. не закодированный пароль хранить нельзя, и цель защиты от ламеров в клубе, то если хранить кодированный пароль то тот ламер ничего с этим не сделает.
5. куки или сессия не имеет значения пока данные закодированные...

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

Это сообщение отредактировал(а) Muerto - 16.7.2010, 19:25

Muerto, куки , а также все хидеры, выдаваемые броузером ВИДИТ провайдер, любой участник вашего сегмента локальной сети, любой из цепочки передающих-принимающих узлов интернета.

Muerto 

Похоже Вы уже сами себя запутали. Давайте расставим запятые над i   :

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


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

Так что если у Вас используется работа с деньгами - то простой http вам противопаказн!!! 

А теперь я расскажу как все должно работать.
1. Все необходимые данные логин, никнейм, id и т.д. которые выводятся на каждой странице сайта хранятся в сессии. Дабы не делать постоянные запросы в базу и не нагружать её.
2. В куке хранится логин и хеш пароля, который лежит в базе. При заходе на сайт проверяется сессия. Проверяется не через isset, а через !empty. Например проверяем id пользователя. if (!empty($_SESSION['id'])) { пользователь авторизован }  иначе проверяем куку. Если в куках есть логин и хеш пароля - запрос в базу. Если связка логин - пароль в базе есть, пишем в сессию необходимые данные и пускаем пользователя дальше.  Если данных нет или нет кук - посылаем на авторизацию.
3. При секретных операциях, например, при смене кошелька, запрашиваем у пользователя пароль и работаем с полученными данными.
4. Для суперсекретных операций используем https  или службу поддержки, которая сама вносит изменения.
5. При залогинивании пользователя пишем в базу с какого ip и время захода. И показываем эти данные. Юзеры в случае чего сами скажут, если кто-то вошел под их данными.

P.S. даже если я получу куки пользователя - максимум что смогу сделать - побродить по сайту под пользователем. Т.к. не зная пароля, не смогу выполнить секретные операции.

capitan, 



не надо хранить хеш пароля в куках. 

Если злоумышленник получает хэш пароля - то у него есть шанс получить пароль через BruteForce.

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

Было бы очень интересно услышать, как работает галочка "сохранить пароль" в окне авторизации...

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

pforummember_id=XXXXX; pforumpass_hash=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx; достаточно открыть куки и посмотреть...
 sessionId подразумевает, что где-то на сервере будет организовано хранилище данных с неопределенным (4 недели?) временем хранения. Чем наличие этого sessionId будет секретнее хеша пароля в куках?

ksnk, 



ну что сказать, 


Наверно, стоит потратиться на более новую версию форума.  Может и ломать так часто не будут.


Кстати, ща посмотрел доки к spring-security 3

Самый примитивный способ который они предлагают:



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

Более безопасный вариант. предлагаемый spring-security - с использованием базы данных с такой табличкой:



Добавлено @ 00:35


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

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

Это сообщение отредактировал(а) Vasay - 17.7.2010, 00:36

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



Вот что выдаст


И выходит, изменяешь пару символов и у тебя уже свой метод кодировки,и хацкеру ещё надо будет узнать какой он...
А в случае SHA-512 я не знаю если это вообще реально  не взломав сервер, да и просто blowfish

Это сообщение отредактировал(а) Muerto - 17.7.2010, 00:56

а зачем тогда пароль в алгоритме хеширования?

Vasay, ну если уже храните пароль, так не стандартным хешем...

1) вот специально разработали REST, чтобы сессии не использовать, не хранить их все на сервере
http://ru.wikipedia.org/wiki/REST
http://en.wikipedia.org/wiki/Representational_State_Transfer

2) на этом форуме, вроде бы используется md5crypt($db_name,$db_name.'-'.$db_pass) (или просто md5) чтобы сравнить сессию в cookie нужно получить хэш с  md5crypt
$db_pass - как "соль", обратно декриптографировать нельзя и перебрать соответственно нелья, так как $db_pass не известно.
(единственное что в базе пароль в открытом виде... не хорошо)


Это сообщение отредактировал(а) gcc - 17.7.2010, 05:16