|
| |
|
|
| |
для: BinLaden
(31.08.2008 в 15:28)
| | | Ну вот.... осталось вам убедить только меня.
Если спёрли сессию... то её сперли со всеми потрохами... т.е. со всем тем что вней на данный момент находится. и будь там 10000 паролей что из того?
Опять же, скрипт, меняющий пароль, может просто стереть ид сессии из таблицы
Мы говорим об угоне сессии или уже о взломе сервера? Что ещё за скрипт меняющий пароль? | |
| |
|
|
| |
|
|
| |
для: BinLaden
(31.08.2008 в 15:28)
| | | чего-то подобное - готов признать, как альтернативу. Например, писать в сессию время последней установки пароля. | |
| |
|
|
| |
|
|
| |
для: Trianon
(31.08.2008 в 15:23)
| | | > Опять же, скрипт, меняющий пароль, может просто стереть ид сессии из таблицы.
Вот именно! Я же и говорил выше, что для этого их нужно записывать в эту самую таблицу. А запись пароля (ну или чего-то подобного) я рассматриваю как альтернативу, которой, правда, сам я никогда не пользовался. | |
| |
|
|
| |
|
|
| |
для: BinLaden
(31.08.2008 в 15:10)
| | | >Я имею ввиду, что это была бы какая-то возможность уничтожить сессию в случае смены данных, с помощью которых она была создана. Обычно же проверяется логин/пароль или, что эквивалентно, идентификатор и пароль. В случае смены пароля украденная сессия получается продолжает спокойно жить.
Опять же, скрипт, меняющий пароль, может просто стереть ид сессии из таблицы. | |
| |
|
|
| |
|
|
| |
для: BinLaden
(31.08.2008 в 15:10)
| | | В случае смены пароля украденная сессия получается продолжает спокойно жить.
о какой смене пароля идёт речь?
Обычно же проверяется логин/пароль
Да но они приходят от пользователя. А проверять на соответствие логин/пароль взятый из сессии бессмысленно, т.к. он всегда будет совпадать. | |
| |
|
|
| |
|
|
| |
для: Trianon
(31.08.2008 в 15:04)
| | | Если честно, то не понимаю как можно проверять сессию на достоверность, а точнее зачем. Её же не могут подделать.
Так что на вопросы 1, 2 ответить не могу.
Я имею ввиду, что это была бы какая-то возможность уничтожить сессию в случае смены данных, с помощью которых она была создана. Обычно же проверяется логин/пароль или, что эквивалентно, идентификатор и пароль. В случае смены пароля украденная сессия получается продолжает спокойно жить. | |
| |
|
|
| |
|
|
| |
для: BinLaden
(31.08.2008 в 14:53)
| | | Если я правильно понял, предлагается ввести защитный ключ, которым проверять сессию на достоверность.
Но тогда возникают два вопроса.
1. Если бы этот ключ жил в СOOKIES - я бы понял.
Но и сессия и таблица на стороне сервера. Что даст такое сравнение "по одну сторону прилавка"?
2. зачем привязывать его к паролю? Не лучше ли сгенерировать для этого уникальный идентификатор без привлечения такой уязвимой вещи, как пароль?
Нет, по другому: Почему нужно именно пароль использовать при создании такого ключа?
Заметьте : пароль - не уникальный идентификатор. Никто не может требовать от пользователя, чтобы его пароль был отличен от других паролей. | |
| |
|
|
| |
|
|
| |
для: Trianon
(31.08.2008 в 13:10)
| | | >>Понятно ведь, что если бы была возможность создавать несколько сессий,
>то злоумышленник, сумевший украсть этот 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
}
?>
|
> Ну вот, начинается.
Понимаю негодование:) Не буду придумывать. | |
| |
|
|
| |
|
|
| |
для: BinLaden
(31.08.2008 в 12:43)
| | | >> Не вижу связи между вопросами.
BinLaden, поймите, я не придираюсь, и не пытаюсь спорить ради спора.
Я пытаюсь понять ход мыслей.
>Понятно ведь, что если бы была возможность создавать несколько сессий,
то злоумышленник, сумевший украсть этот token,
session_id?
>смог бы пользоваться аккаунтом и при смене пароля, что не очень приятно.
любые неаутентичные действия в той или иной степени неприятны.
>Поэтому пароль может компенсировать как-то этот промах с сессиями,
Каким образом?!
>в противном случае надо записывать все идентификаторы сессий в таблицу для правильной организации аутентификации.
Кто б спорил. Токены аутентификации так или иначе, конечно, надо записывать.
Даже если ими являются идентификаторы сессии.
Но даже если их не записывать - от чем поможет пароль в сессии?
>В общем-то я не защитник идеи записывать пароль в сессию, но это может быть ответом на "зачем писать пароль в сессию?".
Или не пароль, а какой-то хеш.
Ну вот, начинается.
Хеш - это уже не пароль.
Какой-то хеш - уже совсем не пароль.
Но даже если и так, то до меня все равно не доходит - чем спасет [некий] хеш пароля , записанный в сессионный массив?
Давайте уж дороем до истины... | |
| |
|
|
| |
|
|
| |
для: Trianon
(30.08.2008 в 12:50)
| | | > Не вижу связи между вопросами.
Понятно ведь, что если бы была возможность создавать несколько сессий, то злоумышленник, сумевший украсть этот token, смог бы пользоваться аккаунтом и при смене пароля, что не очень приятно. Поэтому пароль может компенсировать как-то этот промах с сессиями, в противном случае надо записывать все идентификаторы сессий в таблицу для правильной организации аутентификации.
В общем-то я не защитник идеи записывать пароль в сессию, но это может быть ответом на "зачем писать пароль в сессию?". Или не пароль, а какой-то хеш. | |
| |
|
|
|
