Non sono OAuth, OpenID, Facebook Connect e altri pazzi da un punto di vista della sicurezza?

Suppongo che non ci sia una soluzione davvero valida per i siti web di sempre (ad esempio siti non di alto profilo come banche per le 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ò comporta il riutilizzo della stessa password su servizi diversi o la loro scrittura (su carta o un gestore di password). Sì, esiste il consiglio per creare un sistema di password che includa il nome del sito.

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

Nel gioco Stendhal la maggior parte degli hack degli account viene eseguita da membri della famiglia. Immagino sia speciale per i giochi. Il prossimo gruppo è una supposizione casuale di nomi utente / password. Tuttavia, esiste un numero limitato di tentativi di hacking basati sull'accesso all'account e-mail . Sebbene non consentiamo il reset automatico della password tramite e-mail, molti siti Web lo fanno. La gestione superiore di Twitter è stata violata sfruttando un account email Hotmail scaduto e riutilizzato le password.

Quindi, se si considera di consentire il reset della password via e-mail, vi è un piccolo rischio aggiuntivo nel delegare il processo di autenticazione alle grandi aziende. Tutti hanno misure per rendere più difficile per gli aggressori (recupero tramite messaggi di telefonia mobile in caso di attività sospette, cronologia di accesso, avvisi sui tentativi di accesso di altre contee, ecc.). È molto lavoro implementare quelli nel tuo sito.

A titolo personale, avrei preferito l'approccio Account Manager ( specifica ) sulla fiducia in una di queste aziende. Inoltre, non ha il problema di phishing. Sfortunatamente il progetto non sembra fare progressi.

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

Da un punto di vista della sicurezza, avere un meccanismo collaudato è quasi sempre meglio del tuo. Gli errori di implementazione sono uno dei modi più comuni in cui un buon concetto di sicurezza si rompe.

Da una prospettiva di usabilità preferisco leggermente oauth, è solo facile da usare, quindi per i tuoi utenti finali è un enorme vantaggio. Un utente medio non tecnico è messo fuori da una 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à più grande - la gente non presta comunque attenzione alla fonte delle email: -)

I vantaggi di sistemi come OAuth sono:

• ci sono meno database nel mondo che memorizzano le credenziali di accesso dell'utente. Considerando un servizio come Twitter, questo significa che il nome utente e la password sono noti solo a Twitter e non a Favstar, Amazon, LinkedIn, New York Times e 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 tutti questi servizi usano la stessa password, ma devono comunque perché tutti hanno bisogno di usare il tuo account Twitter, quindi è meglio assicurarsi che queste credenziali "universali" non siano memorizzato in una varietà di luoghi con una varietà di misure di protezione.

Lo svantaggio principale non è diverso dallo svantaggio che interessa l'intera interfaccia utente di accesso: chiunque può creare un'interfaccia utente di accesso simile a quella e utilizzarla per ottenere le 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 . Risulta che gli utenti sono sorprendentemente disposti a fornire a un sito Web la propria password per un altro sito Web, ad es. la loro password Google su un sito di social networking come Shelfari. E come nota Kalsey, a volte erano orribilmente sorpresi di ciò che Shelfari ha fatto con quella password, e dal momento che Shelfari poteva totalmente impersonarle, Google non poteva facilmente fermare l'abuso.

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

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

Per quanto riguarda il n. 2, il punto con gli accessi OpenID è che diventa insolito imbattersi in un sito che pensa di non essere loggato quando si nota di aver effettuato l'accesso negli altri siti Web. D'altra parte, è già semplice senza OpenID o OAuth creare un sito simile a Twitter e collegarsi al sito e sperare di convincere la gente ad accedere ad esso e ad afferrare le loro password. Se gli utenti sono sempre connessi a Twitter (ad esempio per altri siti tramite OAuth o OpenID), probabilmente chiederanno perché non hanno già effettuato l'accesso.

Ho scritto questo sull'ID federato.

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

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

Uso Google per il mio account OpenID. Quasi tutti i siti web che non utilizzano OpenID mi consentono di reimpostare la password via email, quindi se qualcuno ha ottenuto la password per il mio account Gmail, sarei comunque fregato.

Avere 1 password stored in 1000 servers è meno sicuro di 1 password stored in 1 server which authenticates 999 servers è meno sicuro di 1000 password for 1000 servers .

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

Avere 1 password stored using 1-way encryption in 1000 servers è meno sicuro di 1 master password for a password manager which stores 1000 passwords in cleartext or 2-way encryption for 1000 servers è meno sicuro di 1 password stored in 1-way encryption in 1 server which authenticates 999 servers è meno sicuro di 1000 password stored using 1-way encryption in 1000 servers .

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

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

Hai problemi simili con i tutti moduli di accesso incorporati nel contenuto (effettivamente) non affidabile, specialmente perché l'autenticazione utilizzata è la più insicura (il segreto viene semplicemente trasmesso dal browser e se sei fortunato il server mette SSL sotto per la vostra convenienza ..).

Hai bisogno di due cose per risolvere questo e molti altri attacchi di phishing:

• interfaccia sicura per l'autenticazione dell'utente, ad es. finestra di dialogo a discesa dalla barra dell'URL e NON 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 server potenzialmente dannoso (ad esempio, SRP)

BTW, ho implementato SRP per NSS diversi anni fa e altri hanno persino implementato estensioni GUI. A meno che le smart card non diventino onnipresenti, questa è la strada da percorrere: link

Un modo in cui OAuth e OpenID migliorano la sicurezza è che ti obbliga a digitare la tua 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à per tutto il tempo, viene semplicemente fornito un prompt Sì / No anziché una richiesta di password. Nessun passaggio di password in questo scambio.

Questo ti rende più consapevole se in realtà ti viene richiesta la password anziché solo il passaggio.

Quindi # 2 non è davvero un problema.

Gli umani vogliono sempre trasferire le loro responsabilità dalle loro 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.

Un singolo punto di errore è sicuramente qualcosa di cui preoccuparsi dal punto di vista della sicurezza, ma le persone vogliono avere fiducia nelle grandi aziende perché hanno un sacco di soldi e con i soldi arrivano ingegneri di sicurezza (non esattamente, ma sì!). I bravi ingegneri indicano buone pratiche di sicurezza. Inoltre non mostreranno le loro spalle alle persone (si spera!).

Il phishing è sicuramente un problema enorme e la comunità di sicurezza ha lavorato a questo problema da un po 'di tempo. Come accennato 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 design in cui le persone non debbano scegliere le loro password e inserirle pur essendo in grado di autenticarle in modo sicuro.