Per quelle Parti Relying (RP) che consentono all'utente di specificare il provider OpenID (OP), mi sembra di chiunque altro che conosca o indovina il tuo OpenID
L'RP "potrebbe" prendere misure per evitarlo consentendo all'OpenID di essere validato solo dall'OP originale, ma ...
Risposte:
OpenID è uno di quei sistemi in cui devi fidarti degli endpoint. Se l'RP non è affidabile, questo tipo di avvelenamento da associazione è del tutto possibile. Se l'RP è veramente affidabile, questo tipo di attacco è MOLTO più difficile. Il "modo per aggirare" per non essere vulnerabili a questo attacco è la chiave del principio di sicurezza locale (su ServerFault questa sarebbe la rappresentazione del tuo nome utente nel database back-end) con l'endpoint OpenID esterno (l'URL OpenID, ServerFault ti consente di associare multipli di questi).
Puoi ancora attaccare tramite un attacco di avvelenamento DNS da parte del RP, in modo tale che, per esempio, * .livejournal.com venga reindirizzato a un PO appositamente predisposto per l'attacco. Ma questo è un attacco di avvelenamento DNS, non un errore in OpenID stesso. OpenID è solo vulnerabile all'avvio del DNS.
Penso che tu stia confondendo OpenID e le altre parti di User Security. Il tuo OP è il meccanismo di autenticazione, non il tuo account. Qui su ServerFault, hai un account. Tale account non ha alcun mezzo di autenticazione da solo; tranne che lo punti a uno o più PO.
Quando provi ad accedere al tuo account qui come SF, chiede al tuo OP di gestire l'autenticazione. Solo un OP (o più OP, indipendentemente dal fatto che sia stato configurato) può autenticare l'utente ai fini del proprio account SF.
Ci sono tre parti in un tipico sistema di login (chiamato triple "A", o semplicemente "AAA"):
Puoi leggere di più sui sistemi AAA su Wikipedia.
David, il tuo presupposto è falso. OpenID funziona in questo modo: 1) Accedi al sito relyingparty.com 2) Dai a relyingparty.com il tuo OpenID, ad esempio david.com 3) relyingparty.com controlla david.com (ehi, è un URL) per un così chiamato endpoint OpenID che può essere trovato su david.com ma tramite delega anche da qualche altra parte, ad esempio yahoo.com o google.com. chiamiamolo davidsopenidprovider.com 4) Sei reindirizzato a davidsopenidprovider.com ora. Il lavoro di davidsopenidprovider.com è di autenticarti. Devi accedere a davidsopenidprovider.com. Spetta a davidsopenidprovider.com come funziona questo accesso. Può essere nome utente / password, può essere schede informative, certificati del browser, impronte digitali, smart card, meccanismi fuori banda come la verifica delle chiamate, ... Dipende da davidsopenidprovider. com come gestisce l'autenticazione. Quindi chiede se si desidera veramente accedere a relyingparty.com. 5) Se hai effettuato correttamente l'accesso a davidsopenidprovider.com verrai reindirizzato a relyingparty.com e automaticamente effettuato l'accesso lì. 6) davidsopenidprovider.com assicura solo relyingparty.com che sei chi dichiari di essere. Non invia alcuna password.
Quindi la tua ipotesi "Come consumatore, quando creo un account su any-site.com, non ho idea dell'intelligenza degli sviluppatori / dei gestori dei siti". è falso per quanto riguarda OpenID. Se c'è un punto debole, è il provider ma non any-site.com. Questo è il problema con gli accessi tradizionali nome utente / password ora. Devi fidarti di ogni sito che offre accessi in quel modo e non solo uno, il tuo provider OpenID.
Spero che questo aiuti a comprendere OpenID.
Come fai a sapere che lo fanno?
Allo stesso modo in cui sai che qualsiasi vecchio sito trasmette la tua password a qualcun altro - non lo fai. Ecco perché usi quella che potrebbe essere un'azienda stimabile.
Non potresti mai cambiare il tuo OP senza cambiare anche il tuo OpenID.
Certo che puoi. Cerca nella delegazione OpenID.
Il mio OpenID è http://ceejayoz.com/ , ma il mio OP è WordPress.com. Due METAtag nella testa di http://ceejayoz.com/ mi permettono di farlo e posso cambiarlo in qualsiasi momento.
Il tuo openID è il tuo provider. pwnguin.netè il mio openID. Questo non è soggetto a ipotesi, è semplicemente un fatto noto. Ciò che protegge il mio openID è il software in esecuzione su pwnguin.net, che risponde affermativamente solo se il visitatore in questione ha un cookie di autenticazione.
Non dirò che openID sia sicuro; ci sono tutti i tipi di scripting cross site che potrebbero andare avanti, o alcuni dettagli banali che tendo a ignorare o sbagliare.
Questo è ciò che ho raccolto dalle risposte qui ...
OpenID è sicuro solo quanto le parti coinvolte e questo vale per qualsiasi metodo di autenticazione. Mi sono reso conto che prima di iniziare questa discussione.
Il problema con OpenID, come mi sembra è duplice ...
Il tuo ID di accesso non è più un segreto condiviso solo tra te e il sito in cui lo usi. È il tuo OpenID ed è conosciuto da ogni sito su cui lo usi, ed è qualcosa di facilmente indovinabile come un indirizzo e-mail o qualcosa derivato dal tuo indirizzo e-mail o qualcosa di simile.
I RP possono implementare OpenIP sul loro sito senza fare la dovuta diligenza, supponendo che, poiché utilizzano un "protocollo" ampiamente accettato, sia sicuro. Concesso, la maggior parte degli sviluppatori di siti web di punta non ha un vero concetto di come proteggere un sito ma, se implementano la propria sicurezza, almeno il problema n. 1 non entra in gioco.
Come consumatore, quando creo un account su any-site.com, non ho idea dell'intelligenza degli sviluppatori / dei gestori del sito. Uso un ID che non credo possa essere facilmente ipotizzabile. Non voglio che serverfault.com conosca l'ID che utilizzo per accedere a Etrade.com. Uso anche una password diversa su ogni sito e gestisco quelle password con il mio schema. È altamente improbabile che il mio account sia compreso a meno che gli operatori del sito non siano totalmente idioti.
Con OpenID, tutti nel WEB sanno come funziona e come attaccarlo, se l'RP non avesse messo in atto le misure adeguate.
Adoro il software open source, ma nel caso di OpenID penso che si apra la possibilità che ci saranno implementazioni inferiori disponibili per gli ignari utenti.
Penso che tutto ciò potrebbe essere risolto da un sigillo di approvazione firmato che assicura al consumatore che il sito ha superato un audit e non è vendibile agli hack.
Forse sono solo paranoico.