Форум PHP

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

сессия хранится на сервере. БД тоже хранится на сервере.
Какой смысл сравнивать строку из сессии со строкой в БД?

ps. А еще некоторые особо одаренные товарищи любят в сессию засовывать пароль.

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

Ваши сверхсекретные строки, о которых клиент и не догадывается, бесполезны. От него как требовался идентификатор сессии аутентифицированного пользователя, так и требуется.

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

>А еще некоторые особо одаренные товарищи любят в сессию засовывать пароль.

похоже это товарищи из софттайма )
выбираем любое понравившееся сообщение на форуме, жмем Ответить, видим поля "Ваше имя" и "Пароль".. смотрим исходный код - вуаля ) наш пароль в чистом виде

>выбираем любое понравившееся сообщение на форуме, жмем Ответить, видим поля "Ваше имя" и "Пароль".. смотрим исходный код - вуаля ) наш пароль в чистом виде

Возможно Способ украсть этот пароль...

Пароль в куке лежит (name=wrdp)

>Пароль в куке лежит (name=wrdp)
Ну он примерно это и имел ввиду...

Это еще сильно зависит от того, где имено идёт аутентификация... Если игра или чат, то да, ваша система может подойти, а если форум или портал, то пользователю придётся заходить на него каждый раз при выкрывании браузера? Пользователи могут и руки за такое оторвать (проверено опытом :) ). Если нужна длительная аутентификация используйте КУКИ, НО ПРОВЕРЯЙТЕ ИХ ПРИ КАЖДОЙ ЗАГРУЗКИ СТРАНИЦЫ (у меня к пимеру есть отельный файл который отвечает за всю эту фигню. Начиная от выбраного языка и скина и заканчивая проверкой куков или, когда делал игру, в бою находится игрок или нет и т.д. и т.п.)

Хотелось бы спросить у проф-х форумчан - А что вы предпочитаете использовать Cookie или сесии? Хотя, конечно тут все зависит от задачи, ну к примеру при реализации CMS?
Мне например удобно хранить данные для авторизации в cookie, а при авторизации или вообще для совершения какого-либо действия пользователя извлекать из cookie данные, сверять существует ли такой пользователь в БД и является ли он тем за кого себя выдает, если все удачно - ок. Мне данный вариант предпочтительнее, чем создавать сессию, хранить его идентификатор в куках.

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

yu

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

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

И дальше, на основании этого идентификатора и сохранённого соответствия легко получить любые данные о пользователе.

В теории всё круто. Но встаёт вопрос быстродействия и паразитной нагрузки.

Если например соответствие хранится в БД. То каждый раз при обновлении страницы идёт запрос. Что, при приличном количестве хитов, несомненный минус.

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

Вот тут как раз можно хитрить, чтобы максимально зашифровать данные в сессии.

а как вообще должен выглядеть наиболее устойчивый к взлому вид аутентификации?

ИМХО. Генерация одноразового пароля, пожалуй. Действующего в пределах текущей сессии.

> но повысится вероятность взлома

Каким образом?

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

Если этот кто-то доберется до файла сессии, что ему помешает добраться до базы данных?

Да ни что не помешает. Скорее всего такой чувак за сессией и не полезет :) Сразу инъекции начнёт пробовать. Я не говорю, что наличие избыточной информации в сессии гарантирует взлом сайта. Просто не исключаю такой возможности.

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

"Пряники" могут достаться вообще без всяких усилий. Не обязательно, что каждый пользователь за компьютером работает под парольным доступом в нем. И не обязательно такая работа есть "обязательство" служащих на предприятиях, и не обязательно только один служащий может работать за таким компьютером. Но то, что масса таких служащих во время работы "гуляет" в интернете, регистрируется, делает покупки и прочее, это точно. Особенно такая беспечность у женщин, так что записав свои "пряники" такому пользователю, ими же может полакомиться и другой :)

>"Пряники" могут достаться вообще без всяких усилий. Не обязательно, что каждый пользователь за компьютером работает под парольным доступом в нем. И не обязательно такая работа есть "обязательство" служащих на предприятиях, и не обязательно только один служащий может работать за таким компьютером. Но то, что масса таких служащих во время работы "гуляет" в интернете, регистрируется, делает покупки и прочее, это точно. Особенно такая беспечность у женщин, так что записав свои "пряники" такому пользователю, ими же может полакомиться и другой :)

Вот, как мне кажется, очень верно вы заметили!
Есть ещё "сжиматели траффика" которые открывают мою станицу в одном из своих фреймов, страницы платёжных систем, открываемые в дочернем окне...

Опираться на секретность куки не кажется разумным.

Пользоваться сессией, вообще, на мой взгляд, стоит в исключительных ситуациях, где именно она подходит. У меня была проблема с настройкой файервола - я отключался от Интернета после загрузки каждой страницы... Каждый раз пароль вводить?

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

как раз закрытие окна можно перехватить яваскриптом,так что этот вариант тоже можно предусмотреть.

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

а где на ваш взгляд она подходит?

Сессия подходит, например, для ввода капчи в скрипте регистрации.
Уже с некоторой натяжкой, но всё же она может пригодиться для ввода короткого поста на форуме.

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

Вы можете объяснить мне что Вы хотите запрашивать и что получать в ответ?

а реально ли вообще читать куки или даже изменять их значения?

> а реально ли вообще читать куки или даже изменять их значения?

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

Я про вот это:
http://www.softtime.ru/forum/read.php?id_forum=1&id_theme=42730
Мне по наивности кажется, что не лишено смысла. Если логин и хэш пароля хранить в отдельной таблице, запрос не должен быть очень ресурсоемким. Записать в сессию логин и сравнивать его с "хозяином" хэша авторизации. Если не его кука, ломать сессию и культурно хидером на главную страницу...Глупости наверное, просветите.

> Я про вот это:
> http://www.softtime.ru/forum/read.php?id_forum=1&id_theme=42730
> Записать в сессию логин и сравнивать его с "хозяином" хэша авторизации

А где Вы там сессию увидели?

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

хм у меня просто записывается при авторизе 1 куки с именем юзера,а потом из бд вытягивается по куки его статус и соответственно привилегии на страницы.. я так понял это гнило?

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

не ну я просто написал функцию и в хидере вставляю типа loc_no_guests если не авториз кидает на индекс или loc_only_admin и т.д.

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

та имхо всё можно спереть) главное проф и руки)

sl1p, зачем Вы тогда стараетесь что-то скрыть, если всё равно это можно раскрыть?

зачем люди пытаются хорошо жить если всё равно умрут?)

Не надо делать такие сравнения.

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

Вы относитесь к тем людям, которые уверены, что взломать можно всё, главное иметь "руки", "ноги" или что ещё там советуют иметь? Если да, то Вам не месте в Web-разработке и программировании, IMHO.

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

>>... обычный то юзер не будет ломать. На таких я и расчитываю.
Живете одним днём?

да нет просто портал не так уж важен) или даже скажем важен, но в особом кругу людей)

>> да нет просто портал не так уж важен) или даже скажем важен, но в особом кругу людей)
Никак не пойму я Вас. Нельзя ли немного прояснить?..

По определению любой замок, это устройство, которое ДОЛЖНО открываться. Другое дело чем. Можно ключом, можно отмычкой. Суть защиты имхо в том, чтобы сделать взлом нерентабельным. Как и с настоящими взломщиками. Ни один в здравом рассудке домушник не будет возится с замком всю ночь: найдет попроще. А взломщик с высокой квалификацией не полезет в замызганную хрущевку.
Если сайт домашний, то и нечего переживать, а если это корпоративные данные или хотя бы админка, то сложность защиты должна быть сопоставима с важностью данных. Тогда пропадает смысл напрягаться.

так,мне кажется разговор поехал в сторону от темы.
давайте думать логичести:
что мы можем использовать?-куки и сессии.
что где хранится?-куки на машине юзверя,сессии на сервере.
что проще украсть?-куки.
как выдается сессия?-каждое новое окно имеет уникальный sess_id.
возможно ли подделать sess_id?-практически нет(если не прав-поправьте).
что можем делать при входе?-в БД к юзеру вписывать sess_id которую только-что получили,и при переходе со страницы на страницу в начале страницы должно стоять session_name("***");session_start(); и сверяться текущее sess_id с тем что записано в бд.
вот на вскидку так имхо.

Можно наверное так, только вот сложность в чем. На странице несколько запросов в другую(е) таблицу(ы). Как определить принадлежность юзверя к своим записям? Страница с формой, данные нужно менять в других таблицах, в зависимости от обстоятельств. Перезаписывать sess_id при каждом заходе во всех записях как то нелогично...

если честно сессию нешарю, но она же вроде как "одноразовая", как же тогда её юзнуть для длительного использования?

Горячая тема:) не могу не поделиться фишкой, которую применяю.
Как известно, опасность применения сессий в том, что злоумышленник может похитить SESSID (брутфорс, реферрер, троян и т.д.). Большинство таких взломов - это не следствие "кривизны" кода, а халатность или "чайничество" пользователя. Но можно сделать так, что кража SESSID не будет иметь смысла: просто при каждом запросе считывать данные из текущей сессии, уничтожать ее, создавать сессию с новым SESSID (желательно заданным с помощью uniqid();) и помещать эти данные в нее. Тут уже практически у любого пользователя воровать SESSID не имеет смысла - в 99% сессия окажется истекшей.

Наверное никак.
< Хотя, конечно тут все зависит от задачи, ну к примеру при реализации CMS?
Вопрос вроде так стоял, а к админке длительный вход вроде нонсенс...
ЗЫ Не туда попало, выше постом...

>а к админке длительный вход вроде нонсенс...
Почему нонсенс, увеличьте время действия сессии.
Скажем

ini_set("session.gc_maxlifetime", 3600);

Увеличит время действия сессии на час.

P.S. Второй параметр - секунды.

Она кстати не "одноразовая" :) На сеанс работы ее хватит, а дольше - возникает опасность ее несанкционированного использования (паранойя?:-D). Есть один бесплатный хостинг, где сессия жила дольше суток. Сайты на нем щелкали как орехи (меня в то время тоже на него угораздило).

ну должен же всё таки быть какойто нормальный способ для длительного авторизаО_о

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

помните! Чак Норрис настолько суров, что обойдет любую авторизацию