Авторизация

Собираюсь сделать авторизацию но знаю что реально сделать подмену cookie и session.
Столкнулся с такой проблемой, как лучше сделать авторизацию? Вопрос конечно звучит слишком обобщающе, но суть в том:
1. Cookie
Создать три куки:
1. Логин
2. Пароль
3. Рандомный код
Результат:
При каждой авторизации, создается рандомный код, заносится в бд юзеру, после этого занести в куки, проверка идет всех трех параметров.
1.1 Шифрока данных
Надо ли шифровать параметры? Привязать к домену.
Как и каким способом, не дать подменить данные.
2. Session
Создается сессия, при каждом создании заносить sid в бд и тоже проверять при проверки логина и пароля.

Кто занимался уже такой темой, прошу помощи)

2. Session
заносим туда имя пользователя ( $_SESSION['u']= 'Вася'; )
и готово.

-----
Truly yours, Sasha.

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

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

-----
ответы на 99% вопросов здесь

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

Лучше каким то образом записывать имя пользователя в куку в зашифрованном виде и все.
Тем не менее проверять придётся что это за пользователь, но зато сверять это всё с БД не придётся постоянно.

-----
Truly yours, Sasha.

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

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

-----
ответы на 99% вопросов здесь

какой мусор ? Я же говорю - в зашифрованном виде.
Вряд ли ты в сроку вида
6ehd4xhtu09euths94txbksa,./=aeuhk9a75skxaxoejae920500tehuxkjsaduhnd***aeudynt
Впишешь много мусора чтоб тебя впустили.

А куку устанавливать после авторизации

-----
Truly yours, Sasha.

ты мне объясни каким образоб скрипт бует знать что полученные данные с куков являются именно зашифрованным логином СУЩЕСТВУЮЩЕГО пользователя, если не делать сверку с БД???

(Отредактировано автором: 31 Октября, 2008 - 17:26:34)

-----
ответы на 99% вопросов здесь

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

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

-----
ответы на 99% вопросов здесь

Кстате посмотрите систему slaed так там вообще в бд не заносится номер сессии.
Я думаю лучше сделать как:
Кука: base64((пароль+рандомный код заносящийся каждому юзеру)+idсесии .т.к она уникальна))
Проверка понятна. Хрен кто ломанет.
Вид пароля: md5(base64(пароль+randкод))

Я бы с такой хренью не стал заморачиваться

предлагаю что б вы написали сюда алгоритм аутинификации:
1 - при вводе логина...
2 - при просто хождению по сайту

-----
ответы на 99% вопросов здесь

Парится и воравать номер сессии я бы не стал, может быстро стать не актульным. Думаю разработчики PHP по этому поводу придумали еще свои интриги, я просто еще в это не лез. А вот, когда работаем с Cookies то, прийдется работать с БД, чтоб защитится. В куках не нужно передавать только пароль и логин, нужно передавать независимые данные, т.к. будет единственны шанс у злоумышленника пройти между сразу после последнего посещением, т.к. после открытия новой страницы рандом и данные в куки обновятся. Следовательно такая система сработает, только если после передачи cookies злоумышленнику, пользовтель не должен открыть страницу сайта, только в этом случае данные с куков будут актуальны.

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

да но как узнать актуальная ли данная сессия... т.е. принадлежит ли эта сессия аутинифицированному пользователю или нет?

-----
ответы на 99% вопросов здесь

vitaliy_mad
ЧТо Вы так схватились за сессию, отпустите ее. Картинка следующая:
1) ПРи открытии любой страницы авторизованым пользователем - оставляем уникальный код (пусть это будут любые данные, например: base64((рандомный код заносящийся каждому юзеру)+idсесии .т.к она уникальна)) и еще из всего этого вычисляем хэш).
2) Если пользователь входит, но его сессия оборвана и нужно авторизоватся, обращаемся к БД, если конечно у нас есть наif кука.
3) Если это настоящий пользователь, то он авторизуется автоматом, если же нет - это украденый код, то злоумышленник войдет только под одним условием:
---- Если пользователь, после передачи данного кода, НЕ открывал страницы сайта ------
Если он открывал, то пароль в БД не будет найден и выскачит форма аторизации, как и в случае простого отсутствия кука.