Форум PHP

Покажите пожалуйста примером, как хранить логин и пароль в кукисах?

Примером (дурным - в данном аспекте) является этот форум. Исходники лежат в разделе Downloads

Не надо этого делать.

Если хочется аутентифицировать машину посетителя по автологону (без ввода логина/пароля), лучше заведите для этого таблицу.
Добавляя очередную машину, ставьте ей кукис со строкой - случайно сгенерированным набором символов, а в таблицу заносите id пользователя, параметры браузера и эту самую сгенерированную строку. И лучше бы дать возможность пользователю такие записи удалять.

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

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

> Насчет браузера, а если у пользователя несколько браузеров?
А что, у браузеров будут общие cookies?

В том то и дело что нет.

> В том то и дело что нет
Где Вы видел автологин, позволяющий входить с разных браузеров?

С разных, нет.
Я имел ввиду насчет пароля, хранением хешем.

> Где Вы видел автологин
Видели :))

> Я имел ввиду насчет пароля, хранением хешем
Я не понял Вас. При чем тут хешированный пароль, когда Вам не понравилась идея запоминать какие-то данные браузера. Это, очевидно, для дополнительной защиты.

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

А если вообще ни одного не будет?
А если он в интернет-кафе ходит?
А если с мобильника?
А если он не знает что такое интернет?!



>В куках если хранить пароль то хешированный.
Зачем хранить хешированный пароль? Что это даст?
Зачем храня хеш, считать, что хранишь пароль, пусть и хешированный?
Зачем хранить вообще пароль?

Может лучше нитроглицерин хранить?

Довели.

>если вообще ни одного не будет?
То вообще в инет не выйдет.

>А если он в интернет-кафе ходит?
Да пусть ходит.

>А если с мобильника?
Очень круто, но не удобно.

> если он не знает что такое интернет?!
Тогда все остальное отменяется.



Разговор ни о чем

>Зачем хранить вообще пароль?
это по усмотрению автора.
Если Вас интересует почему на форуме так , то вопросы к техподержке форума

>>Зачем хранить вообще пароль?
>это по усмотрению автора.

Я спросил Вас, потому что разговор вернули к идее хранения пароля именно Вы.

>Если Вас интересует почему на форуме так , то вопросы к техподержке форума

Меня интересует Ваше мнение. В контексте Вашего, заметьте, ко мне, предложения.
( Faraon (25.12.2007 в 21:37) to: Trianon ) : В куках если хранить пароль то хешированный.
Пока интересует.

Ладно, встречный вопрос, а чем Вас не устраивает хранение хеша пароля( хоть в двойном, тройном и тд хешировании) ?

Лично я при создании системы автологина не храню хешированный пароль, т.к. при перехвате cookies взломщик будет иметь доступ к аккаунту до смены пароля, а не до logout'а, где уничтожаются записи с ключами, о которых говорит Trianon.

А у Вас хранится только одна запись на пользователя?

Да. Этот ключ у меня просто в отдельной колонке в таблице с аккаунтами.

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

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

OK, если у нас будет общий проект, то мы так и сделаем :)))

Да я, собственно, эмбарго не накладывал :)))

Дима, а чем тебе не нравится такой алгоритм:

<? $hash=md5(md5($admin_key).$user_pass); //$user_pass - пароль пользователя //$admin_key - некая последовательность символов, заданная админом в настройках сервера.

В этом случае, пароль поддается дешифровке только после умыкания $admin_key с сервера. Тогда уж проще умыкнуть сам пользовательский пароль из БД.
Точнее, md5($admin_key) можно получить, путем регистрации на целевом сайте и перебором собственной куки.

В качестве автологон - токена?
Или в качестве параметров аутентификацииприменяемых при проверке пароля, вводимого руками?

Если первое - тем, что в вычислении задействован пароль. Зависимость от него условиями задачи не требуется, ведь так? Тогда зачем?
Собственно, я сам предлагал нечто такое ... в одной из тем.
Конечно это лучше чем пароль в открытом виде, и даже лучше чем чистый хеш md5, но зачем?

Если второе, то имеет смысл ввести зависимость от известных данных.
В данном случае - от логина пользователя.

>Конечно это лучше чем пароль в открытом виде, и даже лучше чем чистый хеш md5, но зачем?
просто я не вижу чем твое предложение принципиально отличается. Ты просто вводишь еще один пароль, для автологина. Ну у нас теперь два независимых пароля для разных целей.... в чем защищенность? Из предложенного мной хэша, получать пароль попросту нецелесообразно - проще взломать фтп сервер или сервер БД. Так как admin_key может быть абсолютно произвольным набором символов любой длинны (мне же его не надо запоминать). А украв и подделав куку все равно как авторизоваться по "хэшу на основе пароля" или по "второму паролю".

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

Я бы не стал называть его паролем. Если его кто-то перехватит, он не сможет сделать ни одно действие, для которого требуется ввод пароля руками.


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

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

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

>В том что по хешу и admin_key (а это велична известная, как минимум серверу) несложный пароль можно подобрать. А значит этим мы создаем соблазн атаки охоты за этим admin_key.
Серверу так же известны хэши паролей. Так не логичнее ли охотится непосредственно за ними, если уж все равно атаковать сервер?

Серверу - неизвестны.
Известны БД.

В том случае, если они в БД хранятся:)

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

Я не спорю, просто раз уж мы начали придираться к словам...:)
Под сервером, я естественно подразумевал сервер БД.

admin_key ты вроде как предлагал вшить в php-код. Впрочем, я мог понять тебя неправильно.

Вы испльзуете типа один из механизмов 1C ?

>чем Вас не устраивает хранение хеша пароля( хоть в двойном, тройном и тд хешировании) ?

Умыкнув хеш, пароль проще подобрать.
Насколько проще - вопрос кучерявости самого пароля и мощности вычислительных ресурсов - вопрос второй.


>Ладно, встречный вопрос, а
Это не ответ.

>Это не ответ.
Может быть и не ответ, а Вы сами обоснуйте по этому вопросу.

>>Это не ответ.
>Может быть и не ответ, а Вы сами обоснуйте по этому вопросу.

Сам я, пожалуй, потеряю интерес к Вашим репликам. В принудительном порядке.

Эта тема если не ошибаюсь уже обсуждалась.
Лично моё мнение, надо делать как сказал Trianon (заводить новую таблицу) + ограничивать права автологина. Хотябы запрет на смену пароля.

Очень интересная дискуссия.
Может ктонить покажет пример работы с кукисами, а именно запись, чтение и удаление.
Как я понимаю, кукисы это своего рода память браузера.

Установить куки можно при помощи функции setcookie().
Прочитать из суперглобального массива $_COOKIE.
Удалить, путем установки времени жизни куки меньше текущего.

Для "Елена Смирнова" сходите на страницу:
http://www.frolov-lib.ru/books/bsp/v34/ch7.htm#ch7_0