Здравствуйте, 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:postmas...@softsearch.ru _______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru