Логин пароль cookie шифрование
 

Подскажите пожалуйста, в какой форме должны хранится логин и пароль пользователя в cookie. Их же надо шифровать?

они не должны хранится в кукисах ни при каких условиях
но, к примеру вконтакт ранее хранил мыло в открытом виде, и пароль в md5 в кукисах.
сейчас так не делают уже

в кукисах следует хранить SESSID как средство сохранения сессии

Ясно, спасибо Gvozd.
Просто сессиями никогда не пользовался.

А вот когда логинятся надо данные как-нибудь шифровать для отправки на сервер?

в общем случае - не надо.
для частных случаев есть HTTPS

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

upd: SESSID вроде сама кладется в куки?

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

Я думаю, что надежнее хранить рандомное число, которое обновляется при каждом запросе страницы. Стырить SESSID можно всегда. Пока тырится сессия, пользователь скорее всего успеет обновить страницу и с левого компа уже не зайти. В общем, это повысит безопасность, хоть и не на 100%.

хм
теперь понятнее.

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

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

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

PS у меня устойчивое чувство, что мы тут занимаемся изобретательством велосипеда, и что уже есть достаточно безопасные схемы поддержания сессии.

Это очень редкий случай.
Эту проблему можно решить так:
1. При смене рандомного числа, запоминаем прошлое, а так же время запроса.
2. Если приходит запрос с прошлым числом и время больше, например, минуты, прошедшее со времени последнего обновления - сбрасывать доступ. Если меньше минуты - разрешать доступ и так же обновлять число, но не переписывать старое. Т.е. у нас остальные вызовы будут обработаны.
3. Если пришло новое число - пункт 1.

Думаю, что минуты вполне достаточно для попытки достучаться до сервера. Если же пользователь больше минуты не обновлял страницу и сессия жива - будет использоваться последнее число, полученное при прошлом обращении. Хочу подчеркнуть, что это очень редкий случай.

Думается мне, что безопасность тут не пострадает.

Возможно, но почему бы и не развить эту тему?:)

Не так уж редко смотрят сайт в нескольких окнах сразу.

B~Vladi,
ну, я также думал разрулить
теперь злоумышленнику достаточно перехватить в любой момент сессию с случайным числом, и обновляя страницу раз в минуту, он будет поддерживать соединение

А если хранить логин и пароль в двух глобальных переменных?
window.login и window.parol ?

mycoding,
ты что шутишь?
конечно же это будет более чем небезопасно

А почему? Все злоумышлиники рассчитывают, что данные в cookie.
Т.е. от случайных скриптов по угону паролей уже затились.
Страница закрыта данных нет.
Можно конечно просто idssesion держать в переменной.
Как можно данные угнать в этом случае.

нормальный злоумышленник просечет фишку на раз

mycoding, тогда уж не локально, а где нить внутри функции, чтобы хакер не сразу их нашел:D

На самом деле кроме сессий похоже ничего нет.
А моя идея с глобальными переменными плохая уже понял.

Как сделать автоматическую авторизацию (галочка "запомнить меня") не сохраняя логин/пароль в куках? Я не вижу способа.

хеширование здесь ничего не меняет.

При входе генерировать случайный ключ, записывать в БД и куки. При следующем входе ищем этот ключ и если находим, восстанавливаем сессию.

если кто то получит доступ к кукам, то с помощью этого ключа он получит доступ к аккаунту, если в куках логин/пароль, тоже получит доступ к аккаунту, в чем разница?

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

Не дать перехватчику куков авторизовать можно только привязав аккаунт к IP.

зачем тогда в этой теме все пытаются хранить в куках что то странное, а не логин/пароль в чистом виде?

хорошо, еще раз: если хеш дает доступ к аккаунту наравне с парой логин/пароль, то какая разница? Или у вас защита по принципу "захешировать/зашифровать все что возможно, а разбираться потом будем"?

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

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

Вот именно. Поэтому толку от привязки мало. Разве что привязывать к подсети.

Не наравне. Особо важные операции обычно требуют повторного ввода пароля, как например, его смена. Опять же, сессия может и умереть, в отличие от логина/пароля.

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

речь про запоминание между сессиями.
.... вообще то .... .... короче я понял, в чем фишка айдишника предложенного B@rmaley-ем: злодей по нему так же может авторизоваться, на этом этапе разницы никакой, но вот дальше-то я ничего не продумывал, а дальше так: злодей авторизуется, id меняется и записывается ему в куки, теперь злодей может спокойно заходить на чужой аккаунт, id при этом каждый раз в куках и в базе меняется, дальше приходит настоящий владелец, зайти по id не может, т. к. у него остался старый id, вводит пароль, id опять новый и у злодея он уже устарел, если он не имеет возможности второй раз добыть новый id, то он отдыхает. Нужно только id делать не совсем случайный, а случайный из незанятых.

.... появляется вероятность следующего: у пользователя в базе занят id, он высвобождается при авторизации злодея, но в куках у настоящего пользователя он остался, другой пользователь случайно занимает высвободившийся в базе id, заходит первый пользователь и попадает на аккаунт второго. Результат: злодей сидит на аккаунте первого пользователя, первый пользователь на акккаунте второго .... . Вероятность ничтожная, но она есть. Решение: логин в куках тоже запоминать, он же даст элемент уникальности и не нужно следить, занят ли id. Теперь можно в базе хранить не чистый id, а хеш от него, теперь если злодей как-то сможет считывать с базы эти хеши, то они ему ничего не дадут, тогда как в варианте без логина в куках, злодей получает из базы чистые айдишники и значит доступ вообще ко всем аккаунтам. Но это совсем не серьезный плюс, т. к. если злодей может считывать хеши, то он уже и так, наверняка, имеет полный доступ к базе, а это в любом случае полный п....ц, хоть хеши там, хоть нет.

Плюсы варианта с логином в куках:
1. нет мизерной вероятности попадания взломанного пользователя на случайный аккаунт. (Вероятность настолько ничтожна, что можно не считать.)
2. хеши вместо чистых id в базе. (Тоже можно не считать, почему объяснил выше.)
3. если id не подошел, то можно поле "логин" из куков заполнить. (Хоть что-то значимое.)
4. раз сервер знает логин из куков, он может предупредить пользователя id которого не подошел, что на его аккаунт заходили с другого компа. (Вот это действительно значимый плюс.)

Минусы варианта с логином в куках:
1. логин в куках в чистом виде. (Можно не считать, т. к. в варианте без логина в куках увидеть этот логин тоже не проблема.)




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

UPD: афигеть, понаписал.

UPD2: сорри, плюсы не ставятся, для Kolyaj понятно почему, недавно добавлял, а вот почему B@rmaley-ю не хочет ставить, загадка.

Зачем контролировать случайность, когда можно сделать такой id, какой нужно? Возьмем мешанину из

md5($login . $ip. microtime() . mt_rand() /* добавить еще переменных по вкусу */)

Если только защищаться от коллизий md5...

да, я про это как раз.

Это слишком маловероятная вещь, чтобы от неё защищаться.

для меня лучше когда на 100% .

Riim,
преждевременная оптимизация это называется.