Всем привет!
Написал систему регистрации/авторизации и задался вопросом: «А безопасна ли система» после долгих поисков «идеального» скрипта – решил, что «идеального» не существует. А каждый участник www видит авторизацию по-своему.

Вот что получилось у меня, что-то мне подсказывает, что тут что-то не так 



На остальных страницах сайта скрипт такой же, за исключением части с проверкой $_POST.
Как я понимаю – на каждой странице нужно заново переустанавливать cookies, т.к. их время истечет и они станут неактивными? 

Сув.

PS статью в факе читал, туда не посылайте! 

Добавлено @ 00:33 
Забыл еще рассказать свои критерии:
авторизация должна быть прочной. Но не слишком запудренной. Наверное максимально приближенной к Винградовской. (например открытие сайта в 2 окнах должно поддерживаться) То есть совсем уж пользователя не зажимать!

Однако мне не хочется использовать таблицу БД, т.к. ее нужно будет чистить (cron) да и обращаться лишний раз к БД я не намерен.

Это сообщение отредактировал(а) Рыжий - 6.2.2007, 00:34

После еще нескольких минут медитации над кодом, увидел, что $_COOKIE['pass'] не зашифрован, а должен 
Так что в куку помещаем md5($pass)

Но если куку украдут, разве хацкеры с помощью brootforce не подберут пароль, пусть даже он в md5 ? 

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

сессии для того и сделаны что бы хранить в них что не попадя 

и ещё как писал Mal Hack, хранить в сессии уникальный ключ этой сессии 

допустим


и так как сессии нельзя подделать хранить там цифру говорящую к какой группе пренадлежит человек 
0-->чайник=гость
10-->админ=бог



Далее чувствую будет адская критика моего поста   

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

Его там вообще не должно быть.

http://forum.vingrad.ru/topic-20119.html

Если я не ошибаюсь Винград хранит хеш пароля и логин в куках.

Что же тогда хранить в куках? Ведь узнавать пользователя - как ни крути, а нужно!

Сув.

Это сообщение отредактировал(а) Рыжий - 6.2.2007, 11:34

Идеального скрипта не существует, но есть хорошие и достаточно безопасные. Возьми лубой скрипт авторизации из учебника PHP или скрипты авторизации на форумах посмотри. И посмотри основные принципы. Поверь негде не хранят связку логин и пароль в cookie.

Добавлено @ 11:37 

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

Помещать в cookie ip адрес - значит пользователи с динамичным ip не смогут использовать куку.
Помещать в cookie имя браузера - мне это просто не нужно, пусть люди заходят и с IE и с FF, хоть одновременно!


Это сообщение отредактировал(а) Рыжий - 6.2.2007, 18:54

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

Смысл был не в этом, смысл в том что не надо хранить пароль в куках. Лучше хранить ID пользователя и уникальный ключ(но не пароль) пользователя и по этим данным проверять пользователя.

Но ведь любую открытую информацию можно подделать. Например если в куках держать логин+email+icq+еще много чего, а другие юзеры видят эту инфу - подделать куку очень просто.
Что же тогда хранить в куках, чтобы узнавать пользователя?

Храни в куках уникальный индификатор пользователя не id, а случайно сгенерированую строку

А как я потом сгенерирую эту строку? И как я узнаю что под строчкой "sdfjkl;dsjfiofi" у меня юзер igor ? В БД мне ничего хранить не хочется 

Один раз за сессию обратиться к БД с данным запросом я думаю можно и производительность от этого неупадет. Тем более при авторизации вы к БД обращаетесь за получением данных пользователя. Что мешает сделать следующее
$query='select * from '.$CONFIG["db_prefix"].'_user where login = "'.$login.'"
        and u_id="'.$u_id.'" limit 1';
u_id генери в зависимости от логина юзера его mail и т.д чтоб одинаковых небыло

Это сообщение отредактировал(а) N1k0laj_BY - 6.2.2007, 23:12

Решил сделать так:
Будет массив Кук:

$_COKIE['my_info'][0] = ID пользователя
$_COOKIE['my_info'][1] = md5($login.' '.$pass);

Выскажите пожалуйста свое мнение.

Алгоритм будет таким: найти юзера с ID == данному, и сравнить хеши, если все ОК - значит ставим сессию, в которую помещаем ID пользователя.

Сув.

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


Да, так и делай.

Хорошо, помечу вопрос решенным ;)

Если такую куку украдут - считай вход открыт 

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

А параметр $login_time таскай в браузерной строке. Так ты легко сможешь проверить, не вышло ли время сессии и обновлять сможешь (через ж. конечно, но работать будет) Такую куку можно и потерять, злоумышленник сможет воспользоваться ей максимум на время сессии.

A md5($pass) ты будешь обязан сделать, так как в открытом виде его после логина уже нигде не возмёшь (Ты же не собираешься пароль на сервере открытым текстом хранить??)

Но по нормальному - конечно БД. Чистить её не надо, только обновлять сессию. (Ну или убивать запись, если юзер удалён). А запрос в in_memory table будет даже быстрее, чем работа с файлами полюбому. Да и потом, ты же за логином/пассом всё равно в БД бегаешь. А тут надо будет только за ИД сессии.

Добавлено @ 01:38 

Не совсем так. Куку конечно украсть сложно, но всё таки можно. Скрипты, ссылки, флэши. Например на форуме у нас Гирдер регулярно находит такие новые дыры и закрывает их. Если подумать, что было на форуме год назад, то удивишься, как не поворовали наши аккаунты уже давно ))

Я считаю так:

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

Куки нужны только для распознавания юзера, далее все поставлено на сессиях. А вот сессии уже можно хранить в БД (убедили все же   ).  В Бд могут быть те же md5($login.' '.$pass). и время валидности сессии.

Как вам такой алгоритм?

Это ты потом докажи 100 человек, у которых скриптом с твоего сайта куки слизали и приватную переписку всех со всеми опубликовали 


Это хрени: md5($login.' '.$pass) нечего делать у юзера на компе в куках. Это во первых. Во вторых pass в открытом виде не должен существовать вообще нигде, кроме головы пользователя.

Куки нужны для распознавания сессии, а всё остальное хранится уже в ней. Зачем хранить у юзер что либо, кроме идентификатора сессии?

ПС:
ИД сессии идеале обновляется постоянно. При этом несколько вариантов учитываются как валидные, и старые потихоньку отмирают.

Ясное дело! Поэтому я храню это в БД у себя.

То есть в куках хранить SID будет наиболее приемлемым вариантом?

Можно спросить, зачем?
Если юзер поменяет ник, ему надо будет новый пасс задавать?

По-моему мы пришли к тупику. Если куки такие ненадежные - их тогда совсем не использовать? Собственно можно ответить "Да" но замены cookie еще нет, Поэтому, если хотим помнить о посетителях  - используем cookie, в таком виде, как я указывал ранее.

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

Почему куки ненадёжные? Храни СИД в них, время жизни которого на сервере контролируется. Ну и логин, чтобы перебором никто не попытался пройти.
Больше ничего не надо. (Так и тут на форуме сделано).

sergejzr, Тогда время жизни сессии нужно большим устанавливать, если я тебя правильно понял.

Если мы хотим Помнить  о юзере как минимум неделю. А в куке хранится SID. По этому SID мы обращаемся в БД и смотрим не просрочена ли сессия, если просрочена - удаляем сессию, и просим зарегиться пользователя?

Да. 

С несколькоми сессиями - это не обязательно делать тут овчинка выделки нестоит. Но неплохо было бы "освежать" их. В идеале - при каждом вызове страницы давать новый СИД. Тогда даже если ктото украдёт его, то юзер "вылетит" со страницы, и большой шанс, что он это заметит и тут же залогинится. Тогда старый СИД у нападавшего станет бесполезным, он же не может новый получить.

Но тут надо конечно с нагрузкой на БД сравнивать. Это же обновление записи при каждом входе. Можно например по времени генерить, каждые 5 минут.

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

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

В общем, думаю использовать такой вариант:

Будет БД:
session_id – SID сессии;
session_expire – microtime последнего действия (точность до сотых);
session_start    -  время логина (microtime до сотых секунды).
user_id – ID юзера;
login – хеш логина;

Куки:
SID 
Время логина
Хеш логина юзера

Соответственно ищем запись в Бд по SID, а потом проверяем: равны ли логин и время логина.
Время действия можно задавать в конфигах, думаю мне подойдет 5 дней.


Интересно что будет с БД. Если 10 000 человек будет бродить по сайту, и у каждого будет меняться microtime последнего действия? 

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


А Вы, батенька, оптимист однако 

Эврика! Тогда берем microtime из бд и проверяем, если он больше 5 минут - обновляем (к примеру...)



Еще какой!  

Еще один вопрос по теме:
Если мы начинаем сессию (чтобы узнать SID) - создается файл. Через определенное время их будет слишком много. Что делать?

Файл будет если ты через ПХП создаёшь. У тебя же БД, зачем тебе теперь он?

Для того, чтобы изменить место хранения нужно править параметр session.save_handler. А если у меня нет доступа к php.ini ? Это можно задать в .htaccess ?

Не трогай этот механизм совсем. он тебе не нужен.

sergejzr,  а что можно трогать?

Ты же имеешь СИД и базу, зачем тебе ПХПшная сессия?

sergejzr, Я SID подразумевал под Session ID. А ты похоже хеш, генерируемый мной?

СИД=SID=SessionId и он один в программе. Зачем тебе несколько их?

sergejzr, Но для того, чтобы записать SID нужно сделать session_start() !! (после чего появится файл с сессией на сервере) Или мы не поняли друг друга?

Рыжий,
Механизм сессий замечательно перекрывается при помощи session_set_save_handler(). 

SamDark, Насколько я знаю эту функцию можно использовать только при параметре: session.save_handler = user в PHP.ini.

Сам посмотри: SID создаёшь ты сам, записываешь в БД сам, хранишь-сам, управляешь ими тоже сам. Скажи, зачем тебе вообще session_start()?

sergejzr, Все, вопрос решен.   

sergejzr


Простите что поднимаю старую тему, но можно ли хотябы узнать примерный код, как без
session_start() SID сделать?

или Хотябы ссылку выложите с таким примером, буду очень благодарен