Client-side captcha

Díky tomu, že spammeři vám vlezou úplně všude, je dnes běžnou součástí většiny formulářů, je dnes běžnou součástí většiny veřejně viditelných webových formulářů captcha. Tedy otázka nebo úkol, jehož zpracování je pro člověka triviální, ale počítač se s ním (zatím) nedokáže jednoduše vypořádat.

Určení, jestli formulář vyplnil člověk nebo spamovací automat je pak jednoduché - pokud je úkol splněný správně, pak formulář zřejmě vyplnil člověk. Pokud ne, byl to počítač. Nepříjemné je, že splnění úkolu se musí testovat na serveru - pokud by k němu docházelo pouze na klientovi, bylo by pro spammery jednoduché tuto kontrolu obejít vyřazením testu (například vypnutím JavaScriptu) a pak odesílat obsah formuláře automaticky.

Na druhou stranu ale je nepříjemné, že pokud formulář obsahuje validaci hodnot v JavaScriptu, pak se tato validace nedá moc dobře vztáhnout i na captchu. Lze sice najít jednoduché řešení pomocí AJAXu, ale to naráží na asynchronní komunikaci a na bezpečnostní omezení XMLHttpRequestu (zakázané cross-domain requesty, které nemusí, ale mohou vadit).

Druhá možnost, jak dosáhnout validace už na straně klienta, je inspirovat se kryptografickými postupy. Víme například, že faktorizace na prvočísla je těžký problém, pro který neznáme efektivní algoritmus. A teď jak toho využít pro tvorbu captchy:

1. Příprava na serveru: server vygeneruje dvě dostatečně velká prvočísla p a q a vypočítá jejich součin n. Prvočíslo p zakóduje do captchy (například jako obvyklá čísla v obrázku) a spolu s obrázkem pošle číslo n.
2. Klient dostane obrázek s kódem a číslo n. Uživatel opíše číslo z obrázku. Pokud ho opíše správně, jde o prvočíslo p a číslo n je jím dělitelné bez zbytku. JavaScript během validace formuláře ověří dělitelnost a v případě neúspěchu upozorní uživatele.
3. Protože faktorizace je obtížný problém, klient pouze na základě čísla n nemůže v rozumném čase zjistit, jaké jsou hodnoty p a q. Navíc, pokud by jí provedl, uspěje pouze v 50 % případů, protože správná odpověď je pouze jedno prvočíslo, klient ale bez použití obrázku neví, které z prvočísel to je.

Pro dosažení rozumné bezpečnosti je potřeba použít delší prvočísla. Dostatečná hodnota by mohlo být například 256 bitů na jedno prvočíslo. Drobnou nevýhodou této metody je, že taková prvočísla mají cca 77 číslic (znaků), což by odradilo nejen spammery, ale i běžné uživatele. Pokud pro kódování použijeme i velká a malá písmena, sníží se počet znaků na 44, což moc velké zlepšení není.

Lepší tedy je použít alternativní řešení (díky Jirkovi za nápad), zvolit dostatečně dlouhý náhodný kód, tak 6-10 znaků, zakódovat je do captchy klasickým způsobem a spolu s captchou poslat hash kódu. Pokud bude hashovací funkce zvolená rozumně, nebude možné pomocí ní získat původní kód a navíc inverze hashovací funkce opět povede k více možnostem, z nichž jen jedna bude správná.

Nejlepší (nejjednodušší) nakonec ale stejně bude přestat teoretizovat, zůstat u současných (osvědčených) řešení a captchu ověřit jen na straně serveru...