Не згоден, що природня.

Природня для даного алгоритму (й для більшості інших алгоритмів капч) - оновлення капчі при перезавантаженні сторінки з капчою.

Безпека, котра псує юзабіліті - це погана безпека.

А юзабіліті, що зменшує безпеку - це шкідливе юзабіліті. І ним я можу пожертвувати за для безпеки .

І твої поради не вирішують проблему по суті, а залатують дірки.

Як я писав раніше (п.2), в мене є ідея, що кардинально вирішить дану проблему. І при цьому без змін в алгоритмі самої капчі.

Будь-які ускладення алгоритму можуть призвести до проблем з безпекою. Тому я і використовую простий, але достатньо ефективний алгоритм. Обмеження в часі (та без прив’язки до сторінок) призначено для протидії напівавтоматизованому методу обхода капч, про який я розповідав в MoBiC.

Якщо реалізувати прив’язку до сторінок, то окрім того, що ускладниться механізм роботи з сесіями (треба буде пам’ятати значення капч для всіх відкритих кожним користувачем сторінок в рамках поточних сесій), також стане можлива атака з використанням напівавтоматизованого метода обходу на різні сторінки сайта. Тобто на відміну від класичної атаки з даним методом на одну сторінку, спам буде розсилатися на різні сторінки. Ось тому й я не роблю подібних прив’язок і використовую перевірений алгоритм.

Це природня робота капч з даним алгоритмом (і це робиться за для безпеки) - тому варто звикати , бо на інших сайтах з цим також можеш стикнутися.

Не згоден, що природня. Твоя ціль - ротація каптчі, але це можна зробити більш зручно для користувачів. Безпека, котра псує юзабіліті - це погана безпека.

Тема для холівару, але я впевнений у цьому. І твої поради не вирішують проблему по суті, а залатують дірки.

Я запропонував простий шлях: прив’язуй ключ до сторінки, і перезаписуй його при оновленні тільки цієї сторінки. Це не погіршить безпеку, але вирішить іншу проблему.

Адже я навіть не прошу елементарних речей типу зберігання даних форми якщо людина невірно ввела каптчю

З каптчею дурна проблема: коли відкриваєш в іншому табі іншу сторінку сайту, то каптча переписується в сесії.

Це звичайна особливість роботи капчі - що в сесії записується тільки останнє значення капчі (так працюють більшість капч, що використовують сесії). І це трапляється лише у випадку, коли ти відкрив (в табі) іншу сторінку з капчею. Якщо ж відкриєш іншу сторінку сайта де капчі немає, то і проблеми не буде. Це природня робота капч з даним алгоритмом (і це робиться за для безпеки) - тому варто звикати , бо на інших сайтах з цим також можеш стикнутися.

Проблему з капчою, з якою ти постійно маєш справу, можна вирішити двома шляхами.

1. Ти можеш звикнути до неї (і алгоритму її роботи). І інші сторінки з капчою відкривати або без графіки (щоб не оновилося її значення в сесії), або враховуючи останнє значення капчі в останньо відкритому табі, й вводити його в тому вікні де ти пишеш коментар.

2. Або використати інший метод, який повністю вірішить дану проблему з капчою. І про який я вже давно замислився, враховуючи твої постійні потасовки з моєю капчою (яка в мене стоїть на варті).

То я говорив не про працівників, а про безпеку сайтів банків. Але ясна річ, в банках є люди, які відповідають за безпеку сайтів банків - секюріті працівники (в тому числі керівники секюріті департаменту), а також топ менеджмент, що відповідає за фінансування цього напрямку. Ось до них цілком може віднестися моє формулювання (якщо за безпекою власного сайта не слідкують).

З каптчею дурна проблема: коли відкриваєш в іншому табі іншу сторінку сайту, то каптча переписується в сесії. Може якось прив’яжеш до сторінки, можна тупо - id статті використати як ключ асоціативного масиву, в який класти код капчі (чи хеш, що ти там кладеш).