Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 7
Во всех проектах стараюсь хранить в куках только идентификатор сессии, а все данные, относящиеся к сессии — в хранилище на сервере.
А собственно кто-то читал статью по ссылке? Там вообще то описан метод расшифровки и шифрования данных, не имея ключа, а ориентируясь исключительно по ответам сервера. Каким образом из этого можно получить ключ — для меня неясно.
Кроме того для расшифровки/шифрования одного блока нужно выполнить 128*(размер блока) запросов к серверу. Это первое.
Второе: метод не зависит от выбранного алгоритма шифрования. Зато зависит от режима шифрования (потому что все используют CBC и надеются таким образом обеспечить не только шифрование но и подлинность данных). Если бы использовали CBC совместно с MAC подписью — таких проблем не было бы.
Учитывая, что и AES и 3DES — блочные шифры, нет разницы, какой из них использовать. .NET всё равно будет использовать режим шифрования CBC для подтверждения подлинности кук.
В общем, проблема действительно есть, но не та, которая описана в статье.
Кроме того для расшифровки/шифрования одного блока нужно выполнить 128*(размер блока) запросов к серверу. Это первое.
Второе: метод не зависит от выбранного алгоритма шифрования. Зато зависит от режима шифрования (потому что все используют CBC и надеются таким образом обеспечить не только шифрование но и подлинность данных). Если бы использовали CBC совместно с MAC подписью — таких проблем не было бы.
Учитывая, что и AES и 3DES — блочные шифры, нет разницы, какой из них использовать. .NET всё равно будет использовать режим шифрования CBC для подтверждения подлинности кук.
В общем, проблема действительно есть, но не та, которая описана в статье.
Я так и не понял, эти «Два исследователя безопасности» взломали Advanced Encryption Standard (AES)? За 50 минут??? Что за бред? :-)
Вообще-то заголовок немного не соответствует действительности.
Прочитайте оригинальную презентацию: netifera.com/research/poet/PaddingOracleBHEU10.pdf
чуваки нашли уязвимость в использовании блочного шифра + CBC (тут 3DES не поможет, он тоже блочный, а Peter Vogel — фантастический идиот).
в их презентации есть примеры не только для ASP.NET, но и для RoR и JSF, так что ребята сеят панику прямо ковровым бомбометанием.
Но, оказывается, что для успешной атаки им надо знать, произошла ли ошибка из-за неверного паддинга(!), или по другой внутренней причине (например такой user id не существует или ip не тот).
Но вы же, как все здравомылящие люди, не оставляете в продакшене вывод ошибок в бразер, не так ли?
Прочитайте оригинальную презентацию: netifera.com/research/poet/PaddingOracleBHEU10.pdf
чуваки нашли уязвимость в использовании блочного шифра + CBC (тут 3DES не поможет, он тоже блочный, а Peter Vogel — фантастический идиот).
в их презентации есть примеры не только для ASP.NET, но и для RoR и JSF, так что ребята сеят панику прямо ковровым бомбометанием.
Но, оказывается, что для успешной атаки им надо знать, произошла ли ошибка из-за неверного паддинга(!), или по другой внутренней причине (например такой user id не существует или ip не тот).
Но вы же, как все здравомылящие люди, не оставляете в продакшене вывод ошибок в бразер, не так ли?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проблема с безопасностью при использовании аутентификации формами в ASP.NET