ПРОЕКТЫ 


  АРХИВ 


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[2]: Авторизация



Здравствуйте, 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 админа и у юзера права админа.


-- 
С уважением,
 Михаил                          mailto:postmaster@xxxxxxxxxxxxx

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


 




Copyright © Lexa Software, 1996-2009.