Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
Объектно-ориентированное программирование на PHP. Авторы: Кузнецов М.В., Симдянов И.В. MySQL 5. В подлиннике. Авторы: Кузнецов М.В., Симдянов И.В. C++. Мастер-класс в задачах и примерах. Авторы: Кузнецов М.В., Симдянов И.В. MySQL на примерах. Авторы: Кузнецов М.В., Симдянов И.В. PHP 5/6. В подлиннике. Авторы: Кузнецов М.В., Симдянов И.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Форум PHP

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум Структурный форум

тема: Запомнить меня (на куках)
 
 автор: Брянский   (27.09.2009 в 02:21)   письмо автору
 
 

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

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

  Ответить  
 
 автор: Trianon   (27.09.2009 в 09:03)   письмо автору
 
   для: Брянский   (27.09.2009 в 02:21)
 

Вы можете писать туда не пароль, а некую другую аутентифицирую сеанс информацию.

>Но это ведь не надежно все равно..

А вот здесь, сказав А, нужно сказать и B. "Но это ведь не надежно все равно.. Я опасаюсь следующих вариантов атак..." и дальше можно пытаться размышлять, как чего избежать.

  Ответить  
 
 автор: Брянский   (27.09.2009 в 14:19)   письмо автору
 
   для: Trianon   (27.09.2009 в 09:03)
 

>Вы можете писать туда не пароль, а некую другую аутентифицирую сеанс информацию.

Т.е. туда писать ID сессии?
А что тогда в куки записать?

  Ответить  
 
 автор: Брянский   (27.09.2009 в 14:28)   письмо автору
 
   для: Trianon   (27.09.2009 в 09:03)
 

Я вот не пойму что писать в куки и что в базе.
Допустим при регистрации я пароль записал так:

$pass = md5(pass.$sol);

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

В куках например будет записано:
id - пользователя.
pass - пароль, так-же обработанный md5($pass.$sol);

Потом когда сверяем куки, то будет запрос вида:
mysql_query("SELECT * FROM users WHERE id='$_COOKIE[id]' && pass='$_COOKIE[pass]'");

Это будет надежно?

  Ответить  
 
 автор: В. В.   (27.09.2009 в 14:39)   письмо автору
 
   для: Брянский   (27.09.2009 в 14:28)
 

интересные обсуждения темы:
http://www.softtime.ru/forum/read.php?id_forum=1&id_theme=67215&page=12
и
http://www.softtime.ru/forum/read.php?id_forum=1&id_theme=67932&page=5

  Ответить  
 
 автор: Брянский   (27.09.2009 в 14:43)   письмо автору
 
   для: В. В.   (27.09.2009 в 14:39)
 

Спасибо, обязательно почитаю.

  Ответить  
 
 автор: neadekvat   (27.09.2009 в 16:32)   письмо автору
 
   для: Брянский   (27.09.2009 в 14:28)
 

Нет, не будет, т.к. куки спокойно могут стырить и на другой машине выдать себя за другого человека. Так злоумышленник, просто обновив страницу, будет залогененным под другим именем.
В куки нужно записать еще что-то такое, чем вы отличите пользователя, которому сами записали куки от пользователя, который только делает вид, что вы его уже знаете.
К примеру, записывать User Agent или айпишник (во втором случаи люди с динамическим айпишником будут очень недовольны)

  Ответить  
 
 автор: cheops   (27.09.2009 в 16:55)   письмо автору
 
   для: neadekvat   (27.09.2009 в 16:32)
 

>куки спокойно могут стырить
Спокойно - это немного не точно, точнее будет сказать при наличии на сайте XSS-инъекции и переходе пользователя по специально-подготовленному эксплоиту, при прослушке трафика в локальной сети или при наличии на стороне пользователя трояна, похищающего cookie.

  Ответить  
 
 автор: Trianon   (27.09.2009 в 17:04)   письмо автору
 
   для: cheops   (27.09.2009 в 16:55)
 

...а также при посредстве инсайдера (человека, имеющего досмтуп к компьютеру) или путем фишинга/обмана (когда данные кукис передает сам владелец эккаунта)

  Ответить  
 
 автор: neadekvat   (27.09.2009 в 17:29)   письмо автору
 
   для: Trianon   (27.09.2009 в 17:04)
 

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

  Ответить  
 
 автор: Trianon   (27.09.2009 в 17:36)   письмо автору
 
   для: neadekvat   (27.09.2009 в 17:29)
 

Собственно, почему я вслед за трояном дописал еще пару моментов?
Потому что, на мой взгляд, о том, что к кукисам придется отнестись чуть ли не так же внимательно , как и к паролям, рядовой пользователь интернета может и не знать (да в сущности и не обязан, если рассуждать здраво...)

  Ответить  
 
 автор: neadekvat   (27.09.2009 в 17:41)   письмо автору
 
   для: Trianon   (27.09.2009 в 17:36)
 

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

  Ответить  
 
 автор: cheops   (27.09.2009 в 17:51)   письмо автору
 
   для: neadekvat   (27.09.2009 в 17:41)
 

Уже много раз обсуждали эту тему: есть разные ресурсы, разумеется пароль от OnLine-счета или интернет-магазина гораздо более ценен, чем от форума или чата. Кому-то лень каждый раз вводить пароль, кому-то нет. Ситуации бывают разные - не во всех случаях можно сказать: следует поступать так и только так - очень часто бывает круг задач, где приходится идти на компромис или против обычного правила.

  Ответить  
 
 автор: neadekvat   (27.09.2009 в 17:59)   письмо автору
 
   для: cheops   (27.09.2009 в 17:51)
 

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

  Ответить  
 
 автор: cheops   (27.09.2009 в 18:04)   письмо автору
 
   для: neadekvat   (27.09.2009 в 17:59)
 

>Короче, снять с себя ответственность
А в этом нет ничего страшного, поиск зон ответственности в области IT идет десятилетиями. Если раньше один менеджер нес ответственность за одного, десять, максимум несколько десятков человек. То в IT речь идет об тысячах и десятках тысяч пользователей - нет никакой возможности даже широким штатом гарантировать их безопасность или осведомленность. Поэтому приходится делегировать ответственность и делегировать в том числе в зонах, которые раньше целиком лежали на плечах поставщика услуг.

PS Это даже не изобретение Web-разработчиков, это началось до Web.

  Ответить  
 
 автор: Trianon   (27.09.2009 в 18:08)   письмо автору
 
   для: cheops   (27.09.2009 в 18:04)
 

не о гарантиях речь... никто ж от поставщика услуг никаких гарантий не требует? речь о возможностях.
делегировать по соглашению - это одно.
делегировать по дефолту - совсем другое.

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

  Ответить  
 
 автор: cheops   (27.09.2009 в 18:12)   письмо автору
 
   для: Trianon   (27.09.2009 в 18:08)
 

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

  Ответить  
 
 автор: Trianon   (27.09.2009 в 17:59)   письмо автору
 
   для: neadekvat   (27.09.2009 в 17:41)
 

не так категорично.

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

К примеру, на этом форуме умыкание кукиса (даже если он хеш) приводит к тому, что враг не только получает возможность создавать темы и отвечать на реплики, но и права на модификацию профиля и привилегии смены пароля. А зачем, спрашивается, по автологону всё это разрешать? Часто Вы визитку меняете?

Да и про подбор самого пароля по хешу сказано достаточно.

  Ответить  
 
 автор: neadekvat   (27.09.2009 в 18:17)   письмо автору
 
   для: Trianon   (27.09.2009 в 17:59)
 

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

А про этот форум - я был неприятно удивлен, когда увидел свой пароль в исходниках (да, здесь я пользуюсь автологином)

  Ответить  
 
 автор: Брянский   (27.09.2009 в 18:14)   письмо автору
 
   для: Брянский   (27.09.2009 в 02:21)
 

Ну вобщем так ничего и не понял :)
Что лучше хранить в куках и как их лучше защитить? :)

  Ответить  
 
 автор: cheops   (27.09.2009 в 18:17)   письмо автору
 
   для: Брянский   (27.09.2009 в 18:14)
 

1) Если пароль, который хранят пользователи дает в случае его получения злоумышлеником доступ к деньгам или каким-то другим преимуществам - храните только логин, запрашивая в каждом критическом месте пароль.
2) Если пароль не значим (не приносит выгоды в случае его получения), а пользователей необходимо оградить от постоянного ввода пароля (форум, чат и т.п.) - храните в том числе и пароль, тщательно следя за тем, чтобы не допускать на сайте XSS-инъекции.

  Ответить  
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования