Achtergrond informatie

ReCaptcha is met als doel gemaakt om de integratie van een captcha in je applicatie zo simpel en veilig mogelijk te maken.



Het hele systeem is gebaseerd op het API principe. Met andere woorden: een client kan met behulp van een request maken naar de server en de response wordt gebruikt binnen de API. In dit geval is die response de hele captcha en heeft de client maar één bestand nodig; in mijn geval recaptcha.php. Omdat het hele systeem een API is, moet het ook kunnen identificeren. Dat gebeurt met behulp van een private en public key.
Omdat het op het API principe is gebaseerd, heb je de GD library ook helemaal niet nodig, omdat het genereren van het plaatje allemaal op de server van reCaptcha gebeurt. Hierdoor is de server belasting voor jouw ook minimaal.

Wat reCaptcha zo uniek maakt, is dat reCaptcha woorden uit ingescande boeken gebruikt. Hierdoor is er een enorm scala aan woorden en dus meer variëteit aanwezig in de captcha zelf. De woorden worden ook nog eens vervaagd, waardoor de kans van slagen van een captcha-recognizer minder groot wordt.
Het is ook mogelijk om een audio versie van de captcha te gebruiken. Hier worden audio-signalen gebruikt om de gebruiker de juiste invoer door te geven.

Een andere toepassing die reCaptcha heeft, is veilige e-mail adressen weer te geven. Met behulp van een encryptie methode wordt het e-mail adres in de html versleuteld, maar is het nog steeds mogelijk om het op de pagina weer te geven. Ook hier wordt de private en public key weer gebruikt, om zo te kunnen communiceren met de API op de server van reCaptcha.

Misschien is het je ook al opgevallen dat er twee woorden worden weergegeven op het plaatje in plaats van een. Dit komt, omdat er één woord is, waarvan de server API zelf het niet kon lezen (OCR) en één woord is, waarvan de server API zelf wel kon lezen.
Nu het interessante deel. De captcha bevat dus het onleesbare woord en het leesbare woord. Als de gebruiker nu beiden woorden in probeert te typen en vervolgens verzendt naar de server API, dan kan de server API al met enige vermoedens het onleesbare woord definiëren. Dit komt door de gebruiker, want de gebruiker heeft gezegd dat die vlek gelijk staat aan dat woord. De volgende keer stuurt de server API nogmaals die onleesbare woord, maar deze keer is er al iets meer zekerheid over de betekenis (bits en bytes) van die vlek. En zo wordt de vocabulaire steeds gevoed door de gebruikers zelf.

« Lees de omschrijving en reacties