Авторизация на сессиях

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

Есть БД юзверей. В ней id, логин и пароль в md5 и или иже с ним (соль там и все такое).

Стартуем сессию, проверяем, задан ли $_SESSION['id']. Если нет, то отправляем на страницу авторизации.
Если задан, то лезем в БД и проверяем, есть ли юзверь с таким id. Если есть, пускаем на страницу, если нет - отправляем опять же на страничку авторизации.

Такого подхода достаточно? Или необходимо более надежно защититься?

К примеру, кроме $_SESSION['id'] задавать еще какой-нить уникальный для данной сессии $_SESSION['session_hash'], который генерится при авторизации и записывается в БД, а затем проверяется вместе с id?
Я вот этот момент не очень понимаю... ну если он нужен, конечно. По мне, так это только для кук надо делать...

Можете в двух словах описать безопасный принцип авторизации на сессиях?

А то примеров в инете куча, но никто не описывает идеологии: тупо "сделайте так", "сделайте так" и "как видите все просто".

0

Сообщение от Laroux Стартуем сессию, проверяем, задан ли $_SESSION['id']. Если нет, то отправляем на страницу авторизации. Если задан, то лезем в БД и проверяем, есть ли юзверь с таким id. Если есть, пускаем на страницу, если нет - отправляем опять же на страничку авторизации.

правильно.

Сообщение от Laroux К примеру, кроме $_SESSION['id'] задавать еще какой-нить уникальный для данной сессии $_SESSION['session_hash'], который генерится при авторизации и записывается в БД, а затем проверяется вместе с id?

Он и так создаётся, ваш session_id (уникальный)
Вот напиши в файле
получишь что то типо v2hbsobp11p9jsua528prtgfv5
Выйди из браузера, снова войди, он изменится.

1

Сообщение от Laroux К примеру, кроме $_SESSION['id'] задавать еще какой-нить уникальный для данной сессии $_SESSION['session_hash']

Он уже есть, это id сессии

1

Хорошо, сто он есть, этот идентификатор сессии.. я должен с ним что-то делать?
Например, запоминать в БД, чтобы моего юзера не ломанули?

Или вот банально $_SESSION['id'] будет достаточно?

0

Laroux, чтоб «не ломанули», не используйте сессии без кук

0

miketomlin, не люблю я клиентские штуки.. почему чисты PHP великолепен? Да потому, что он все далает на серваке и отдает только html.
Как только дело касается чего-то на компе пользователя и что нужно как-то юзать....

0

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

0

Laroux, не любишь клиентские штуки, делай двухфакторную аудентификацию, думаю объяснять не стоит что придется использовать

0

Jodah, ну и все-таки сесии и куки немного разные вещи, согласитесь.

Не, куки не буду юзать принципиально.

А если сделать так, к примеру: запомнить в сессию id пользователя, а также getallheaders() в sha256 с какой-нить солью и в каждое обращение кроме id проверять еще и эти заголовки? Спасет?

0

Сообщение от Laroux почему чисты PHP великолепен? Да потому, что он все далает на серваке и отдает только html. Как только дело касается чего-то на компе пользователя и что нужно как-то юзать....

И это тебе не дает 100% уверенности что тебя не ломанут

Добавлено через 1 минуту

Сообщение от Laroux Не, куки не буду юзать принципиально.

А это ты зря, я тоже так думал, но куки решают ситуацию, отбрось эти принципы жизнь проще станет

0

Сообщение от Laroux ну и все-таки сесии и куки немного разные вещи, согласитесь.

Конечно разные. Но повторюсь, сессии используют куки (session_start отправляет куку с именем PHPSESSID и использует её для идентификации).

Сообщение от Laroux Не, куки не буду юзать принципиально.

Зря.

0

балин.. чо ж так все сложно-то?

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

Заранее благодарен

0

Все элементарно. Просто нужно отделять слой PHP-абстракций от реального положения дел/протокола.

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

Скинул в личку ссылку на статью, где описывается сама суть.

1

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

0

Я хочу сказать, что сессии – это лишь прослойка для удобства тех, кому лень пару лишних строк самому написать. Плюс по дефолту сессии хранятся в файлах – некоторые считают, что так быстрее. Лично мне сессии только мешают. Чем настраивать их под себя, проще вовсе без них обойтись. sid – это по сути ключ авторизации предопределенного формата, зависящего не от меня. Опять-таки, чем что-то настраивать, мне проще использовать свой аналог, не задумываясь о том, как подогнать сессии под себя.

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

1

Сообщение от miketomlin Лично мне сессии только мешают.

+1, никогда не ощущал от них профита. Хотя нет, пару раз был профит, когда помогал делать курсовые. Когда гораздо проще обращаться к $_SESSION, чем описывать человеку, как работают куки (в частности setcookie).

1

Laroux, сессии совсем без кук (это когда вы пихаете sid в адреса страниц), как я вам выше намекнул и написал Jodah, в целях безопасности лучше совсем не использовать. Сам механизм, конечно, может быть полезен в каких-то частных случаях. Например, можете запихнуть ключ авторизации в ссылку активации акка пользователя, только сразу после однократного перехода по ней делайте ссылку недействительной – смените ключ авторизации. В редких случаях возможность входа по одноразовой ссылке может быть полезна, только не нужно всю авторизацию подобным образом строить.

0

miketomlin, да я же не против.
Давайте еще раз, ребят. Потому что много тут уже переписки, а воз (мой, правда ) и ныне там.

Исходные данные: 1) предполагаем, что к моей БД с данными пользователей никто не доберется; 2) сессии у меня хранятся на сервере в месте недоступном извне. Из соседнего аккаунта хостинга тоже каталог с фалами сессий недоступен.

Что мы делаем:
Есть база, в которой хранятся данные пользователя (4 поля): UserID, Login, Password в каком-нить ужасно зашифрованном формате с солями, SessionID.

Для проверки "авторизован ли пользователь?" Я использую следующий механизм: стартую сессию, проверяю, существует ли $_SESSION['UserID'].
Если нет - редирект на страницу авторизации, а на ней я (при правильном вводе имени и пароля) записываю session_id() этому пользователю в базу в поле SessionID.
Если $_SESSION['UserID'] определен, то идем в БД, делаем запрос по `UserID`= $_SESSION['UserID'] и `SessionID` = session_id(). Запрос вернул строку? - велкам! Если же нет - отправляем на страницу авторизации.

Можете мне указать на потенциальные уязвимости такого подхода?

0

Сообщение от Laroux Можете мне указать на потенциальные уязвимости такого подхода?

Компроментация id сессии (то же может быть и с кукуми)

Сообщение от Laroux Если $_SESSION['UserID'] определен, то идем в БД, делаем запрос по `UserID`= $_SESSION['UserID'] и `SessionID` = session_id(). Запрос вернул строку? - велкам! Если же нет - отправляем на страницу авторизации.

Человек не сможет с 2 устройств быть залогинен на 1 аккаунт. Может быть как плюсом, так и минусом. Да и смысла особого нет. Ид юзера изменить можно только на сервере.

0

Laroux, а зачем session_id в БД сохранять?

0