OpenID: le mie (grosse) perplessità
8 Febbraio 2008 - di Marco Cattaneo
Alla vigilia della pertenza per un weekend meneghino (nel quale, come di consueto, cercherò di rivedere qualche amico e fare il punto su un paio di idee), mi ritrovo con un tema che mi sta particolarmente a cuore - ovvero i meccanismi di autenticazione centralizzata - sul quale vorrei spendere due parole.
Notizia di ieri: Microsoft, Google, Verisign e IBM entrano a far parte della corporate board del progetto OpenID e dimostrano, evidentemente, il loro interesse per la nota tecnologia di autenticazione centralizzata decentralizzata (attenzione: non é un ossimoro, capirete meglio in seguito). Sebbene l’utente finale possa essere rallegrato dal successo della suddetta tecnologia e illuso dalla vana speranza di non dover ricordare migliaia di password, rimangono proprie di OpenID alcune criticità e un colossale paradosso che non riesco a togliermi dalla testa.
Punto uno. OpenID nasce con la finalità di centralizzare su un unico provider la pratiche di autenticazione sui propri account sparsi per il web, delegando ad esso la verifica delle proprie credenziali di accesso (tipicamente username e password). Poiché ogni azienda facente parte della corporate board del progetto può diventare provider di autenticazione OpenID, l’utente dovrà scegliere a quale di essi affidare il proprio account unico. Visto che ognuno di loro possiede già un proprio database di milioni di utenti (che nel frattempo saranno stati convertiti in OpenID), non sarà realmente possibile avere una sola identità, ma si finirà per doverne attivare una per ogni OpenID provider (poiché nessuno consentirà di accedere ai propri servizi “interni” loggandosi con OpenID fornita da altri provider). Siamo certi che, a questo punto, non fosse meglio un sistema centralizzato (ovvero basato su un solo provider di credenziali) indipendente e opportunamente “monitorato” da un ICANN della situazione?
Punto due. OpenID si presta a centralizzare, oltre che i meccanismi di autenticazione, anche la fiducia degli utenti (e quindi i rischi di trappole phishing e di furto d’identità!). Quali strumenti addizionali vengono forniti agli utenti per verificare la reale identità del sito dell’OpenID provider presso il quale tenteranno di inserire la propria username/password combination? Ve lo dico io: nessuno, oltre alla verifica visuale dell’URL nella barra dell’indirizzo!
OpenID, infine, non dispone di meccanismi centralizzati per la revoca degli account delle relying party (ovvero dei siti che lo sfruttano per semplificare l’accesso ai propri utenti), funzionalità che sarebbe stata davvero utile, se presente!
Concludo invitando chiunque utilizzi OpenID ad approfondirne i criteri che ne regolano il funzionamento, per fare in modo che la pura illusione di semplificare la propria vita online non si tramuti semplicemente in nuovi rischi per la propria sicurezza.
Premetto che non sono un tecnico e quindi potrei dire tranquillamente delle castronerie, ma (approvando le tue giuste perplessità) non sarebbe meglio che fosse una autorità pubblica (intendo proprio una Pubblica Amministrazione) a gestire un sistema centralizzato di autenticazione? Tra l’altro per gli enti pubblici questo sistema sicuro esiste (esisterebbe) già: la carta di identità elettronica, che diventerà obbligatoria nell’ interazione online con la PA a partire dal 31/12/2008: è un sistema sicuro e universale di accesso. Un problema non da poco è che per poterla usare è necessario un lettore di smartcard per ma se divenrasse uno standard i costruttori potrebbero adeguarsi facilmente.
Personalmente non sono d’accordo e ti invito a rivedere meglio come funziona il protocollo:
punto uno: è prerogativa del protocollo la scelta ed il controllo da parte dell’utente della doppietta URL/autenticatore, dunque se un operarore aderisce ad OpenID deve rispettare questo punto, sennò cuol dire che non sta implementando OpenID ma qualcos’altro…senza contare che questo discorso vale anche al contrario, ossia si possono “perdere” gli utenti ma se ne possono anche “guadagnare”…se c’è una cosa che il Web2.0 ha insegnato è proprio che che più di condivide più di guadagna, per cui perchè non condividere anche gli utenti?
punto due: il phishing è un rischio come in tante altre situazioni e ci sono soluzioni per aggirarlo…inoltre, se qualcuno si impossessa della tua casella di mail non può forse accedere a tutti i login ad essa associati?
In quanto alla revoca dell’account, se invece di usare un account Open ID “embedded”, come quello di Technorati per intenderci, usi un Open ID URL su un dominio (blog o sito) di cui hai il controllo questo problema non si pone proprio ed è la soluzione che probabilmente prenderà piede…
Rispondendo a Mauro: il fatto che un servizio sia pubblico non dà alcuna garanzia in più…vedi il caso del fisco britannico che si è perso i dati di mezza nazione…
Open ID come tecnologia ti dà un garanzia non da poco: se un Open ID provider ti dà qualche motivo di perplessità cambi in pochi secondi ed i servizi a cui sei iscritto non se ne accorgono nemmeno…
Ciao Cosimo, rispondo con ordine:
1) mi era chiarissima questa prerogativa del protocollo, ma ciò non toglie che si tratti di un meccanismo che agevoli la creazione di “più centri indipendenti”, piuttosto che più centri “interconnessi e compatibili fra loro” (a causa della miopia dei provider!). E’ piuttosto evidente che nessun grande player abbia reale interesse (o intenzione) di condividere i propri utenti, ma sono d’accordo che dovrebbero.
2) sto dicendo semplicemente che era una buona occasione per prevenirlo! Sarebbe stato sufficiente supportare un meccanismo di controllo che mostrasse all’utente una frase da lui predeterminata prima di chiedergli l’inserimento di login e password. Sarebbe una contromisura utile per evitare che il redirect verso un sito esterno possa essere sfruttato impropriamente.
3) io parlavo di una revoca selettiva, non globale (!), del proprio account!
mi dispiace ma non sono d’accordo.
1) stiamo parlando di security, quindi, consentire che i db degli utenti dei provider siano interconnessi è fonte di debolezza non di forza. In una ipotesi di questo tipo, se uno dei server dei “federati” è vulnerabile per carenze del gestore, diventa possibile punto di attacco per tutto il sistema. Con un sistema in cui invece si condivide il protocollo, ma non il db, se il tuo fornitore (il tuo sevrer autenticatore) si dimostra inaffidabile o semplicemente non ti fidi più, lo cambi in quattro e quattr’otto e fine della storia…
2) la soluzione che proponi non è sbagliata ma non è comunque una garanzia di sicurezza ed in ogni caso, OpenID non esclude nulla a proposito delle modalità con cui l’utente si autentica presso il suo provider…per cui volendo si possono implementare anche logiche basate su generazione di chiavi usa e getta etc…vedo a questo proposito il profilarsi di un mercato dei provider con differenti livelli di servizio e sicurezza, proteggere un blog non è la stessa cosa che proteggere una casella email od un conto corrente…
il phishing in ogni caso è una piaga con la quale sarà meglio imparare a convivere e per la quale non sarà facile trovare una soluzione definitiva, un po’ come lo spamming…
3)nel momento in cui cambi la dichiarazione del tuo provider, l’altro account è di fatto disaccoppiato ed inutilizzabile…se proprio si desidera cancellarlo, non è escluso che ciascun provider non possa predisporre delle procedure per consentirne la rimozione, a patto di autenticare a sua volta il richiedente…
In effetti sul primo punto anch’io non riesco a capire dove sia il problema, se un sito supporta OpenID *deve* farti loggare anche se il tuo provider OpenID non e’ il sito stesso, giusto?
Flux, ti faccio un esempio concreto: sia Yahoo! che Microsoft sono provider OpenID. Io utente utilizzo un account Yahoo! come OpenID e mi loggo su servizi di terze parti con questo account. Esso non mi consentirà di loggarmi sui servizi di Microsoft, poiché Microsoft è provider OpenID e non supporta l’autenticazione con OpenID forniti da altri provider. Tutto chiaro?
Certo Flux,
il punto di Forza di OpenID è proprio questo: distribuire l’autenticazione. E bada che limitare da parte di un sito l’autenticazione solo agli account che risiedono su “sé stesso” è un controsenso…un sito non ci guadagna nulla dall’ospitare o no l’account di un utente; tanto dal punto di vista del servizio, quello è un suo utente comunque!!! Detesto essere autoreferenziale, ma consiglio a chi vuole di leggere il mio articolo scritto per Idearium.org…
Sono d’accordo che sia un controsenso, ma tant’é… che é così!
Marco, nel caso che ipotizzi MS non consentirebbe l’autenticazione basata sullo standard openid ma l’autenticazione basata su una sua versione del protocollo; quella che fai tu e’ un’ipotesi o ci sono gia’ casi di questo tipo?
Ah ah ah..
Flux, non é un’ipotesi, é la comune realtà della maggior parte dei provider!!
Marco ma fammi un esempio concreto allora, MS non e’ ancora ufficialmente un provider OpenID no?
MS non lo é ancora, in effetti, ma qualunque altra coppia di provider non si supporta a vicenza (esempio Yahoo! e ClaimID)
Il problema che cita Marco tra Yahoo! e ClaimID è dovuto al fatto che il primo supporta solo la nuova versione del protocollo (OpenID 2.0), mentre ClaimID supporta la 1.0 . Inoltre, non sono da escludersi problemi di implementazione da parte di alcuni provider vista la novità della tecnologia, ma questo non significa che lo facciano di proposito…anche perchè sennò, non capisco a che servirebbe aderire, visto che il vantaggio di OpenID è l’account unico (senza di questo sarebbe anzi scomodo), se un provider volesse risolvere questo problema solo per il proprio circuito di siti, non sarebbe necessario ricorrervi…sia Yahoo! che Google avevano già peraltro delle soluzioni a questo proposito…inoltre, il problema andrebbe visto al contrario: ci sono ricerche che dimostrano quanto tutti i fornitori di servizi online di qualunque genere perdano clienti a causa delle maschere di adesione noiose e della ritrosia degli utenti a lasciare anche solo l’email…con OpenID questo problema in parte sarebbe risolto, per cui paradossalmente un provider potrebbe guadagnarne di utenti più che perderne…
Cosimo, abbi pazienza, la situazione é talmente chiara ed evidente che sostenere a spada tratta il protocollo per partito preso mi sembra quantomeno miope!
Non esiste, a mia conoscenza, un provider OpenID che accetti OpenID altrui! Segnalamene uno - di mediamente famoso - se lo conosci, perché mi sentirei rincuorato!
Che, in linea di massima, sia controproducente non accettare utenti di db altrui é chiaro, ma non mi dire che non comprendi perché colossi come MS o Yahoo! lo facciano e non pretendere che sia solo una “svista”!
Se mediamente un utente fatica a compilare un nuovo form, si ritroverà a doverlo fare se desidera aderire a servizi gratuiti e rinomati dei quali non vuole fare a meno. Il problema non si pone.
Caro Marco,
scusa, ma di miopi mi pare che qui ci sia solo tu.
Per un serie di ragioni elementari.
Intanto mi dovresti spiegare perchè aderire ad uno standard che ha lo scopo di unificare l’autenticazione se poi non la si unifica…perchè, ripeto, se implementi OpenID senza questa possibilità sono più i problemi che i vantaggi, e Microsoft & C. saranno tutto tranne che stupidi…poi io non sostengo a spada tratta un protocollo, ho risposto tecnicamente ad alcune maldestre osservazioni che hai fatto sul piano tecnico…se OpenID vincerà o no, o salteranno fuori protocolli migliori lo sapremo tra non molto…quello che sostieni tu e che a mio parere è insostenibile, anche se tu facessi parte del board di Microsoft, è l’inapplicabilità di un modello economico che invece fino ad oggi ha vinto nonostante tutti i veggenti con la sfera di cristallo…forse sei troppo giovane per ricordarlo, ma mi ricordo come se fosse ieri di quelli che dicevano che:
1) dell’web su internet non ci sarebbe stato alcun bisogno (ebbe sì io sono stato un utente di Internet quando il web non esisteva ancora !!)
2) che l’HTML 1.0 di Mosaic era più che sufficiente e nessuno avrebbe mai avuto bisogno di Netscape
3) di quelli che dicevano che Internet gratis sarebbe durata poco e che era un modello economico insostenibile, per cui a breve sarebbe stato tutto a pagamento (e stanno ancora aspettando)
4) di quelli che dicevano che il modello Open Source non sarebbe durato molto, che i costi sarebbero stati insostenibili, mentre mi risulta ci siano realtà economiche più che floride che l’hanno sposato
e potrei andare avanti citando le maximail gratis, la musica online e via così…mi sbaglierò, ma la morale che ne ho tratto è che gli apparenti interessi specifici di seppur grandi compagnie come Microsoft o Yahoo! o altre ancora, si trasformano a favore di modelli economici nuovi e più vantaggiosi per l’utenza e non in nome di ragioni etiche, ma soprattutto perchè sono proprio loro a trarne alla fine il maggior vantaggio…
Il fatto che ci sia un periodo di transizione in cui non tutto funziona è normale…per non andare troppo indietro, basta vedere a che punto siamo con l’adesione di Microsoft Live Search e Yahoo! al protocollo SiteMap di Google: se il secondo ha risposto prontamente, Live Search è ancora lì a metà che non consente il ping, come sono in ritardo con decine di altre cose…è solo una questione di priorità e di pianificazione…e non mi venire a dire che MS sta sabotando dall’interno il protocollo !!!
Per cui, se forse non scommetterei ancora su OpenID come tecnologia vincente per unificare l’autenticazione, di sicuro scommetto sul fatto che prima o poi a questo si giungerà, perchè ce n’è bisogno e conviene a tutti.
E con questo, dal mio punto di vista il discorso si chiude, a meno che non ci siano argomenti diversi e consistenti sui quali confrontarmi.
ciao
Cosimo
Rispetto la tua opinione, Cosimo, anche se non la condivido. Mi piacerebbe giocarmi una birra sul fatto che OpenID naufragherà come molti altri tentativi precedenti, in pochi anni, proprio per le lacune che presenta (il protocollo o le sue implementazioni). Staremo a vedere..
Punto due. OpenID si presta a centralizzare, oltre che i meccanismi di autenticazione, anche la fiducia degli utenti (e quindi i rischi di trappole phishing e di furto d’identità!). Quali strumenti addizionali vengono forniti agli utenti per verificare la reale identità del sito dell’OpenID provider presso il quale tenteranno di inserire la propria username/password combination? Ve lo dico io: nessuno, oltre alla verifica visuale dell’URL nella barra dell’indirizzo!
—-
Yahoo mette un sigillo, ovvero un immagine e un testo.
Concordo molto con la perplessità numero 1.
Io attendo la versione 2.
saluti
Siamo in due che scommettiamo per la stessa birra ;)
googlesystem.blogspot.com/2008/05/spreading-opensocial-across-web.html
ragazzi, mettete in fresco le birre… ;)
ciao
Cosimo
@monte: il bello è che openid è un protocollo “aperto”. Puoi crearti un tuo provider con poche righe di html/php che abbia un testo identificativo per ogni utente o un sigillo, ma con i moderni sistemi di phishing js questo cambierà poco (l’eventuale sito “truffa” prima arriverà alla pagina di login del tuo provider, la ricopierà pari-pari, e te la mostrerà in un sito fasullo (compresti sigilli ecc.). Dimentichi che il provider si può autenticare con un certificato SSL (così, oltre al sito scritto nella bara, che non è poco, avrai pure la garanzia che il sito sia veramente quello, nei rari casi di avvelenamento DNS).
I rischi con OpenID sono gli stessi che con qualsiasi sistema di autenticazione standard.