Форум PHP

Я себе так представляю:
Вводиться логин, пароль в форму, введенные данные сверяются с теми, что хранятся в БД, если всё верно логин и пароль записываются в сессию, и в коде каждого файла администрирования проверяется, имеются ли сессии с правильной связкой логин+пароль.
Правильно ли таким способом ограничивать доступ?

Достаточно одного логина или какойто другой переменной зарегистрированной в сесии. А пароль как лежал в БД в обличии хеша, так пусть там и лежит)

зачем писать пароль в сессию?

А как Вы считаете - можно ли разрешать пользователям создавать несколько сессий подряд, под которыми он прошёл аутентификацию? То есть одновременно будет существовать 2-3 сессии, в файлах которых будет записан идентификатор пользователя "Вася".

Думаю не стоит. Сессия должна быть одна (правда ошибки предусмотреть стоит). А так вы правы

>>зачем писать пароль в сессию?
>А как Вы считаете - можно ли разрешать пользователям создавать несколько сессий подряд, под которыми он прошёл аутентификацию? То есть одновременно будет существовать 2-3 сессии, в файлах которых будет записан идентификатор пользователя "Вася".

Не вижу связи между вопросами.
Я вообще не считаю сессионный идентификатор удачным токеном аутентификации. Но дело же не во мне?

А можно или нет - решает автор.. Мне бы не понравилось.

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

>Я в этом вопросе не профи, а потому создал тему, где спросил насколько удачна идея с сессиями.
>А как можно еще поступить, не используя сессий?
Использовать Cookie.

[поправлено модератором]

> Не вижу связи между вопросами.

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

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

>> Не вижу связи между вопросами.
BinLaden, поймите, я не придираюсь, и не пытаюсь спорить ради спора.
Я пытаюсь понять ход мыслей.

>Понятно ведь, что если бы была возможность создавать несколько сессий,
то злоумышленник, сумевший украсть этот token,
session_id?

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

>Поэтому пароль может компенсировать как-то этот промах с сессиями,
Каким образом?!

>в противном случае надо записывать все идентификаторы сессий в таблицу для правильной организации аутентификации.

Кто б спорил. Токены аутентификации так или иначе, конечно, надо записывать.
Даже если ими являются идентификаторы сессии.
Но даже если их не записывать - от чем поможет пароль в сессии?

>В общем-то я не защитник идеи записывать пароль в сессию, но это может быть ответом на "зачем писать пароль в сессию?".

Или не пароль, а какой-то хеш.
Ну вот, начинается.
Хеш - это уже не пароль.
Какой-то хеш - уже совсем не пароль.

Но даже если и так, то до меня все равно не доходит - чем спасет [некий] хеш пароля , записанный в сессионный массив?

Давайте уж дороем до истины...

>>Понятно ведь, что если бы была возможность создавать несколько сессий,
>то злоумышленник, сумевший украсть этот token,
>session_id?

Да.

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

<?php $query = "SELECT * FROM `accounts` WHERE `id` = {$_SESSION['id']} AND `password` = '" . mysql_escape_string($_SESSION['password']) . "';"; $result = mysql_query($query); if(  mysql_num_rows($result) < 1 ) {     # logout } ?>

> Ну вот, начинается.

Понимаю негодование:) Не буду придумывать.

Если я правильно понял, предлагается ввести защитный ключ, которым проверять сессию на достоверность.

Но тогда возникают два вопроса.
1. Если бы этот ключ жил в СOOKIES - я бы понял.
Но и сессия и таблица на стороне сервера. Что даст такое сравнение "по одну сторону прилавка"?

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

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

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

Так что на вопросы 1, 2 ответить не могу.

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

В случае смены пароля украденная сессия получается продолжает спокойно жить.
о какой смене пароля идёт речь?
Обычно же проверяется логин/пароль
Да но они приходят от пользователя. А проверять на соответствие логин/пароль взятый из сессии бессмысленно, т.к. он всегда будет совпадать.

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

Опять же, скрипт, меняющий пароль, может просто стереть ид сессии из таблицы.

> Опять же, скрипт, меняющий пароль, может просто стереть ид сессии из таблицы.

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

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

Ну вот.... осталось вам убедить только меня.
Если спёрли сессию... то её сперли со всеми потрохами... т.е. со всем тем что вней на данный момент находится. и будь там 10000 паролей что из того?
Опять же, скрипт, меняющий пароль, может просто стереть ид сессии из таблицы
Мы говорим об угоне сессии или уже о взломе сервера? Что ещё за скрипт меняющий пароль?

http://softtime.ru/article/index.php?id_article=27

Штацесс катит вроде только для ограничение доступа к файлами администрирования.
А если речь идет об ограничении доступа к аккаунту пользователя. То есть, чтобы пользователь передвигался по своему аккаунту и не вводил постоянно логин+пароль.