Ci sono parecchie cose che si possono dire far parte della nostra routine quotidiana, prendere il caffè, lavarsi i denti, ascoltare la radio, fare la spesa…inserire username e password.
Che si tratti di un bancomat, della casella di posta elettronica o della rete aziendale, per accedere ad informazioni e/o risorse riservate, dobbiamo provare la nostra identità.

La maggior parte di queste autenticazioni, come sono definite tecnicamente, siamo chiamati a effettuarle su accessi ad Internet; ripetiamo le stesse operazioni più volte al giorno, anche per il medesimo servizio, identità reale, nickname o avatar che sia.
Talvolta è solo noioso, quando non è una vera e propria scocciatura perchè andiamo di fretta e dobbiamo ripescare username e password tra decine di coppie tutte diverse e magari annotate chissà dove…o, peggio, le abbiamo perse ed inizia la trafila del recupero, tramite la domanda segreta (la squadra del cuore od il cognome da ragazza della mamma) oppure con il riinvio della password alla casella di posta associata al profilo. E se quella casella nel frattempo l’avessimo cambiata? O magari abbiamo perso la password anche di questa? Un disastro…

…un solo username, una sola password

Personalmente, ho circa centocinquanta password per uso privato ed un altro centinaio per lavoro; di sicuro ogni giorno ne uso almeno venti diverse e ne so a memoria giusto tre o quattro, quelle di uso strettamente quotiano. Gestirle è complicato e a tutt’oggi non ho trovato una soluzione soddisfacente, comoda e sicura sotto tutti i punti di vista.
C’è chi risolve il problema usando sempre la stessa password per tutto, ma si augura che non arrivi mai il giorno in cui dovrà cambiarla, perchè non saprebbe rintracciare tutti i sistemi in cui l’ha utilizzata. Altri ricorrono a software specializzati per immagazzinarle con sicurezza, talvolta integrati nel browser sotto forma di plug-in.

Se sulla password abbiamo un buon margine di manovra, lo username quasi mai è lasciato alla nostra discrezione; ci impongono l’email, ce lo generano d’ufficio oppure ci sono quelli che si registrano sempre prima di noi (1).

Dal punto di vista di noi sviluppatori, l’implementazione dei servizi di autenticazione, immagazzinamento e gestione delle password, oltre a essere un compito ripetitivo e talvolta noioso, è anche un problema rischioso e spesso molto dispendioso.

Alla luce di tutte queste considerazioni, non è la prima volta che desta interesse la prospettiva di un sistema di autenticazione centralizzato. Poter aver un’unica username ed un’unica password comune a diversi sistemi di diversi fornitori; un unico sistema di gestione per cambiarla in qualunque momento; un unico database con queste infomazioni, se possibile più sicuro da attacchi e manomissioni.

Le perplessità e le domande sono ovviamente speculari. Chi è il gestore dell’archivio con queste informazioni ? Chi ne controlla l’autorevolezza e la trasparenza ? Cosa ne garantisce la continuità di servizio nel breve e nel lungo periodo ? Sono al sicuro da furti di identità e dalla profilazione su ciò che faccio e scrivo ?

Il problema è apparentemente irrisolvibile. Quando più o meno nel 2000, Microsoft pubblicò il sistema Passport che offriva un servizio centralizzato di autenticazione basato sulla fornitura di una password e di un’email (non necessariamente di HotMail, su questo c’è sempre stato un equivoco (2) ) parecchie sono state le perplessità sorte sin dal primo momento.
Passport è comunque stato forse il primo sistema SSO (Single Sign On) su larga scala ed oggi vive un’evoluzione in Windows Live ID.

Al di là delle considerazioni tecniche sull’architettura del protocollo e sulla sicurezza dello scambio dei messaggi di autenticazione, il problema principale fonte di perplessità nei confronti di Microsoft è sempre stato quello di affidare ad un “ente privato” un così delicato compito, senza poterne conoscere e controllare le politiche di gestione, per non parlare dell’affidabilità del personale assegnato a tali attività e dei conflitti di interesse sottostanti.
Google propone una soluzione per consentire l’accesso alle Google Applications, basata sul protocollo SAML, dove è lasciata al partner la gestione dell’identità; ma anche con questa soluzione, le perplessità di cui sopra si spostano da un attore all’altro e non spariscono completamente.

Il problema è dunque non come ma chi può rivestire un ruolo così delicato. Non parliamo poi del fatto che, anche se in Italia dal punto di vista normativo in questo senso siamo all’avanguardia (3), stiamo pur sempre parlando di Internet e non ci sono autorità e/o normative valide ovunque e applicabili in maniera trasversale.

Il miracolo/spettro della biometria

Prima di proseguire, vorrei aprire una parentesi a proposito della biometria per cercare di fugare leggende che ne fanno per alcuni la soluzione a tutti i problemi di autenticazione e sicurezza, in contrapposizione ad altri che la vedono come il demone dei prossimi anni per il controllo e la profilazione delle masse.

Una breve premessa di natura tecnica è necessaria per spiegare di che cosa si sta parlando.
E’ biometria tutto ciò che ha come oggetto di studio la misurazione delle variabili fisiologiche o comportamentali tipiche degli organismi, attraverso metodologie matematiche e statistiche (Wikipedia). Questo significa che non ci si limita alle impronte digitali, ma il discorso di estende alla scansione della retina, alle impronte vocali, alla mappatura della vascolarizzazione della mano ed a tutto quello che ci si potrà inventare negli anni a venire.
Il punto di arrivo è comunque lo stesso: queste variabili fisiologiche vengono ottenute da dispositivi di input (talvolta dedicati) accoppiati ad opportuni software che trasformano le letture in modelli numerici, o meglio in vettori; sono questi ultimi che vengono associati all’account dell’utente e fungono da termine di confronto per le successive letture. Sofisticati algoritmi sono in grado di comparare questi vettori di riferimento con quelli ottenuti successivamente anche se in modo impreciso o parziale. Il confronto ha successo se il grado di certezza che viene ottenuto dalla comparazione supera la soglia minima predefinta da chi ha impostato il sistema.

Al di là del problema della certezza dell’identificazione, che ci può interessare fino ad un certo punto e la cui soluzione è puramente una questione di evoluzione della tecnologia biometrica, la questione scottante è appunto chi custodisce i vettori di riferimento.
Ipotizzando infatti uno scenario in cui l’identificazione biometrica divenisse preponderante, ci dovrebbe essere per forza un’entità che associa i profili degli utenti ai vettori biometrici, nè più nè meno come si fa con le password. Se però queste informazioni venissero violate da ladri di identità, potrebbero essere usate per impersonare la vittima del furto emulando il dispositivo di lettura biometrica e sostituendo il vettore che dovrebbe essere letto dallo scanner con quello trafugato (4).
La differenza rispetto ad un comune furto di password, è che dopo la scoperta della violazione, la password può venire sostituita, un dato biometrico evidentemente no.

Paradossalmente, il punto debole della sicurezza biometrica è proprio la robustezza della sua univocità con il soggetto associato.
Pensare che si possano identificare degli enti affidabili e sicuri a cui affidare questo compito di custodia ed autenticazione mi sembra non solo utopistico ma anche ingenuo. Questa è la ragione per cui potrei affidare la protezione del mio pc ad un sistema biometrico implementato in locale sulla mia macchina, ma non mi fiderei mai di proteggere la mia email o, peggio, il mio conto corrente con un sistema, anche se sofisticatissimo, risiedente in rete.

Meglio molti, invece di uno

La parentesi biometrica ci ha comunque riportato sull’idea del certificatore esterno; l’unica praticabile se vogliamo districarci dalla selva di password, ma abbiamo bisogno di averne il controllo.
Ipotizziamo di potercelo scegliere, poterlo cambiare quando ci pare, anche solo temporaneamente, magari di implementarlo da soli (installando il software su un nostro server, oppure sviluppando la nostra applicazione). Ipotizziamo anche di poterci scegliere l’id da utilizzare e di poter usare la stessa doppietta username/password per tanti servizi di fornitori diversi, di poter modificare quest’ultima da un solo pannello di controllo facendo sì che la modifica valga su tutti i sistemi affiliati. Lo stesso dicasi per l’email associata all’account.

Se tutto questo fosse possibile, implementato magari con una tecnologia aperta, avremmo OpenID. Brad Fitzpatrick, il creatore di LiveJournal e foundatore di Six Apart, un paio di anni fa partì proprio da queste considerazioni per svilupparlo.

Come funziona

La genialità dell’idea sta principalmente nel come username e certificatore vengono associati in modo da consentire al titolare dell’account di modificarne la combinazione in modo abbastanza semplice e veloce. Ci sono tuttavia aspetti molto interessanti anche in fase di autenticazione.

Partiamo dall’username, definito come OpenID URL, che è appunto un indirizzo valido di una pagina web che il possessore è in grado di gestire in modo più o meno completo. È utilizzabile la pagina principale di un blog che supporti OpenID, come LiveJournal appunto, o che non lo supporti, ma che consenta di introdurre del proprio codice HTML, oppure ancora, una normale pagina HTML in uno spazio a cui abbiamo accesso diretto.
Nella sezione head della pagina introdurremo (o lo farà per noi il sistema di pubblicazione che supporta nativamente OpenID) un tag HTML, non visualizzabile, ma perfettamente leggibile da un sistema preposto a farlo, composto in questo modo:

<link rel=”openid.server” href=”http://openid.com/server/endpoint/url” />

L’attributo rel specifica il protocollo (in questo caso usiamo OpenID versione 1.0, la 2.0 è ancora in draft); mentre il secondo, href, è l’URL del certificatore esterno.
Si capisce subito che con questo speciale username, anche se un po’ più lungo dei soliti identificatori (5), possiamo:

1. garantirci comunque molteplici identità, se necessario, per usi anonimi o comunque non direttamente riconducibili all’identità in rete con cui siamo più conosciuti;
2. affidare temporaneamente o definitivamente ad un nuovo certificatore il compito di validare la nostra identità in qualunque momento lo desideriamo;
3. collegare ad un profilo pubblico e/o al blog il nostro username.

Resta da definire l’account presso il certificatore esterno, l’OpenID provider. Ce ne sono già parecchi, scegliamo quello di cui ci fidiamo, a meno di non diventare provider di noi stessi installandoci un’implementazione su un nostro server. Se siamo iscritti a LiveJournal o ad altri servizi che lo integrano nativamente, possiamo scegliere uno di questi.
In ogni caso, il nostro profilo presso il provider, conterrà le informazioni che completano il profilo di sicurezza, la password, l’email e eventuali opzioni sulle modalità di autenticazione. Quando dovremo modificare uno di questi parametri, lo faremo accedendo al sito del provider ed autenticandoci con i nostri OpenID URL e password.

Il principio fondamentale di OpenID è dunque che il proprietario dell’identità è il titolare dell’id e non il provider che lo gestisce. Ne è la prova il fatto che possiamo cambiare provider quando vogliamo e molto velocemente. Se desideriamo inoltre maggiori garanzie di copertura del servizio di autenticazione, possiamo ricorrere a provider “di riserva”, identificati come delegates che verranno interpellati in caso di indisponibilità del provider principale; sempre nella pagina corrispondente al nostro OpenID URL, sarà sufficiente aggiungere uno o più tag come questo:

<link rel=”openid.delegate” href=”http://mytest.myopenid.com”  />

Dal punto di vista utente non c’è molto altro da sapere (6), passiamo perciò a farci un’idea di come funziona il meccanismo di autenticazione nel momento in cui accediamo ad un sito (che chiameremo servizio da adesso in avanti) compatibile con questa procedura.
 In fase di login viene richiesto all’utente l’username, ossia l’OpenID URL. Il servizio carica la pagina associata, la scansisce alla ricerca del/i tag che abbiamo visto sopra e determina l’indirizzo dell’OpenID provider (che chiameremo provider da adesso in avanti) e la versione di protocollo da utilizzare.
A questo punto, il servizio è in grado di mettersi in contatto con il provider; opzionalmente, la comunicazione può avvenire in modo cifrato, ci sarà allora una breve negoziazione per le chiavi necessarie. Il processo di autenticazione dell’utente avviene tramite HTTP redirection, il che significa che il servizio redirige il browser sul provider in modo che autentichi l’utente senza che il primo vi prenda parte alcuna, men che meno tracciare le operazioni che l’utente fa (come inserire la password). Se l’utente si è già autenticato sul provider, ossia ha una sessione in corso, l’autenticazione viene completata con successo anticipatamente. Anche l’esito dell’autenticazione viene trasmesso via HTTP redirection; il servizio valida la risposta in funzione della precedente richiesta e se viene accettata, la fase di autenticazione termina con successo.
Voglio ancora rimarcare l’aspetto che grazie all’uso dell’HTTP redirection, servizio e provider non comunicano mai direttamente tra loro scongiurando buona parte degli attacchi noti come man-in-the-middle, dove in buona sostanza c’è un quarto attore posto in ascolto tra servizio e provider e diverso dall’utente.

All’autenticazione base, si possono inoltre aggiungere OpenID Simple Registration Extension, per effetturare la sottoscrizione a nuovi servizi OpenID senza richiedere alcuna compilazione del profilo utente (la risposta del provider fornisce al servizio otto attributi base, tra cui email, sesso, lingua etc…), e OpenID Attribute Exchange, valido solo per OpenID 2.0 e pensato per la lettura/scrittura di singoli attributi di identità personale (come l’email ed il numero di telefono).

Una schematizzazione più estesa di questi concetti è descritta nella nella prima parte di questa introduzione ad una libreria OpenID per Java.

Sicurezza

L’obiezione più scontata è sicuramente: se il nostro account OpenID viene in qualche modo violato, l’aggressore avrà accesso a tutti i servizi da esso autenticati. Perfettamente vero.
Ma spostiamo un attimo l’attenzione su come funzionano gli account classici: sono tutti associati ad una casella di email. Tutti ne abbiamo più di una, ma di certo non ne abbiamo una per ogni account. Se una di queste caselle venisse violata, il ladro potrebbe recuperare tutte le password connesse semplicemente fingendo di averla smarrita ed aspettando che arrivi la nuova per email. Improbabile? Non direi poi tanto.
Alternative al recupero via email ce ne sono poche e costose. I servizi che possono permettersi un call center rivelano da recenti analisi che l’30% delle chiamate è proprio motivato dal recupero delle password (Gartner Group), con costi che sono stati stimati (7) in media $25 per operazione (Forrester). E non è comunque difficile assumere l’identità di un’altra persona per telefono, avendo un po’ di informazioni di partenza e faccia tosta.

I principi di sicurezza che animano OpenID sono dunque:

1. affidarsi a provider che offrono le garanzie ritenute necessarie e nel momento in cui non le soddisfano più sostituirli;
2. offrire il minimo profilo possibile ad un attacco: se ci rubano la password o ci forzano l’email, da un unico punto di accesso possiamo cambiarli e propagare la modifica a tutti i servizi che sono associati.

Niente è perfetto

Ci sono ovviamente anche i contro.
Il blog di Tech Team Lead News fa una lista dei problemi principali e non sono solo di natura tecnica. Quello più evidente è di usabilità, tipico delle nuove soluzioni tecnologiche; i provider esistenti sono infatti ancora troppo expert-oriented. E’ lecito perciò aspettarsi innovazioni procedurali e tecniche che agevolino gli utenti non esperti nel creare, gestire ed utilizzare gli account OpenID.

Ci sono sicuramente problemi di sicurezza e un’interessante schematizzazione la si trova in questo articolo.
Tra questi spicca il phishing: un servizio truffaldino può redirigere l’utente verso un falso provider che estorcerà la password all’ignaro utente. Qui le contromisure tecnologiche possono essere molto complesse senza totali garanzie di protezione; rendere consapevoli gli utenti e fornire loro gli strumenti per identificare i siti fasulli è forse la strada meglio praticabile.

Non è escluso che OpenID possa evolvere ispirandosi ad altri standard come OAuth, che ha una sua soluzione per gli attacchi man-in-the-middle (phishing incluso). La dinamica dell’autenticazione dal punto di vista dell’utente è ben spiegata qui. Quest’ultimo è molto diverso da OpenID sotto molti punti di vista; non c’è un attore che funge da certificatore esterno e non c’è SSO nel vero senso della parola; abbiamo più servizi che devono scambiarsi tra loro dati appartenenti ai propri utenti. Ciascuno conserva l’autorità sull’autenticazione dei propri profili, ma quando c’è necessità di scambio dati, il servizio richiedente redirige l’utente sul servizio dell’offerente (in maniera analoga ad OpenID), dove quest’ultimo si autenticherà ed autorizzerà l’operazione. La sostanziale differenza è che i due servizi si conoscono a priori e condividono delle chiavi segrete per effettuare operazioni uno sull’altro se l’autenticazione ha avuto successo; accorgimento che impedisce che un servizio fasullo si inserisca in mezzo per carpire identità o informazioni.

Più business

Soluzioni come OpenID sono sicuramente un’opportunità per i fornitori di servizi. Oltre ai già citati costi di implementazione e gestione, è inutile nascondere che le maschere di sottoscrizione costituiscono un ostacolo per i nuovi utenti, che non hanno voglia di perdere tempo e sono sempre istintivamente restii a lasciare anche solo la propria email su un nuovo sito.

Molti grandi si sono già mossi, AOL, Orange, WordPress sono solo alcuni di questi.

Blogger, lo ha introdotto a titolo sperimentale da pochi giorni per velocizzare le operazioni di firma dei commenti. Applicazioni di questo tipo, che si classificano in termini di rischio sicurezza ad un livello tutto sommato molto basso, possono trarre notevole giovamento da innovazioni come questa proprio per le ragioni sopra.

Microsoft qualche mese fa ha annunciato l’introduzione della versione 2.0 di OpenID in Vista come complemento a CardSpace.

Firefox lo ha incluso nei requisiti della versione 3.0.

Conclusioni

C’è già qualcuno che oggi definisce OpenID come l’HTML dell’identità.
È difficile dire adesso se potrà anche solo avvicinarsi al successo del primo e se non emergeranno altri standard migliori o semplicemente più forti politicamente. Di certo, il problema è importante ed in tale crescita di percezione che una soluzione in questa direzione dovrà necessariamente venire individuata.

Note

(1) Mi piacerebbe potermi identificare sempre come “cosimo”, ma nella maggior parte dei casi anche oltreoceano, nonostante sia un nome non certo raro ma nemmeno comunissimo, c’è quasi sempre qualcuno che mi precede. (back)

(2) In realtà Microsoft, evidentemente interessata a farlo, offre la possibilità di crearsi un account su HotMail, servizio del quale è proprietaria, ma non esclude l’utilizzo di altri account di posta; molti utenti hanno erroneamente interpretato questa offerta, messa peraltro in maggiore evidenza della seconda opzione, come un requisito. (back)

(3) Le problematiche relative alla tutela/violazione delle password rientrano sia nel dominio dell’arcinota legge sulla privacy (D.Lgs 196/2003) che in quello della legge sulla criminalità informatica (Legge 547/1993). (back)

(4) Eseguire questa operazione è solo apparentemente complesso. Tutti i produttori di dispositivi biometrici corredano i propri prodotti di strumenti software di supporto allo sviluppo che includono anche programmi di emulazione da impiegare in fase di test delle applicazioni. Adattare software del genere per gli scopi sopra è piuttosto semplice e spesso nemmeno necessario. Nel caso di una web application, la cosa richiede lo sviluppo di un po’di software ma non è impossibile. (back)

(5) Se usiamo il nostro blog, dovrebbe essere piuttosto memorizzabile e relativamente velocemente digitabile; meglio ancora, se il dominio ci appartiene ed abbiamo il controllo dell’area file, possiamo mettere nella pagina indice della radice (index.html) il tag in questione e ridurre di molto la lunghezza dell’id da digitare. (back)

(6) In realtà OpenID versione 2.0 prevede anche la possibilità di specificare gli OpenID URL in modo più flessibile, anche se più complesso, usando XRI (eXtensible Resource Identifier) ed utilizzare YADIS per la specifica degli OpenID provider. (back)

(7) Per chi volesse divertirsi, questo è uno dei tool online che consentono di stimare l’impatto economico del problema. (back)