Immagino che non ci sia una soluzione davvero buona per i siti web di tutti i giorni (ad esempio siti non di alto profilo come le banche per i quali gli utenti accettano ed economici consentono un'autenticazione a due fattori). Si può solo scegliere una soluzione che abbia il minor impatto negativo possibile.

Sfortunatamente le persone non sono brave a ricordare un numero enorme di password. Ciò si traduce nel riutilizzo della stessa password su servizi diversi o nella loro scrittura (su carta o un gestore di password). Sì, c'è il consiglio di creare un sistema di password che includa il nome del sito.

Ma le persone sono pigre. Il riutilizzo della password è peggiore di un account centrale perché significa che una vulnerabilità in qualsiasi applicazione rivela la password.

Nel gioco Stendhal la maggior parte degli hack dell'account sono effettuati da membri della famiglia. Immagino che sia speciale per i giochi. Il gruppo successivo è quello di indovinare casualmente nomi utente / password. Tuttavia, esiste un numero limitato di tentativi di hacking basati sull'accesso all ' account di posta elettronica . Sebbene non consentiamo la reimpostazione automatica della password tramite e-mail, molti siti Web lo fanno. Il management superiore di Twitter è stato violato sfruttando un account di posta elettronica Hotmail scaduto e password riutilizzate.

Quindi, se si considera di consentire la reimpostazione della password tramite e-mail, ci sono pochi rischi aggiuntivi nel delegare il processo di autenticazione alle grandi aziende. Tutti dispongono di misure atte a rendere più difficile il compito degli aggressori (ripristino tramite messaggi di telefonia mobile in caso di attività sospetta, cronologia di accesso, avvisi sui tentativi di accesso da altre contee, ecc.). È molto lavoro implementarli nel tuo sito.

Personalmente, avrei preferito l'approccio Account Manager ( specifica ) sulla fiducia in una di quelle società. Inoltre, non ha il problema del phishing. Purtroppo il progetto non sembra fare progressi.

Alla fine abbiamo deciso che Stendhal supportasse sia OpenID che account locali e lasciassimo decidere agli utenti.

Dal punto di vista della sicurezza, disporre di un meccanismo collaudato è quasi sempre meglio che eseguire il proprio. Gli errori di implementazione sono uno dei modi più comuni in cui un buon concetto di sicurezza viene infranto.

Dal punto di vista dell'usabilità preferisco leggermente oauth, è semplicemente facile da usare, quindi per i tuoi utenti finali questo è un enorme vantaggio. Un utente medio non tecnico è scoraggiato dalla sicurezza palese, quindi ridurre al minimo l'intrusione delle funzionalità di sicurezza è una vittoria per i siti con un numero elevato di utenti.

Il rischio di phishing non è in realtà maggiore: le persone non lo fanno. Non prestare comunque attenzione alla fonte delle email :-)

I vantaggi di sistemi come OAuth sono:

• ci sono meno database al mondo che memorizzano le credenziali di accesso di un utente. Considerando un servizio come Twitter, ciò significa che il nome utente e la password sono noti solo a Twitter e non a Favstar, Amazon, LinkedIn, New York Times e a tutte le altre applicazioni che si basano sul servizio.
• come dice @Rory, il sistema è ampiamente utilizzato ed è stato testato e (si spera) protetto in misura adeguata.

Entrambi questi vantaggi riguardano il tuo punto 1: OK, quindi tutto questi servizi utilizzano la stessa password, ma devono comunque farlo perché tutti devono utilizzare il tuo account Twitter, quindi è meglio assicurarsi che queste credenziali "universali" non siano archiviate in una varietà di posti con una varietà di misure di protezione.

Lo svantaggio principale non è diverso dallo svantaggio che interessa tutta l'interfaccia utente di accesso: chiunque può creare un'interfaccia utente di accesso simile a quella e utilizzarla per ottenere le proprie credenziali.

Senza uno scenario specifico e un modello di minaccia in mente, è difficile rispondere alla tua domanda.

Ma una chiara vittoria è il classico caso d'uso OAuth. Si scopre che gli utenti sono incredibilmente disposti a fornire a un sito Web la password per un altro sito Web, ad es. la loro password Google a un sito di social network come Shelfari. E come nota Kalsey, a volte sono rimasti terribilmente sorpresi da quello che Shelfari ha fatto con quella password, e poiché Shelfari poteva impersonarli totalmente, Google non poteva facilmente fermare l'abuso.

Ora, con OAuth, un'app come Shelfari otterrebbe solo un accesso parziale tramite un'API al database dei contatti dell'utente e Shelfari utilizzerebbe una chiave API che Google potrebbe facilmente revocare.

Nel mondo reale, è molto probabile che gli utenti riutilizzino le password su più siti , quindi il tuo attacco in # 1 ha la possibilità di funzionare in molti posti così com'è. In effetti possiamo sperare che gli utenti utilizzino una password migliore per il loro importante sito OpenID, o utilizzino authn a 2 fattori, o qualsiasi altra cosa.

Per quanto riguarda # 2, il punto con gli accessi OpenID è che diventa insolito per imbattersi in un sito che pensa che tu non sia loggato, quando noti che sei loggato in altri tuoi siti web. D'altra parte, è già semplice senza OpenID o OAuth rendere un sito simile a Twitter e collegarsi al sito e sperare di convincere le persone ad accedervi e prendere le loro password. Se le persone sono sempre connesse a Twitter (ad es. Per altri siti tramite OAuth o OpenID), è probabile che chiedano perché non hanno già effettuato l'accesso.

Ha scritto questo sull'ID federato.

Fondamentalmente stai parlando del problema del rischio centralizzato o delle chiavi del regno. Questo vale anche per i gestori di password, ma proteggere un numero limitato di sistemi di identità e autenticazione è molto più semplice ed efficace che avere centinaia di password deboli (o la stessa password debole cento volte). I fornitori di Open ID come Google ora offrono l'autenticazione a due fattori; se non ti piace un soft token sul tuo telefono, i token hardware USB di Yubikey sono supportati anche da molti provider Open-ID. Anche il controllo e l'audit sono notevolmente migliorati; conosci tutte le applicazioni in cui hai utilizzato una password? Neanche io. Eppure molti fornitori di Open-ID hanno tutti i siti in cui hai concesso l'accesso a quell'identità, revocare l'accesso è un processo con un clic

Dal punto di vista aziendale, utilizzando qualcosa come Facebook oAuth fornirà l'accesso a tutti quei dati sociali , analisi e maggiori possibilità di diventare virali. Aggiungi che è più veloce ed economico che pagare un programmatore per sviluppare una funzione di autenticazione utilizzando una qualche forma di autenticazione federata mi sembra un gioco da ragazzi.

Uso Google per il mio account OpenID. Quasi tutti i siti Web che non utilizzano OpenID mi consentono di reimpostare la password tramite e-mail, quindi se qualcuno avesse la password del mio account Gmail, sarei comunque fregato.

Avere 1 password memorizzata in 1000 server è meno sicuro di 1 password memorizzata in 1 server che autentica 999 server è meno sicura di 1000 password per 1000 server .

Tuttavia quest'ultimo non è pratico, le persone non sono in grado di ricordare 1000 password per 1000 server, l'unico modo per farlo è usare i gestori di password. E dove si trova il gestore di password?

Avere 1 password memorizzata utilizzando la crittografia unidirezionale in 1000 server è meno sicuro di 1 password principale per un gestore di password che ne memorizza 1000 password in chiaro o crittografia a 2 vie per 1000 server è meno sicura di 1 password memorizzata in crittografia a 1 via in 1 server che autentica 999 server è meno sicura di 1000 password archiviati utilizzando la crittografia unidirezionale in 1000 server .

Pertanto OAuth / OpenID possono essere più sicuri, convenienti e pratici. L'utilizzo di 1000 password senza un gestore di password non è pratico e l'utilizzo di gestore di password è meno sicuro poiché tali password dovrebbero essere archiviate in testo normale o utilizzando la crittografia a 2 vie.

Un modo in cui OAuth e OpenID migliorano la sicurezza è che ti obbligano a digitare la password meno spesso. Il collegamento di un nuovo account a OAuth / OpenID è solo il mio reindirizzamento al provider di identità e poiché sono già connesso al provider di identità tutto il tempo, fornisce semplicemente un prompt Sì / No invece di un prompt della password. Nessuna password viaggia durante questo scambio.

Questo ti rende più consapevole se ti viene effettivamente chiesta la password invece di passare semplicemente attraverso.

Quindi # 2 non è davvero un problema.

# 2 è assolutamente vero ma non principalmente un problema di ID federale, solo che in questo caso è ancora più critico.

Hai problemi simili con tutti i moduli di accesso incorporato in contenuti (effettivamente) non attendibili, soprattutto perché l'autenticazione utilizzata è la più insicura (il segreto viene semplicemente trasmesso dal browser e, se sei fortunato, il server mette SSL sotto per tua comodità ..).

Occorrono due cose per correggere questo e la maggior parte degli altri attacchi di phishing:

• interfaccia sicura per l'autenticazione dell'utente, ad es. finestra di dialogo a discesa dalla barra degli URL e NON fa parte del contenuto del server.

• protocollo di autenticazione implementato in modo nativo (non dal contenuto del server, come JavaScript) che non rivelerà il segreto a un utente potenzialmente dannoso server (ad esempio, SRP)

A proposito, ho implementato SRP per NSS diversi anni fa e altri hanno persino implementato estensioni GUI. A meno che le Smartcard non diventino onnipresenti, questa è la strada da percorrere: http://trustedhttp.org/wiki/TLS-SRP_in_NSS

Gli esseri umani vogliono sempre trasferire le proprie responsabilità dalle proprie spalle (non tutti). La sicurezza è una grande responsabilità e la maggior parte delle aziende desidera concentrarsi sul core business e offrire ai propri clienti il ​​meglio del proprio prodotto piuttosto che preoccuparsi della sicurezza.

Il single point of failure è sicuramente qualcosa di cui preoccuparsi dal punto di vista della sicurezza, ma le persone vogliono fidarsi delle grandi aziende perché hanno ottenuto enormi soldi e con i soldi arrivano buoni ingegneri della sicurezza (non esattamente ma Yeah! ). Buoni ingegneri significa buone pratiche di sicurezza. Inoltre non mostreranno le spalle alle persone (si spera!).

Il phishing è sicuramente un grosso problema e la comunità della sicurezza ha lavorato su questo problema per un po 'di tempo ormai. Come menzionato da @Rakkhi, soluzioni recenti come Yubikey, Fido U2F per risolvere il problema del phishing potrebbero aiutare a rafforzare la sicurezza.

L'unica cosa che possiamo sperare è un nuovo cambiamento di design in cui le persone non devono scegliere le loro password e inserirle pur essendo in grado di autenticarle in modo sicuro.