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

Но я говорил не про это.


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

Т.е. храня пароль в сессии или вообще где либо в открытом виде - Вы подвергаете пользователя дополнительным рискам.

Мне нравиться третий вариант тем что если я проверяю if(isset($_SESSION ..
То не нужно писать несколько раз isset && isset && isset для ip agen username id
А все храниться в одном месте!

Добавлено через 10 минут и 10 секунд
И все же если вернемся к безопасности, неужели agent и ip нас могут защитить?
А если человек с разных браузеров заходит?

агент  - защита от дурака
ip - уже что-то, но у многих он динамический.

Если работаете с деньгами - используйте хотя бы https

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

сори дабл пост.

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

Пароль и в базе надо хранить в хешированном виде - это как минимум..

Muerto, Уже все сказали, пароль нигде не должен храниться, кроме как в базе, причем шифрованный.  Или Вы пытаетесь всех переубедить, что правы? Проверять пользователя на каждой странице - это перебор. Я такого кодера уволил бы сразу, пока он своим кодом не положил сайт.  

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

Это сообщение отредактировал(а) capitan - 16.7.2010, 14:55

Самым первым вопросом Muerto, было то, что можно ли хранить и создавать на сервере очень много сессий.

Вот и меня интересует, пользуется сайтом к примеру 2000 человек, и не будет ли плохо, если на сервере лежит 2000 файлов сессий?

Если ОДНОВРЕМЕННО 2000 человек зайдут на сайт (одновременно - в течении 10 минут - время жизни сессии), то да, будет 2000 сессий. Но с таким наплывом посетителей сайт либо дохнет сам, либо переходит в другую категорию обслуживания, на более дорогой тариф (и, вероятно. с более другими разработчиками)   

capitan, А что мешает хацкеру, если он не знает какой пароль и получил доступ к серверу тупо взять и сменить пароль на 12345 и захешировать?

Я никого не переубеждаю, это всего лишь обсуждение...

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

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

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

А что мешает их в сессию засунуть и считывать оттуда???




Вам так сильно это интересно? Зачем? Ваш подход не предусматривает высоконагруженный проект.

так а не легче айди туда записать и вытянивать данные по айди(где надо, а не везде). темболее если данные из сессии похитят, то что лучше чтобы узнали пароль или айди пользователя? 
Неужели Вы думаете что все вам тут пудрят мозги! 

CruorVult, Да никто мозги не пудрит, все верно, дело во мне- я не знаю как сделать безопасно без проверки пароля.

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


Ура, вы узнали что мой id Это 1 username это admin хэш пароля UHFgfd6435dfd7345Fsd43fdg745fdhdf
Как вы узнайте что нужно ввести koshka в пароле если мой алгорит кодирования не доступен в паблике?

Добавлено через 3 минуты и 48 секунд
capitan, Ну у меня есть проекты и похуже, на старом скрипте, которые тянули и по 10к хостов в день...

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

Мде!
Как Вы думаете какой запрос будет выполянтся быстрее:
1) поиск по id(primary key)
2) или по хешу

Ах да, я забыл, вам производительность не главное  

Добавлено через 2 минуты и 20 секунд

перечитайте внимательней эту тему - может и поймете 

Что-то смешались в кучу кони люди сессии и куки, а точнее session cookie и permanent cookie.

Как работает сессия?

Пользователь заходит на сайт, сайт делает session_start(), что заставляет произойти следующее:
1) на сервере создается файл сессии с уникальным идентификатором сессии в качестве имени
2) браузер пользователя устанавливает у себя session cookie для вашего сайта, который содержит этот уникальный идентификатор.

Именно таким образом сайт "узнаёт" пользователя при дальнейшей работе. Он спрашивает session cookie для себя, браузер ему отдает её содержимое, в содержимом хранится идентификатор сессии, сайт достает данные для этой сессии из файла, созданного в шаге 1. Это все происходит прозрачно для вас, благодаря механихму сессий.

Если я узнаю идентификатор живой сессии на сайте и подменю его в своей session cookie для вашего сайта, то я сразу "зайду" как другой пользователь. 
Для session cookie идентификатор сессии - это единственное что хранится на стороне клиента. Все остальные данные, которые вы достаете/кладёте из массива $_SESSION хранятся на стороне сервера, в файле, созданном на шаге 1.

Безопасность тут обеспечивается тем, что я не могу узнать имена существующих сессий, если только другой пользователь сам мне его не отдаст или я у него его не украду. Кража сессионых кук - весьма распространённый метод взлома. Защитить пользователя от него вы можете лишь в области javascript, обеспечив экранирование пользовательского ввода, чтобы злоумышленник не смог на вашем сайте где-то подставить вредоносный javascript код. (например на какой то доске объявлений, забудете заыкранировать и сразу встречайте js-injection)

Session cookie удаляется браузером после закрытия. Она временная.

Cookie

Теперь касательно permanent cookie. Они используются для того, чтобы сайт узнавал пользователя даже после того, как браузер был закрыт. permanent cookie живут столько, сколько им отведено по expire времени.

Обычно минимальная информация, которая хранится в такой cookie - идентификатор пользователя.

Вопрос - как обеспечить безопасность этой куки? Чтобы злоумышленник, подделав или украв permanent cookie пользователя, не смог ей воспользоваться.

Ответ: обычно в такую cookie подкладывают уникальный hash, который злоумышленник знать не может, это спасает от подделки. hash пароля - один из возможный путей, но недостаточно секьюрный. Обычно хешируют связку типа useragent+ip+password. При подключении пользователя с permanent cookie сайт должен взять его текущий useragent+ip+password, захешировать и сравнить с тем, что в cookie. Не совпадают? - До свидания, логинься снова. 

От воровства этих cookie спасаются точно так-же, как от воровства первых - экранировать ввод. Не допустить javascript-injections.