Комментарии к статье ""
| 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. |
