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

Стандарт не должен описывать все методы обхода, он лишь должен сказать, чтобы эффективно проверяли (не поверхностно). Как наличие дыр, так и надёжность систем защиты - в том числе и капч и блокировок, о чём я писал в своих статьях. А учитывая, что в прошлом году у моего клиента на сайте была BF (которую я выявил), а в этом году, после PCI DSS аудиторов, были добавлены два уровня защиты (оба дырявых, которые я легко обошёл), то я предполагаю, что именно они посоветовали данные защитные механизмы.

Що цікаво, попередній метод (з яким я неодноразово стикався на протязі 2009-2011) і цей метод я застосував під час аудиту в липні на одному українському е-комерс сайті (мого клієнта). При тому, що цей сайт перед цим пройшов PCI DSS аудит у закордонних “спеціалістів” і таких проблем вони не виявили. Так що такі прості методи не по зубам стандарту PCI DSS і аудиторам, що працюють по ньому.