Lo scorso febbraio ho finito di realizzare il sito di Linea4Office, dove ho messo in pratica gli insegnamenti di Michele Diodati per la realizzazione di CAPTCHA accessibili. I CAPTCHA sono quei codici di riconoscimento che un utente deve trascrivere in un form al fine di stabilire se il sistema sta dialogando con un essere umano o con un robot usato dagli spammer per intasare i siti di messaggi indesiderati.
Il problema è questo: la maggior parte dei CAPTCHA fa uso di immagini che l’utente deve decifrare. Ovviamente questa soluzione non è accessibile per gli utenti che usano un lettore di schermo o un browser testuale. Alcuni siti, come Google, hanno deciso di usare CAPTCHA alternativi sotto forma di file audio. Ma questa soluzione, alla lunga, non è ottimale: sia le immagini che i file audio sono piuttosto laboriosi da implementare da un punto di vista lato server. Ecco allora la soluzione di Michele: porre all’utente una domanda a cui solo un essere umano è in grado di rispondere (per esempio: “felino domestico, detto anche micio”). I risultati sono sorprendenti: dopo quasi nove mesi online, il proprietario del sito di Linea4Office non ha ricevuto nessuna email di spam. Per operare un raffronto sulla velocità dello spamming, basti bensare che in quello stesso lasso di tempo la mia casella di posta aveva ricevuto centinaia di email di spam nel periodo febbraio-agosto 2009 (ossia dopo aver pubblicato la mia email online).
A Michele va certamente una lode che ancora una volta conferma l’eccezionale statura tecnica di questa persona.
Salve,
la soluzione è interessante, solo che a lungo andare, le definizioni che saranno limitate, anche se in numero elevato, si ripeteranno e, se questo sistema di riconoscimento tra esseri umani e programmi dovesse prendere piede e presentarsi su vari siti, prima o poi si realizzerà un sistema di hacking piuttosto semplice (implementarlo ad esempio per il sistema di captcha-recognition di JDownloader sarebbe un lavoro di una ventina di minuti, con tanto di sistema di richiesta all’utente di inserire le definizioni mancanti e di apprendimento del sistema delle nuove definizioni).
Questo sistema inoltre potrebbe portare a dei falsi negativi, ovvero una definizione che ammette più risposte in soluzione, oppure sinonimi delle risposte.
Implementarlo e migliorarlo è sicuramente un gioco da ragazzi, basti pensare alla realizzazione di un sistema che generi per iscritto operazioni matematiche, ad esempio: “sommare cinque, nove ed undici (il lettere)”, ma un programmatore smaliziato potrebbe facilmente realizzare l’algoritmo che ne ricava una formula (ad esempio “SUM 5, 9, 11″) e dunque si è di nuovo a capo.
Il sistema dei CAPTCHA è e sempre sarà un gioco di guardie e ladri, quando le guardie avranno le pistole semi-automatiche, i ladri acquisteranno quelle automatiche, quando i poliziotti avranno giubbotti anti-proiettile, i ladri acquisteranno proiettili in grado di perforarli.
La sicurezza, soprattutto online, è un argomento assai interessante, ma dire che questo sistema funzioni, pubblicato su un solo sito, mi sembra una notizia un tantino affrettata.
Non ho idea del numero di visitatori univoci giornalieri del sito in questione, ma il mio sistema di captcha sopracitato utilizzato per il sito di un hotel ha purtroppo fallito miseramente dopo soli 6 mesi di operatività. Risultato: un guestbook riempito di 12000 record di proposta di vendita di pillole magiche e di incontri per adulti.
Ben lungi da me l’idea di pubblicizzare la mia personale soluzione di captcha.
Christian
Grazie per le tue osservazioni, molto corrette.
Concordo.
Un altro problema è l’internazionalizzazione: l’utente deve comprendere la lingua in cui è proposta la domanda.
Questo implica che bisogna preventivamente riconoscere la lingua utilizzata dall’utente, in modo automatico, o eventualmente consentendo all’utente di selezionare la lingua per la domanda.
Questo implica che dobbiamo adattarci praticamente a qualunque lingua del pianeta, pena l’impossibilità di consentire l’accesso alle funzionalità offerte.
Vero è che si presuppone che l’utente sia in grado di comprendere la lingua del sito, e come minimo l’inglese.
Ma nessuno dovrebbe impedire a qualcuno di voler scrivere un messaggio in una lingua non prevista.
Inoltre il captcha potrebbe offrire l’accesso a contenuti indipendenti dal linguaggio (immagini, musica, …), e quindi il prerequisito della conoscenza della lingua del sito decade automaticamente.
Inoltre la limitazione sul numero di domande porterebbe in breve ad avere un dizionario di risposte.
Cosa che, tra l’altro, di fatto già esiste in tutti quei siti di domande e risposte (answers.com, etc.).
In ogni caso l’idea è buona, e potrebbe essere utilizzata in contesti ristretti, con domande molto particolari (e possibilmente legate al profilo dell’utente che richiede l’accesso), per consentire l’accesso ad aree con elevati requisiti di sicurezza.
@Andrea Rui:
Il problema dell’internazionalizzazione è minimale. Lo script di cui parlavo io (CAPTCHA ad espressioni matematiche/letterali) è stato da me realizzato con un sistema di GeoLocation (identifica le lingue preferite dall’utente in base alle impostazioni del browser.
Per intenderci:
in Internet Explorer 8 dentro Strumenti -> Opzioni Internet -> Lingue;
in Firefox (WIN/LINUX) -> Strumenti -> Opzioni -> Contenuti -> Lingue;
in Firefox (MacOS) -> Firefox -> Preferenze -> Opzioni -> Contenuti -> Lingue;
in Chrome (WIN/LINUX/MacOS) Personalizza -> Roba da smanettoni -> Cambia carattere e lingua -> Lingue (e comunque nel caso fa lui le traduzioni delle pagine…)
Queste informazioni vengono inviati nell’header della request al server.
Altro modo attraverso il quale lo script identifica è quello di localizzazione attraverso l’IP della richiesta, attraverso servizi quali ip2location.com (in realtà usa un DB locale per velocizzare)
Tutte le regole di creazione delle frasi matematiche sono in un comodo file .INI e basta realizzarne uno per una nuova lingua e in meno di 30 minuti si configura, così come hanno fatto tanti programmi: si lascia alla community fare parte del lavoro.
I contenuti indipendenti dal linguaggio purtroppo, come spiegato nell’articolo hanno delle limitazioni (cecità, sordità) inoltre io stesso mi sono trovato in difficoltà più di una volta a leggere dei caratteri nei captcha grafici con distorsione, oppure il riferimento allo zero (0) e alla lettera O maiuscola, che a seconda del font usato per generare l’immagine possono essere molto simili.
Inoltre, come avevo risposto per le definizioni (l’esempio del gatto), nelle immagini si possono avere molti punti di vista. Supponiamo di realizzare un database contenente delle immagini di animali e la definizione. Uno script fornisce l’immagine e chiede di identificarlo. Una foto presa su internet di un cavallo. Ma io potrei provare ad inserire un pony perché mi sembra di altezza ridotta o puledro perché mi sembra giovane ed esile.
Alcuni captcha del genere (per fortuna non quelli a larga diffusione) sono anche realizzati male, lasciando nel codice un riferimento chiaro del contenuto dell’immagine (ovvero: viene trasmessa anche la soluzione del captcha).
Alcune prime implementazioni di captcha audio erano a dir poco ridicole: Il file audio non veniva generato lato server, ma veniva caricata una playlist (tipo la seguente in formato ASX (Windows Media Player)):
Ovviamente questo è un esempio: e facile vedere che i file che vengono eseguiti in successione hanno il nome che indica la lettera o il numero che comunicano. (Posso assicurarvi che questo è ciò che ho trovato)
Altri metodi che avevo trovato per limitare le possibilità di tentativo di forzatura erano:
1. il più banale: presentare ad ogni errore di immissione un nuovo captcha.
2. legare una singola domanda ad una sessione (realizzata con l’ID di sessione generato dal server o usando un cookie (e qui ci sono pro e contro)) per identificare univocamente il browser dell’utente, in questo modo anche se l’utente esegue il refresh della pagina la domanda che gli viene posta è la medesima. Questo sottostando comunque al punto 1.
3. legare la storicità delle domande ad una sessione, ovvero non ripresentare per la stessa sessione due volte la stessa domanda, se non altrimenti possibile (fine delle possibilità nel caso di una lista di definizioni, illimitato nel caso del mio sistema)
4. legare la storicità anche all’ip pubblico che genera la richiesta. questo ha un contro: potrebbe portare a problemi di accesso simultaneo da computer dietro un gateway (router o condivisione connessione internet) o proxy.
5. usare codice JavaScript, tecniche di AJAX, un filmato Flash o un applet Java per la visualizzazione nel client. Rendendo più difficile la lettura del codice della pagina da parte di un programma automatizzato si guadagna parecchio tempo. Personalmente ho usato un semplicissimo captcha all’interno di un sito web interamente realizzato in Flash. Nonostante gli oltre tre milioni di accessi univoci e le svariate iscrizioni alla newsletter ed e-mail di richiesta contatto, non vi è stato nessun tipo di intrusione o di invio di SPAM.
Per il resto concordo con te, su un sito con un numero ristretto di accessi una qualsiasi soluzione è sufficiente. Se poi, nel caso del sito indicato dall’articolo, non si punta su mercati più larghi dell’Italia, si sta anche più tranquilli.
Tornando al sito dell’hotel di cui parlavo nel primo reply, il sito era entrato in varie directory e rings per hotel, tutte cose facilmente tracciabili da un crawler…
Con questo penso di aver esaurito e condiviso con voi in toto la mia conoscenza sull’argomento
Ciao
Christian
L’esempio di file ASX è stato tolto… peccato.