Форум PHP

Здравствуйте! У меня два вопроса:
1) Лучше применять ключ шифрования выбранный случайно из нескольких, или шифровать только одним ключом (я шифрую печеньки)?
2) Как защититься от сниффинга (отснифить строку печенек - получить аккаунт)?

З.Ы. Печеньки - Cookies

Сразу видно, что у вас подход к cookies совершенно неправильный. Какие данные вы там хотите шифровать? Имя сессии? Никакой секретной информации там не должно быть, даже в зашифрованном виде. А чтобы ID сессии не подходил другим пользователям просто в данных сессий храните хеш от айпи+брайзер пользователя и в случае несовпадения с текущими данными - сбрасывать сессию.

$hash = md5($_SERVER['REMOTE_ADDR'].$_SERVER['HTTP_USER_AGENT'];

(код писал прямо на форум, могут быть ошибки)

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

можете и сосать. только на время сессиии ИП не меняется провайдерром

хи-хи.. это не так
Я читал, что АйПи может смениться в любой момент абсолютно прозрачно для клиента, те без разрыва соединения с прровайдером

Ссылку на источник.

Я об этом никогда не слышал и в любом случае провайдеры (насколько я знаю) не используют такие возможности ибо это чревато последствиями: некоторые сетевые приложения не получат ответы на свои запрос и ответ может попасть не в те руки.

Ссылку дать не могу, я читал это в книге. Если найду напишу.

Это как?

DHCP-сервер может отозвать адрес раньше истечения срока аренды?

Есть люди, у которых IP меняется при каждом обращении к странице. Они залогинятся, и их выкинет.
Я шифрую такую строчку:

serialize(array(str login, str pass, int status))

третий элемент - права юзера (-1...3).
Так делать, наверное, ненадо.
Расскажите, пожалуйста, как сделать несниффаемую авторизацию на Cookies?
У меня для уважающих себя людей (т.е. у кого нормальный браузер) сделал страничку для Digest-аутентификации (не снифаеццо. Если скажите, что сниффаеццо, покажите на примере). Но как хранить это между закрытиями браузера?

> Есть люди, у которых IP меняется при каждом обращении к странице. Они залогинятся, и их выкинет.

И это хорошо, а если безопасность им не важна добавьте флаг при авторизации "Не контролировать IP адрес" и в случае его установки не вносите хеш REMOTE_ADDR.

Я не могу добавить флаг, я использую WWW-аутентификацию.

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

Хотя если безопасность для вас не критична, то уберите вообще эту методику защиты. Проводите простую авторизацию и всё.

Безопасность критична. Можно послать всё на и просто не запоминать юзера, но хочется, чтобы эта возможность всё-таки была.

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

Может вы не правильно применяете этот хеш? Его нужно хранить в переменной сессии (не к cookies) и сравнивать с текущими параметрами. Cookies всегда хранят только SID.

Сессии не долговечны. А вот как сделать авторизацию на куках?

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

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

если авторизация сделана правильно, каковы шансы, что злоумышленик пробьется к чужому аккаунту? Или все-таки не пробьется?

Если авторизация на куках, шансов много.

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

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

Слабым местом в моём подходе останется лишь то, что данные для первоначальной авторизации передаются в не зашифрованном виде, тут лучше использовать SSL.

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

Вот самая большая уязвимость и есть в SID.
А SSL - удовольствие очень дорогое.

Ничего не дорогое, а SID какраз я и рассказал как защищать.

>Слабым местом в моём подходе останется лишь то, что данные для первоначальной авторизации передаются в не зашифрованном виде, тут лучше использовать SSL.
специально для слабых мест

По вашей ссылке стойкость хеша только страдает из-за использования соли (challenge). Она бесполезна. Алгоритм имеет право на жизнь лишь в узких рамках и большинство атак он всё-равно не остановит.

>По вашей ссылке стойкость хеша только страдает из-за использования соли (challenge).

Простите, стойкость чего страдает?

В зависимости от длинны пароля и длинны соли стойкость хеширования (md5 - функция хеширования) страдает в плане безопасности (те вы позволяете злоумышленнику знать часть пароля заранее), пока-что в ней нашли только коллизии, но полноценный взлом не сильно затянется. Как минимум соль не добавит безопасности, абсолютно, ведь злоумышленник сможет её видеть в чистом виде.

>те вы позволяете злоумышленнику знать часть пароля заранее.

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

Скорее наоборот, смотрите мы возвращаем скрипту вот это:

MD5(challenge + MD5(password))

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

Злоумышленнику не составит труда перехватит значение challenge, что ещё больше упрощает его доступ к данным (часть первоначального хеша зарание известна). Зачем тогда включать эту переменную в процесс? Она ничего не даёт по сути, автор просто насмотрелся на приёмы шифровки пароля с солью (которая в отличии от вашего примера хакеру не известна) в пхп, которая используется для противостоянию дешифровки паролей краденных с базы.

И как там написано от атаки типа Man-in-the-middle этот вышеуказанный способ вообще не поможет. Только шифрование, те. преимущественно SSL.

И учтите что от в некоторых случаях работа порта функции md5 в JS может отличаться от работы PHP и давать разные результаты, пользователь никогда потом не сможет залогиниться. Об этом написано в той статье.

Продолжайте противостоять дешифровке краденых паролей из базы...