PHP в деталях



         

Комментарии к статье ""


4.7.2001 08:17  Balbes

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

Ответ DL:

Генерить новый пароль.

4.7.2001 08:52  YEAA  []

Цитата:[22.05.01] Небольшая новость. Вот уже как 3 недели юзаю свежескаченную версию IE 6.xx.xxxx. Да, все-таки куки по умолчанию там отключены. А заставить пользователя что-либо сделат в настройках, чтобы попасть к вам на сайт, сами понимате невозможно. Да еще это будет назвываться "понижение уровня безопасности", чего от бедных пользователей добиться, все равно что пароль от Интернета добыть. Некоторые очень смелые пользователи и пароль от Инета сообщат, но

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

Ответ DL:

Откуда цитата? Кто такой бред пишет? Я не знаю, какая моча в голову БГ ударила, но куки - это нормальная технология. Что, всё передавать через адресную строку, что ли?!

4.7.2001 17:59  Максим Деркачев  []

> Кстати, именно так можно залазить под паролем и без ведома друга

> в web-интерфейсы, строящие авторизацию на сессиях.

Не совсем корректно.

Системы аутентификации, построенные на сессиях обычно вообще не используют логины/пароли в куке. Вместо этого в сессии регистрируется флажок, залогинился ли пользователь или нет. При этом, если хэшик идентификатора сессии будет светиться в параметрах GET, и есть возможность их перехватить во время, когда сессия (и аутентификация) активны, то можно залезть "под юзера" даже не зная его логина и пароля. Однако совсем не обязательно этому хэшику появляться в параметрах GET.

При работающих куках id сессии появится в QUERY_STRING один раз, а именно - на втором клике (если его туда принудительно не пихать). Только в этот момент его можно поймать в логах прокси, и и "сесть" на сессию без использования сниффера. При этом, можно запретить светить session id в QUERY_STRING вообще.

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

Т.о. для увеличения безопасности системы построенной на сессиях есть несколько решений. Наиболее простое - обязать клиентов пользоваться куками (в целях их же безопасности). Т.к. куки включены примерно у 95% всех пользователей, то этот недостаток не является критичным. Поймать session id можно будет только сниффером.

Другое решение - ограничить сессию одним адресом. Действенно, но хуже. Куча людей может сидеть за одним прокси, и они смогут подглядывать в сессии друг к другу. С другой стороны, один пользователь может кидать запросы с совершенно разных адресов, не вставая с кресла - если его провайдер использует load balancing, или динамически переключается с магистрали на магистраль в зависимости от тарифных планов. Так что это не очень хороший выход.

Так что аутентификация, построенная на сессиях, совсем не обязательно ломается при помощи простого copy/paste.

<


Содержание  Назад  Вперед