Алгоритм правильной аутенфикации, подскажите, пожалуйста.

[storng]

Алгоритм правильной аутенфикации, подскажите, пожалуйста.

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

Пришла в голову следующая мысль.

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

Логин пользователя
Хэш логина

Id пользователя
Хэш id

Права
Хэш прав

Разумеется хэш будет не просто md5 а скажем двойной с солью.

Далее, пользователь входит на страницу админки, первым делом получаем данные из кук, проверяем соответствует ли данные хешам, если всё ок пускаем на страницу, если нет то показываем форму для аутенфикации.

Как вам этот вариант по безопасности?
Что лучше в этом алгоритме изменить для безопасности и оптимизации работы.

Также интересует вопрос следующего шага.
Я хочу на каждой странице админке получать куку и сверять данные и в зависимости от прав выводить соответствующую информацию.
Это правильно вообще?

Заранее большое спасибо за любые советы.

 

[Beavis]

storng
А сессии в вашей версии пхп не поддерживаются?

 

[storng]

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

 

[Духовность™]

Права
Хэш прав

а как ты будешь проверять, что хэш прав не поддельный?

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

ты путаешь куки и сесии, точнее - их прямое назначение.

Задача сессии не должна состоять в том, что бы они жили вечно. На то они и зовутся сессиями. А вот куки можно хранит долго. Исходя из этого, можно понимать, что _автологин_ делать надо не с помощью увеличения жизни сессий, а с помощью кук. Имеется кука автологин и её параметры актуальны? Стартуем сессию и записываем туда данные, не проходя явного для пользователя процесса аутентификации. Вот и все.

при этом не желательно, каждый раз при входе пользователя лазить в БД

а что в этом зазорного? Получить права + инфу о пользователе запросить из базы на основе данных из кук - этот тривиальные запросы.

 

[Фанат]

хэш прав лишний

-~{}~ 07.04.10 13:53:

при этом нежелательно каждый раз при входе пользователя лазить в БД.

Желать надо осмысленные вещи, а не всякие глупости

 

[storng]

triumvirat
Спасибо за советы, задумался.

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


По поводу сессий, а почему именно их использовать, а не пользоваться постоянно куками?

По поводу вашего последнего предложения, я так понял, что оптимальнее всё-таки поступить следующим образом:

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

Далее, когда человек входит в админку, берём логин, проверяем его хеш, далее лезем в БД, находим этого пользователя и получаем его права, которые пишем в сессию вместе с логином и хеш этих данных?

А если сессию сопрут и расшифруют права и укажут другие, или при открытии любой страницы каждый раз лазить в БД за правами и не хранить их в сессии?

-~{}~ 07.04.10 13:55:

Автор оригинала: *****
хэш прав лишний

-~{}~ 07.04.10 13:53:


Желать надо осмысленные вещи, а не всякие глупости

Понял, спасибо!

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

 

[Фанат]

а кроме прав ничего из базы не запрашивается? тупо отдается одна и та же карнитка из кеша?

 

[storng]

Автор оригинала: *****
а кроме прав ничего из базы не запрашивается? тупо отдается одна и та же карнитка из кеша?

убедительно =)

Ещё раз уточню, значит в куках я буду хранить только логин и хэш
как человек заходит в админку, проверяю его логин<>хэш, если всё ок, лезу в БД получаю роль (права).

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

 

[baev]

И где здесь «теория программирования»?

 

[storng]

Автор оригинала: baev
И где здесь «теория программирования»?

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

 

[Духовность™]

Если пользователей будет 1000, и страниц, которые они посещают тоже большое количество, это сильно ударит по производительности?

когда будет и когда ударит, тогда и поговорим .

По поводу сессий, а почему именно их использовать, а не пользоваться постоянно куками?

кто сказал, что именно сессии надо использовать?

ты пойми разницу между куками и сессиями. концептуальную разницу, а не физическую. Куки - это часть протокола HTTP. Сессии - это механизм PHP, основанный в т.ч. и на куках, но имеющих иную концепцию и назначение.

Идентифицировать пользователя всегда нужно из кук. А на основе идентификации можно либо

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

Чем плоха реализация хранения прав в сессиях? При изменении прав нужно как-то отслеживать пользователя со старыми правами и убивать его сессию.

 

[storng]

triumvirat, Фaнaт большое спасибо за помощь, теперь понял как лучше это делать

 

[Фанат]

интересует оптимальный алгоритм

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

 

[storng]

Автор оригинала: *****
оптимальный алгоритм вычисления, сколько будет дважды два - сложить 2 и 2. Для обсуждения этого алгоритма в академию наук обращаться не обязательно

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

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

Ну как вам?

 

[Beavis]

storng
смотри чтоб нельзя было просто изменить УИ в куках и превратиться в админа

 

[dr-sm]

storng а зачем еще один уникальный идентификатор (УИ) если есть Id?

 

[storng]

Автор оригинала: Beavis
storng
смотри чтоб нельзя было просто изменить УИ в куках и превратиться в админа

Нет, УИ будет уникальный длинный код, который просто хранится в доп. поле пользователя в БД
далее уже, в функции авторизации я по этому УИ смотрю в БД пользователя и получаю из БД права пользователя и доп. информацию.

-~{}~ 07.04.10 19:19:

Автор оригинала: dr-sm
storng а зачем еще один уникальный идентификатор (УИ) если есть Id?

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

Т.е. УИ будет у каждого пользователя свой, т.е. строка вида: ERTERterteTTERT.345EERTERTEFBN.ERT345erRERNF.ERTERTE34756EJJSRT
Имея эту строку я получаю в БД по ней самого пользователя и его реквизиты для работы.
Т.е. каждый раз на каждой странице я беру этот УИ, лезу в БД, получаю данные, заношу их во внутренний массив и работаю в пределах этой страницы уже только с массивом.
Чтобы получить другие права пользователь должен подобрать УИ другого посетителя (что нереально), либо украсть куку, но тогда вообще ничего не поможет, если только привязываться к IP что абсолютно нереально.

 

[dimagolov]

а вот строку из 60 разных букв и цифр, абсолютно уникальная для каждого пользователя - это запросто.

обчно достаточно md5(id + salt + <тут по вкусу, время создания или еще что, чтобы менялся для пользователя со временем>)

 

[storng]

Автор оригинала: dimagolov
обчно достаточно md5(id + salt + <тут по вкусу, время создания или еще что, чтобы менялся для пользователя со временем>)

хм, интересно!

Ну, т.е. в любом случае, если есть то, что меняется со временем, значит этот guid нужно хранить в БД?

 

[dimagolov]

его хранить стоит в любом случае, чтобы отделить те, что мы выдавали клиентам от тех, которые нам подсовывают. кроме того, md5 это хеширование, то есть необратимый процесс и перебирать все id в базе не стоит, проще хранить хеши.