| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > PHP: Для профи > Теория регистрации пользователей |
| Автор: Aliance 4.5.2009, 11:26 |
| Доброго времени суток всем! Я задался таким вопросом: как написать наиболее удачную регистрацию/авторизацию пользователей на моем сайте. Прежде всего я думал о том, по какому полю следует идентифицировать пользователя. Т.к. на моем сайте подразумевается регистрация как физ. лиц, так и юр., то я решил сделать не ФИО или ник идентифицирующем полем, а адрес электронной почты. Если кто-то считает, что я ошибся, просьба обосновать/предложить свое решение. Далее, встал более глобальный вопрос: как и куда запоминать, что пользователь "успешно авторизировался"? Сперва в голову пришла стандартная идея хранения в куках логина (в нашем случае e-mail`а и зашифрованного пароля). Так же в БД можно хранить "соль" и т.д. и т.п. Но затем мне в голову пришла идея, а то если воспользоваться более продвинутым (?) алгоритмом хранения авторизации - сессии. Что если назначать пользователю, который успешно ввел свои данные, уникальную сессию и хранить в куках именно ее? Тогда можно не меняя пароля, сбросить данную сессию. А можно даже устанавливать ей свое время жизни. В общем эта идея показалась мне более продвинутой. Но все же решил я посоветоваться с вами, гуру php, как считаете - какой вариант хранения оптимальнее? |
| Автор: ksnk 4.5.2009, 11:52 | ||
У меня рабочий e-mail, который я считал самым "надежным" уже сменился, причем безвозвратно. Самым "живучим" моим почтовым адресом стоит считать адрес на mail.ru  Для Юр лиц часть бывает, что меняются секретари. У каждого может быть собственный адрес. Что делать - перерегистировать? К тому-же регистрация по адресу email - еще один способ засветить адрес для спам-рассылки. Нужно отдельно с этим бороться... |
| Автор: Aliance 4.5.2009, 12:03 |
| Данный адрес (а фактически логин) нигде показываться не будет. Он служит только для определения уникальности. Но в принципе, повторюсь, от этой идеи можно отказаться обратно в сторону обычного логина. А что делать с моим главным вопросом? |
| Автор: ksnk 4.5.2009, 12:23 |
| Если нужна строчка -- сейчас у нас 25 юзеров на сайте, то нужно завести таблицу - "Юзеры online" с датой последней активности и sessid. Всю полезную юзеру информацию хранить в сессии. Обычно этого хватает |
| Автор: enof 4.5.2009, 12:37 | ||
Когда читал, растерялся маленько. А чем стандартный механизм сессий не подходит? |
| Автор: gcc 4.5.2009, 13:07 |
| сессию можно привязывать к ip, оно по-моиму по-умолчанию редко где привязыается? и при входе чтобы можно было задать время жизни сессии... если кто-то украдет сессию, то у себя на компе может под логином зайти, тот тут можно привзять айпи по которому она была привязана (но айпи тоже можно вынести любой наружу, так что хз) на движках болиших, еще сделано чтобы форум переспрашивал пароль админа, тогжа когда админ заходит в админку, через какое-то время, если админ не был активный... еще модно использовать JSON http://ua.php.net/manual/en/ref.json.php |
| Автор: Aliance 4.5.2009, 16:25 |
| Мы не о том совсем. Если вас смущает слово сессия, я могу назвать это "уникальной строкой, идентифицирующей пользователя". Не суть. Вопрос такой: что лучше А или Б? А) хранить в куках логин/пароль и проверять при каждом заходе их. тогда если украдут куки - могут узнать и пароль. тогда администратор сайта не может без ведома пользователя обезопасить его (ибо если сменит ему праоль, пользователь об этом узнает) Б) хранить в куках уникальную строку тогда, можно менять ее каждые сутки, что снизит шансы на ее кражу (а даже если она была сворована и вор потихому сидел под чужой уник. строкой, то не больше суток). тогда же при краже вор НЕ УЗНАЕТ сам пароль пользователя Мне кажется второй вариант лучше, но почему везде используется первый? |
| Автор: gcc 4.5.2009, 17:52 |
| второй лучше, где используется первый? хотя там можно закриптограифровать пароль, хорошо "посолить" http://ru.wikipedia.org/wiki/Радужная_таблица http://www.usenix.org/events/usenix99/provos/provos_html/node10.html |
| Автор: Aliance 5.5.2009, 08:20 |
| Как это где? На данном форуме, например. То есть разработчики IPB из года в год выбирают худший вариант? |
| Автор: realPROme 5.5.2009, 10:31 |
| Aliance, сайт должен запоминать пользователя? т.е. автоматическая авторизация при последующем заходе нужна? если да - то первый вариант, если нет - стандартный механизм сессий в пхп |
| Автор: Aliance 5.5.2009, 10:54 |
| Должен запоминать. Но какая разница сайту что будет хранится в куках - логин или сессия. НЕ СТАНДАРТНАЯ СЕССИЯ, а сессия (или уникальный номер авторизации, если кому угодно) хранится в куках. Я не знаю как еще объяснить, если уже третий раз Вы пишете про стандартную session_start() - я говорю НЕ ПРО НЕЕ. За примером далеко ходить не нужно - Zend Framework предлагает авторизацию, основанную именно на таком механизме. |
| Автор: Elfet 29.5.2009, 22:07 | ||
Я всегда делаю так, мне так больше нравится в выглядит безопаснее. Украсть её можно, но вот только уже не хэш пароля.  |
| Автор: nerezus 30.5.2009, 13:47 | ||
Хранить логин и хэш. |
| Автор: Elfet 30.5.2009, 17:39 |
| Б - мне кажется лучше потому что: - идентифицировать кто это по хэшу можем только мы - меньше ненужной информации в куках - если всё же хэш украли, то войдя заново в профиль хэш меняется |
| Автор: Aliance 31.5.2009, 10:14 |
| nerezus, аргументация? Elfet, спасибо. Тоже придерживаюсь этого варианта. |
| Автор: nerezus 31.5.2009, 12:01 |
| Aliance, аргументация "классический вариант" не подходит? Способ простой - и пароль не хранится, и перелогиниваться при конце сессии не надо. А если по IP хочешь проверку на случай XSS, то last_ip храни в таблице пользователя. |
| Автор: Aliance 3.6.2009, 21:49 | ||
nerezus, а при конце жизни кук надо? Мне кажется ты написал не подумав. Время жизни у кук же есть, и она ничем не отличается от сессии. Потому что это те же куки. Так что тут однотипная модель. Только в классическом варианте есть хеш, который можно расшифровать (лично так делал много раз) (конечно соль и т.д. поможет, но не гарантированно), а там ты пароля не узнаешь. Конечно можешь украсть куки (как и в том варианте), то тогда смена сессии будет для пользователя незаметна, в отличии от принудительной смены пароля. |
| Автор: nerezus 7.6.2009, 16:28 | ||||
|
| Автор: bazzjr 8.6.2009, 20:02 |
| Aliance можно немного внесу свою лепту? Я считаю вариант С, будет получше чем оба.  Обьясню... т.е. при первом заходе юзера на сайт, и ввода им пароля и логина, мы создаем ХЭШь(на основе чего, тебе видней), и заносим его в БД. Далее при каждом действии юзера, этот хэшь мы прверяем, и если не то, то "пока". Пчему это лучше чем хранить в кукисах и пр.? Просто этот хэшь в БД, точно украсть не сможет никто... в отличии от сессий и кук. |
| Автор: Elfet 8.6.2009, 21:51 |
| bazzjr, а как идентифицировать пользователей? |
| Автор: bazzjr 9.6.2009, 06:28 | ||
идентифицировать при заходе на сайт? или в последующей работе с сайтом? |
| Автор: Elfet 9.6.2009, 09:34 |
| bazzjr, в последующей работе с сайтом? |
| Автор: bazzjr 9.6.2009, 11:50 | ||
разве не понятно? или ты имел ввиду как это будет выглядеть в коде ПХП? |
| Автор: Elfet 9.6.2009, 13:55 | ||
этот "ХЭШь" мы как-то должны хранить у юзера, либо в куках, в сессии (куках, в ссылках). Ты же говоришь:
Ты предлагаешь ещё как-то хранить его у юзера? как? |
| Автор: bazzjr 9.6.2009, 15:50 |
| у юзера естественно хранить это в сесиях. но даже если сессия будет сперта(ее трудоемко спереть в отличии от кусисов), то это ничего не даст. Так же можно для доп.защиты(для параноиков) приписывать префикс во время проверки, это дает высокую степень защиты, так как для взлома хакеру нужно выявить этот префикс, что практически невозможно. |
| Автор: Elfet 9.6.2009, 16:16 |
| bazzjr, это и есть вариант В |
| Автор: bazzjr 9.6.2009, 16:24 |
| да, только там говорится про куки, нет розговора про сессии, и ни слова при этом про БД... |
| Автор: Elfet 9.6.2009, 17:21 |
| это не суть. |
| Автор: xarakiry 21.6.2009, 21:30 |
| Можно сделать так. В таблице хранить идентификатор сессий, который записывается при каждом логине. И айпи последнего входа. При авторизации проверять ясное дело логин и пароль, и если успешно выдавать уникальный номер пользователя в зашифрованном виде. Далее , если при каждом действии пользователя на сайте, сверяется идентификатор сессии и айпи (не изменились ли они), если все норма то пользователь продолжит работу. Если нет то удалить идентификатор пользователя и предложить заново авторизоваться. |
| Автор: Aliance 23.6.2009, 17:11 | ||
xarakiry, у некоторых пользователей IP может менять в течении сессии.
Элфет прав, это и есть он |
| Автор: ksnk 23.6.2009, 17:55 | ||
Это не запрещает использовать IP для проверки авторизации. Просто для таких юзеров будет актуальна галочка "запомнить в куках мой логин-пароль". Пару раз введут пароли, потом сами найдут галочку... ну или с сайта сбегут... |
| Автор: LittleFuntik 7.7.2009, 11:49 |
| А вот еще вариант, который будет довольно безопасным. Пользователь авторизируется. В БД создается запись, где будет находится наша `sessid`,`user`,`ip`,`dt`... Строка`sessid` будет генерироваться случайным образом, например md5(логин + пароль + id). А сейчас очень важный вариант, спасающий от дос атак: очень важно прослеживать активность пользователя. Если заходов с одного IP, например, за 30 сек больше 50, то завершить работу скрипта, с соответствующим сообщение о безопасности. Или вот еще поинтереснее вариант: выделяем количество записей из БД которые были активны на протяжении 10-20 сек. Если кол-во записей преувеличивает, например 20-30, то что-то не так и выдаем сообщение, мол сервер перегружен. Примерно по такому принципу мой друг боролся с дос атаками на moto.com.ua. Вот я с Вами и поделился. Спасибо за внимание. Удачки Вам!  |
| Автор: nerezus 7.7.2009, 11:57 |
| LittleFuntik, как правило на запуск скрипта ресурсов тратится больше, чем на его работу. А еще если в скрипте и проверять IP... вобщем лишь нагрузку увеличит. Такое может прокатить лишь с массивными скриптами. Про дефекты кодерской мысли типа битрегза я не буду говорить, тут точно поможет. |
| Автор: Ипатьев 7.7.2009, 14:28 |
| Мне кажется, что использование БД для борьбы с DOS-типом атак можно назвать только анекдотическим. Да и не бывает сейчас простого DOS, только распределенный. По первоначальному вопросу. Хоть он и старый, но какое-то обсуждение неконкретное, по кругу об одном и том же. Разница между вариантами А и Бэ представляется мне не настолько принципиальной, чтобы об нее копья ломать. Идеи про расшифровку или кражу хэшей кажутся мне сильно гипотетическими. Разница только в количестве кук. А вот по сессиям, мне кажется, что автор смешивает два понятия: сеанса и "запоминания" пользователя для последующей автоматической авторизации. Пытаясь сделать только последний. Такой вариант имеет право на жизнь, но представляется мне гораздо менее гибким, чем классический. В нем, в частности, нельзя сделать проверку IP без неудобств для пользователя. Плюс мы теряем возможность работать при отключенных куках (да, это менее безопасно, но контроль IP дает вполне достаточную защиту). Мне представляется куда более удобным применение обоих методов. Для запоминания сеансовой информации используется "классическая" сессия до закрытия браузера, а для запоминания юзера - кука с хэшем. |
| Автор: LittleFuntik 7.7.2009, 16:31 |
| А если запустили робота, который только и знает, что ежесекундно создает сессии... То что делать? висим, Сервер... |
| Автор: Ипатьев 7.7.2009, 16:57 |
| Мне кажется, обсуждение ДОС атак здесь будет оффтопиком. К регистрации пользователей всё это не имеет никакого отношения. |
| Автор: LittleFuntik 10.7.2009, 19:14 |
| ох уж эти правила... "оффтоп" понимаешь-ли))) сори, Ипатьев |
