In che modo l'utilizzo di OpenID influisce sulla sicurezza webapp?

Penso che abbia senso firmare offrire tramite OpenId, ma non richiederlo , anche per i siti di e-commerce.
La ragione di ciò è che gli utenti esperti di tecnologia (ancora la base utente principale per openid) possono decidere se assumersi tale rischio, oppure no.

I siti che non consiglierei di utilizzare OpenId, sono siti altamente sensibili, ad es. siti bancari o sistemi privati / aziendali in cui si desidera anche il controllo delle identità degli utenti (ala Identità centrata sull'azienda, anziché Identità centrata sull'utente).

C'è un chiaro vantaggio nell'usare OpenId, dal momento che non devi gestire le identità degli utenti, incluse password, reimpostazione, sicurezza, ecc. e accettare il rischio che comporta.

Ogni provider OpenID ha un compromesso tra funzionalità di sicurezza e svantaggi. Ad esempio:

Caratteristiche

• Google, Facebook, MyOpenID e Verisign offrono tutti diversi gradi di supporto per due fattori. (Verisign è l'IMHO più sicuro)

• Tutti supportano operazione Javascript gratuita (per utenti paranoici di sicurezza)

• Privacy e anonimato potenziato con MyOpenID e LiveID (non molti altri però)

• Criterio di modifica della password

• Signin Seal (Yahoo, ADFSv2)

Difetti

• Molti siti non offrono la stessa sicurezza di intestazione HTTP come documentato qui . Ciò significa che alcuni siti sono più vulnerabili a MITM, FireSheep, replay di token o Clickjacking rispetto ad altri siti.

• Non c'è davvero alcuna coerenza tra i vari siti.

E questo è solo l'inizio. Ho un post più dettagliato con molti collegamenti ipertestuali preziosi qui . Lì, sto confrontando tutte le funzionalità di sicurezza dei principali provider OpenID e richiedendo alla community qualsiasi altra funzionalità o IDP che dovremmo prendere in considerazione.

Se scopri un IDP con funzionalità di sicurezza non elencate, incoraggerò chiunque a postare lì.

Is it suitable for any kind of webapp?

Direi che Verisign sarebbe un nome affidabile per gli scenari di maggiore sicurezza, supponendo che l'utente finale abbia optato per tutti i campanelli e i fischi. Non sono un fan della configurazione di le intestazioni HTTP (collegamento ripetuto). Assicurati che il tuo relying party (sito web) si protegga dai cookie riprodotti dall'RP e dalle sessioni precedenti.

Se stai usando Windows / IIS come parte relying, posso inviare più informazioni per proteggerti dagli scenari che ho menzionato nel paragrafo precedente.

Ricerca aggiuntiva

Microsoft ha una dettagliata whitepaper dei problemi di sicurezza di OpenID qui . Ho inviato un'email agli autori e hanno rilasciato un analizzatore al link lo strumento di analisi è disponibile qui: link

Non penso che sia una buona idea usare openid per il sito di e-commerce, ma va bene per i siti web di social networking e i siti di informazione.

I motivi sono:

• Non sai quanto è sicuro il provider.
 -

Non userei OpenID per nulla per il semplice motivo che non conosco abbastanza bene il funzionamento interno di esso. In generale però direi questo;

esternalizzando la tua gestione degli accessi ti stai preparando per una caduta in caso dovesse accadere qualcosa con uno dei principali fornitori.

Diciamo per esempio che google decide di iniziare a essere malvagio e vende le password dell'utente a una terza parte, che terze parti accedono al tuo sito e fanno cose per conto degli utenti.

L'utente non si arrabbierà con Google, sarà incazzato con te.

E mentre in questa situazione estrema hai delle leggi dietro di te, non so se avresti un caso se le tue informazioni utente sono trapelate in altre forme.