нужно ли хранить пароль в сессии

[inkz]

Немного погуглив на тему, пришел к выводу что не нужно, но меня все же мучает вопрос:

Если хранить в сессии только логин, нельзя ли его потом в ручную подменить в куках броузера и зайти от имени другого пользователя, не зная его пароля?

 

[AmdY]

inkz
зачем тебе пароль хранить в сессии? он нужен только при авторизации, затем ставишь переменную в сессию и проверяешь её if (isset($_SESSION['isAuth']))

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

 

[Духовность™]

Использовать исключительно для идентификации сессии - никогда этого не понимал. Зачем? Почему не обойтись одними лишь куками?

 

[Koc]

Духовность™
возможно соль в том, что б принудительно разлогинить юзера через N времени. Для кук он может пролонгацию сделать, а вот в сессиях-то ничего поменять он не сможет

 

[Mols]

Я вообще не понял с чего вдруг вывод/предположение о том, что сессии чел использует исключительно для идентификации ?

 

[Фанат]

нельзя ли его потом в ручную подменить в куках броузера и зайти от имени другого пользователя, не зная его пароля?

Нельзя, поскольку в куках никакого пароля и нету.

 

[inkz]

Почитал несколько статей про сессии, но мне все же непонятен именно этот момент.

Насколько я понял, с помощью кук можно делать тоже самое, но в случае с работы с сессиями, данные хранятся на сервере, а у клиента только id в куках (или url если они отключены).
Но ведь получается тогда, что клиент может поменять этот id, и таким образом получить доступ к чужой сессии?

Духовность™
Трудно ответить, я пока только учусь, делаю это скорее в академических целях.

 

[AmdY]

Почитал несколько статей про сессии, но мне все же непонятен именно этот момент.
Но ведь получается тогда, что клиент может поменять этот id, и таким образом получить доступ к чужой сессии?

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

 

[Фанат]

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

 

[Alien85]

О чем вы говорите?

Нужно взять за принцип:
В сессиях храним то, что юзеру менять нельзя!
В куках - все остальное!

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

И почему нельзя SID совать в URL? Если куки отключены, да пожалуйста, все равно по IP проверяем.

AmdY, вы предлагаете вместо SID отправлять дополнительный идентификатор - масло масляное.
Или вы думаете, что умнее разработчиков php?

Koc, вы думаете, что сессии нужны для того, что б принудительно разлогинить юзера через N времени?
то же самое можно сделать и без сессий!

вас человек об одном спрашивает, а вы ему .... . . .. .. . . ..

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

 

[Koc]

то же самое можно сделать и без сессий!

каким образом?

 

[Духовность™]

Какая подмена? О чем вы говорите? Какая привязка к IP? Что вы человеку мозги пудрите?

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

Суть авторизации на куках довольно проста: ставишь пользователю по факту ввода корректных данных две куки - ID его в базе и md5() от связки следующих строк:
- его логин
- его пароль в базе (который был при регистрации тоже в md5 захэшен)
- секретное слово, например 'dcdc35687989sdcsd'

Вот. Отсылаешь пользователю эти две куки по факту его входа в систему. Когда пользователь вошел, выбираешь из таблицы пользователей данные пользователя с ID, пришедшим из куки. Если запись найдена, сверяешь хэш из кук с хэшем от md5(user_login_из_базы, user_pass_из_базы, секретное_слово)

Если строки равны, все ок. Если нет - убиваешь куки и делаешь redirect.

Сессии - не лучший механизм для того, чтобы учиться делать аутентификацию.

 

[Вурдалак]

Духовность™ предложит вам немало способов усложнить себе жизнь.

 

[AmdY]

Alien85
как бы даже в мане предупреждают об опасности, и настройки по умолчанию всеми силами останавливают перед глупостью с тасканием SID в урле. Или вы думаете, что умнее разработчиков php?

Users may send a URL that contains an active session ID to their friends by email or users may save a URL that contains a session ID to their bookmarks and access your site with the same session ID always, for example.

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

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

 

[Alien85]

каким образом?

Суть авторизации на куках довольно проста: ставишь пользователю по факту ввода корректных данных две куки - ID его в базе и md5() от связки следующих строк:
- его логин
- его пароль в базе (который был при регистрации тоже в md5 захэшен)
- секретное слово, например 'dcdc35687989sdcsd'
Вот. Отсылаешь пользователю эти две куки по факту его входа в систему. Когда пользователь вошел, выбираешь из таблицы пользователей данные пользователя с ID, пришедшим из куки. Если запись найдена, сверяешь хэш из кук с хэшем от md5(user_login_из_базы, user_pass_из_базы, секретное_слово)

Koc, уже ответили за меня. Добавь дату последнего входа в базу и все! Когда тебе надо, тогда и выкидываешь пользователя.

Сессии - не лучший механизм для того, чтобы учиться делать аутентификацию.

Духовность™ предложит вам немало способов усложнить себе жизнь.

Духовность™, теперь подумайте, что вы написали: вы каждый раз проверяете, действительно ли пользователь вошел на сайт?
Получается, перехватив ваши куки можно войти на сайт под чужим именем и пользователь даже этого не узнает.
+ на последок: что вы будете делать, когда понадобится сделать автовход ("Запомнить меня")?

как бы даже в мане предупреждают об опасности, и настройки по умолчанию всеми силами останавливают перед глупостью с тасканием SID в урле. Или вы думаете, что умнее разработчиков php?

Если человек намеренно отключил куки, я думаю он знает, что делает. Если нет - флаг ему в руки и веселого серфинга в интернете. Кстати, второе ваше предложение совсем не к месту.

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

я не понимаю, к чему вы это написали? на этот вопрос я уже писал ответ - ssl.

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

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

 

[Koc]

Добавь дату последнего входа в базу и все! Когда тебе надо, тогда и выкидываешь пользователя.

так это те же сессии, вид сбоку

 

[Духовность™]

вы каждый раз проверяете, действительно ли пользователь вошел на сайт?

да, а что Вам не нравится?

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

я не понимаю, к чему вы это написали? на этот вопрос ... ответ - ssl.

+ на последок: что вы будете делать, когда понадобится сделать автовход ("Запомнить меня")?

time()+60*60*24*365

 

[AmdY]

ты же советовал хранить всё остальное в куках

О чем вы говорите?
Нужно взять за принцип:
В сессиях храним то, что юзеру менять нельзя!
В куках - все остальное!

 

[craz]

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

 

[inkz]

Духовность™
Интересная идея.
Сделал так, только в куках пользователя хранится хэш из связки логин+пароль, без id. Сейчас только понял, что искать по id, базе будет проще чем по хэшу, наверное в этом минус.
А зачем там секретное слово?

Получается что при первом залогивании пользователь отправляет нешифрованные данные, а дальше только md5 (разве его нельзя точно так же расшифровать, если поймать снифером? тогда как я понял, остается только ssl. но далеко не все сайты его используют, значит наверное это все же редкий случай...). А что если добавить в базу к пользователю, некое зашифрованное секретное слово, несвязанное с паролем и логином и передавать в куки пользователя только его + установить проверку по IP. Если IP сменился, то нужно логиниться повторно, таким образом перехват этого слова, ничего хакеру не даст, т.к. логина и пароля он не знает.
Тогда автозаход будет таким:
- пользователь отправляет это некое слово серверу, через куки,
-сервер отправит запрос к базе и найдет по нему нужного пользователя.
не знаю насколько такой подход можно назвать рациональным, ведь придется каждый раз дергать базу что бы сверить юзера.