Доброго времени суток всем!

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

Прежде всего я думал о том, по какому полю следует идентифицировать пользователя. Т.к. на моем сайте подразумевается регистрация как физ. лиц, так и юр., то я решил сделать не ФИО или ник идентифицирующем полем, а адрес электронной почты. Если кто-то считает, что я ошибся, просьба обосновать/предложить свое решение.

Далее, встал более глобальный вопрос: как и куда запоминать, что пользователь "успешно авторизировался"? Сперва в голову пришла стандартная идея хранения в куках логина (в нашем случае e-mail`а и зашифрованного пароля). Так же в БД можно хранить "соль" и т.д. и т.п. Но затем мне в голову пришла идея, а то если воспользоваться более продвинутым (?) алгоритмом хранения авторизации - сессии. Что если назначать пользователю, который успешно ввел свои данные, уникальную сессию и хранить в куках именно ее? Тогда можно не меняя пароля, сбросить данную сессию. А можно даже устанавливать ей свое время жизни. В общем эта идея показалась мне более продвинутой.

Но все же решил я посоветоваться с вами, гуру php, как считаете - какой вариант хранения оптимальнее?

У меня рабочий e-mail, который я считал самым "надежным" уже сменился, причем безвозвратно. Самым "живучим" моим почтовым адресом стоит считать адрес на mail.ru 

Для Юр лиц часть бывает, что меняются секретари. У каждого может быть собственный адрес. Что делать - перерегистировать?

К тому-же регистрация по адресу email - еще один способ засветить адрес для спам-рассылки. Нужно отдельно с этим бороться...

Данный адрес (а фактически логин) нигде показываться не будет. Он служит только для определения уникальности. Но в принципе, повторюсь, от этой идеи можно отказаться обратно в сторону обычного логина. А что делать с моим главным вопросом?

Если нужна строчка -- сейчас у нас 25 юзеров на сайте, то нужно завести таблицу - "Юзеры online" с датой последней активности и sessid. 
Всю полезную юзеру информацию хранить в сессии. Обычно этого хватает

Это сообщение отредактировал(а) ksnk - 4.5.2009, 12:30

Когда читал, растерялся маленько. А чем стандартный механизм сессий не подходит?

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

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

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

еще модно использовать JSON http://ua.php.net/manual/en/ref.json.php

Это сообщение отредактировал(а) gcc - 4.5.2009, 14:24

Мы не о том совсем.
Если вас смущает слово сессия, я могу назвать это "уникальной строкой, идентифицирующей пользователя". Не суть.
Вопрос такой: что лучше А или Б?
А) хранить в куках логин/пароль и проверять при каждом заходе их.
тогда если украдут куки - могут узнать и пароль.
тогда администратор сайта не может без ведома пользователя обезопасить его (ибо если сменит ему праоль, пользователь об этом узнает)
Б) хранить в куках уникальную строку
тогда, можно менять ее каждые сутки, что снизит шансы на ее кражу (а даже если она была сворована и вор потихому сидел под чужой уник. строкой, то не больше суток).
тогда же при краже вор НЕ УЗНАЕТ сам пароль пользователя

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

второй лучше, где используется первый?

хотя там можно закриптограифровать пароль, хорошо "посолить"
http://ru.wikipedia.org/wiki/Радужная_таблица
http://www.usenix.org/events/usenix99/prov...tml/node10.html


Это сообщение отредактировал(а) gcc - 4.5.2009, 17:54

Как это где? На данном форуме, например. То есть разработчики IPB из года в год выбирают худший вариант?

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

Должен запоминать. Но какая разница сайту что будет хранится в куках - логин или сессия. НЕ СТАНДАРТНАЯ СЕССИЯ, а сессия (или уникальный номер авторизации, если кому угодно) хранится в куках. Я не знаю как еще объяснить, если уже третий раз Вы пишете про стандартную session_start() - я говорю НЕ ПРО НЕЕ.
За примером далеко ходить не нужно - Zend Framework предлагает авторизацию, основанную именно на таком механизме.

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

 А классический вариант?
Хранить логин и хэш.

Б - мне кажется лучше потому что:
- идентифицировать кто это по хэшу можем только мы
- меньше ненужной информации в куках
- если всё же хэш украли, то войдя заново в профиль хэш меняется 

nerezus, аргументация?


Elfet, спасибо. Тоже придерживаюсь этого варианта.

Aliance, аргументация "классический вариант" не подходит?
Способ простой - и пароль не хранится, и перелогиниваться при конце сессии не надо.
А если по IP хочешь проверку на случай XSS, то last_ip храни в таблице пользователя.

nerezus, а при конце жизни кук надо? Мне кажется ты написал не подумав.
Время жизни у кук же есть, и она ничем не отличается от сессии. Потому что это те же куки. Так что тут однотипная модель.

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

 Подумав.

 От PHP-сессий - очень даже отличается.

Aliance можно немного внесу свою лепту?

Я считаю вариант С, будет получше чем оба.   

Обьясню... т.е. при первом заходе юзера на сайт, и ввода им пароля и логина, мы создаем ХЭШь(на основе чего, тебе видней), и заносим его в БД. Далее при каждом действии юзера, этот хэшь мы прверяем, и если не то, то "пока".

Пчему это лучше чем хранить в кукисах и пр.?
Просто этот хэшь в БД, точно украсть не сможет никто... в отличии от сессий и кук.

bazzjr, а как идентифицировать пользователей? 

идентифицировать при заходе на сайт? или в последующей работе с сайтом?

bazzjr, в последующей работе с сайтом?

разве не понятно? или ты имел ввиду как это будет выглядеть в коде ПХП?   

этот "ХЭШь" мы как-то должны хранить у юзера, либо в куках, в сессии (куках, в ссылках). Ты же говоришь: 

Ты предлагаешь ещё как-то хранить его у юзера? как?

у юзера естественно хранить это в сесиях.

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

bazzjr, это и есть вариант В 

да, только там говорится про куки, нет розговора про сессии, и ни слова при этом про БД...

это не суть.

Можно сделать так.

В таблице хранить  идентификатор сессий, который записывается при каждом логине. И айпи последнего входа.

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

Далее , если при каждом действии пользователя на сайте, сверяется идентификатор сессии и айпи (не изменились ли они), если все норма то пользователь продолжит работу. Если нет то удалить идентификатор пользователя и предложить заново авторизоваться.

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


Элфет прав, это и есть он 

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

А вот еще вариант, который будет довольно безопасным.

Пользователь авторизируется. В БД создается запись, где будет находится наша `sessid`,`user`,`ip`,`dt`...
Строка`sessid` будет генерироваться случайным образом, например md5(логин + пароль + id).
А сейчас очень важный вариант, спасающий от дос атак: очень важно прослеживать активность пользователя. Если заходов с одного IP, например, за 30 сек больше 50, то завершить работу скрипта, с соответствующим сообщение о безопасности. Или вот еще поинтереснее вариант: выделяем количество записей из БД которые были активны на протяжении 10-20 сек. Если кол-во записей преувеличивает, например 20-30, то что-то не так и выдаем сообщение, мол сервер перегружен.
Примерно по такому принципу мой друг боролся с дос атаками на moto.com.ua. Вот я с Вами и поделился.
Спасибо за внимание. Удачки Вам!  

LittleFuntik, как правило на запуск скрипта ресурсов тратится больше, чем на его работу. А еще если в скрипте и проверять IP...

вобщем лишь нагрузку увеличит.

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

Мне кажется, что использование БД для борьбы с DOS-типом атак можно назвать только анекдотическим. Да и не бывает сейчас простого DOS, только распределенный. 

По первоначальному вопросу. Хоть он и старый, но какое-то обсуждение неконкретное, по кругу об одном и том же.
Разница между вариантами А и Бэ представляется мне не настолько принципиальной, чтобы об нее копья ломать. Идеи про расшифровку или кражу хэшей кажутся мне сильно гипотетическими. Разница только в количестве кук.

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

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

А если запустили робота, который только и знает, что ежесекундно создает сессии... То что делать? висим, Сервер...

Это сообщение отредактировал(а) LittleFuntik - 7.7.2009, 16:31

Мне кажется, обсуждение ДОС атак здесь будет оффтопиком. К регистрации пользователей всё это не имеет никакого отношения. 

ох уж эти правила... "оффтоп" понимаешь-ли))) сори, Ипатьев