ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Авторизация



Здравствуйте, Михаил.

Вы писали 23 января 2014 г., 15:35:37:

> Здравствуйте, Pavel.

>>>> Всё просто. Суёшь в авторизационную куку логин пользователя и хэш.
>>>> А  на  стороне  сервера  считаешь хэш от логина, пароля, подсети и
>>>> salt и смотришь, равен ли он тому, что пришёл в куках.

>>> Я  не  специалист по криптографии, но насколько понимаю просто хэша
>>> тут недостаточно, нужен HMAC.
>>> В инете на эту тему за 5 минут нашел только такую статью:
>>> http://rdist.root.org/2009/10/29/stop-using-unsafe-keyed-hashes-use-hmac/

>>> Но встречал и более наглядные объяснения, почему нельзя в куке для 
>>> авторизации хранить просто хэш и нужен именно HMAC.

>> Кто-нибудь может кинуть ссылку на более наглядные объяснения с более
>> человекопонятной  схемой,  как  это ломается? Либо может быть кто-то
>> разъяснит  "на  пальцах", как злоумышленник, имея одну или несколько
>> пар  "userId  + keyedhash" сможет сгенерировать пару "admin_userId +
>> valid_keyedhash"?

> Как  ломается,  сам  пока  не  разобрался.  Но  атака ведётся на поиск
> константной строки, которая конкатенируется к данным (в Вашем случае к
> userId  ).  Когда  она  или  её  замена  найдены, то берётся админский
> userID,  найденная  строка  и получается подпись для админа. Далее она
> суётся в куку вместе с id админа и у юзера права админа.

Хорошо. Т.е. если на сервере проверка при этом делается по схеме

- Получили из куки userId
- Получили некий зависимый от userId идентификатор, например номер телефона
- вычислили HashFunction( userId, StaticOrRollingKey, GetSomeUserData(userId))
- сравнили хеш из куки и и вычисленный

то такая схема "более безопасна" и относительно стойка к вышеприведенной атаке?

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





-- 
С уважением,
 Pavel                          mailto:pavel2000@xxxxxx

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru


 




Copyright © Lexa Software, 1996-2009.