Domanda:
OAuth, OpenID, Facebook Connect e altri non sono pazzi dal punto di vista della sicurezza?
Oscar Godson
2011-05-22 11:18:41 UTC
view on stackexchange narkive permalink

Lavoro sempre con le API e lavoro con sviluppatori web che insistono sul fatto che OAuth, OpenID, ecc. sono di gran lunga superiori a un metodo casalingo. Ogni sito sembra utilizzare anche questi ora per facilità d'uso per l'utente, ma anche per sicurezza. Lo sento quasi ogni giorno che è più sicuro, ma trovo che sia estremamente difficile da credere per alcuni motivi:

  1. Se un hacker in qualche modo ottiene la tua password su un sito, lo sa ha accesso alla maggior parte dei siti che visiti adesso.

  2. Rende il phishing 10 volte più facile. Con così tante persone che usano gli stessi accessi e lo fanno più e più volte, è meno probabile che le persone leggano effettivamente tutto e controllino l'URL in alto.

Potresti elencare più motivi per cui non è sicuro o potresti spiegarmi perché è più sicuro? Non vedo perché dovresti sopportare il fastidio di integrare uno di questi quando sembra che un utente stia bene inserendo in 3 campi (nome utente, password, e-mail) invece di fare clic sul logo del servizio per accedere (Twitter, Google, FB ecc.), Inserendo il proprio nome utente / password, facendo clic su Invia, quindi su Approva.

== Aggiorna ==

Per espandere la mia domanda come da richiesta.

Ai miei due punti precedenti, # 1 , non importa come l'ha capito l'hacker. Non sono sicuro di come espanderlo esattamente. Potresti forzarlo, indovinarlo, usare la password dimenticata e fare un attacco al dizionario su domande comuni, ecc. Ma comunque lo fai, il mio punto è che 1 password per accedere a 1000 server è molto meno sicura di 1000 password per accedere a 1000 siti diversi. Posso personalmente indovinare alcune delle password dei miei amici e familiari e non ho accesso a tutti i tipi di account. Non dovrei nemmeno cercarli. Mentre navighi sul web mi sono appena loggato ... Se fossi un hacker, molte di queste password sono molto facili da decifrare. Alcune delle password del mio amico sono pepsi , tina (quindi anno di nascita), 123456 e altre stupide. Il mio preferito però è tomcruisesucks LOL.

Per il punto # 2 , per espandere ulteriormente, potrei andare a http: // wired. com, http://klout.com, http://twitter.com, http://thenextweb.com e hanno tutti un accesso a Twitter. Mi fido dei siti (per la maggior parte) quindi, onestamente, non controllo più l'URL della finestra popup che si apre per accedere e presumo che la maggior parte non lo faccia. Quella finestra pop-up potrebbe essere stata facilmente hackerata da un hacker che entrava in uno dei loro server, o da un impiegato malvagio, o semplicemente da un sito di app fasullo che un bot sta inviando a persone su Twitter che più persone accedono a questa app fasulla, ma usando l'accesso a Twitter.

Le persone sono così abituate a vedere le stesse pagine di accesso che non guardano più . Se questo thread diventa abbastanza popolare, posso facilmente fare un test semplicissimo su Twitter o FB inviando a tutti un collegamento a un'app falsa, avere una finestra popup che assomiglia a Twitter o FB e faranno il login. Lo garantisco. Se faccio andare la schermata di accesso a, diciamo, http://bankofamerica.com o http://paypal.com si chiederanno perché sono qui , perché hanno bisogno di queste informazioni, ecc. Gli stessi siti utilizzati per accedere più e più volte sono estremamente pessimi nella pratica.

Questo è il mio punto di discussione più ampio;)

Hai fiutato i diversi schemi di autenticazione? Che aspetto ha sul filo? Conosciamo il protocollo? Cosa passa da e verso il server, una cosa.
@marcin - openid e oauth sono standard molto aperti e relativamente ben controllati, con specifiche, pagine di wikipedia ecc. YMMV con Facebook Connect ....
È difficile rispondere a questa domanda perché ci sono molti aspetti diversi. Innanzitutto, non chiarisci esattamente quale alternativa hai in mente a oauth. Qual è la nostra applicazione? In secondo luogo, Facebook Connect è presumibilmente proprietario, e quindi in una lega molto diversa da oauth e openid. E terzo, il tuo commento sui problemi di phishing derivanti dall'uso di link sui muri di Facebook delle persone è un argomento completamente diverso. Suggerisco di modificare le parti di collegamento di Facebook e di collegamento di Facebook qui e di porre domande separate su quelle, se lo desideri.
@nealmcb Perché non dovresti usare un metodo homebrew o semplicemente controllare i cookie. I.E. l'utente accede al servizio, quindi ha accesso API. questo potrebbe essere fatto facilmente con un iframe o un modulo POST. Tutti i servizi open source o meno hanno gli stessi difetti e questo è quello che dico. collegano tutti i tuoi account con un'unica password. Ancora una volta, per il tuo terzo punto, questo è _esattamente_ lo stesso per Ouath, o davvero, QUALSIASI sito, ma è peggio quando i siti di grandi dimensioni contengono la tua password perché le persone non controllano l'URL. Penso che ti manchino i miei 2 punti numerati ...
La maggior parte delle persone non legge i commenti, quindi sarebbe utile poter modificare la domanda in uno specifico scenario di attacco. Quale risorsa stai proteggendo, da quali minacce, ecc. Vedi le faq. Quindi possiamo discuterne nelle risposte.
Fatto! Ho ampliato i due punti
Grazie. Devo dire che non è ancora chiaro quale sia la tua domanda: quale problema stai cercando di risolvere, da quale prospettiva. Stai decidendo se utilizzare queste tecnologie in un'app tutta tua? Se utilizzare un openid o un login personalizzato per un determinato sito? Possiamo aspettarci di essere d'accordo su quale risposta è giusta? Dovremmo essere in grado di - vedere le faq e notare che questo sito non è per "discussioni".
Sono un utente di lunga data (quasi 2 anni) di StackOverflow, conosco le regole :) e sì, ci sarà una risposta giusta. In breve, una domanda di una frase, questi metodi di autenticazione sono effettivamente più sicuri di avere il proprio sistema di accesso? Altre persone di seguito sembrano capire quindi non sono sicuro di come espandere: \ La risposta "giusta" è una spiegazione di sì è più sicura e perché o no non è e perché mi piace / capisco / risposta più prolissa.
Google supporta u2f, che rende il phishing 1000 volte più difficile.
Dieci risposte:
#1
+23
Hendrik Brummermann
2011-05-22 13:59:10 UTC
view on stackexchange narkive permalink

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.

Google ha l'autenticazione a due fattori.
#2
+17
Rory Alsop
2011-05-22 13:46:39 UTC
view on stackexchange narkive permalink

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 :-)

Questo è vero per il phishing tramite posta elettronica, tranne per il fatto che la maggior parte dei provider di posta elettronica (Yahoo, Live, Gmail, ecc.) Non lasciano passare i siti di phishing. La mia preoccupazione è più simile a quei link su FB o Twitter dei tuoi amici che dicono "controlla questo link"
#3
+17
user185
2011-05-22 13:58:12 UTC
view on stackexchange narkive permalink

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.

** Il primo ** punto è vero se usi la stessa password e nome utente esatti, ma avere password diverse su 1000 server diversi è più sicuro di 1 password su 1000 server, no? ** 2 ° ** Sì, chiunque può effettuare un login, ma c'è una _enorme_ differenza tra vedere una pagina / pulsante di login FB mezza dozzina di volte al giorno e un login una tantum per un sito casuale. Se fossi su site1.com e avesse una pagina di accesso per site2.com, sarebbe strano. Se site1.com avesse una pagina di accesso a Facebook, la maggior parte degli utenti non ci penserebbe nemmeno. Questo è ciò che intendo.
@Oscar: nelle situazioni in cui OAuth è utile, non puoi avere 1000 password diverse. "quindi tutti questi servizi utilizzano la stessa password, ma devono comunque farlo perché tutti devono utilizzare il tuo account Twitter"
@Oscar purtroppo la maggior parte delle persone ha esattamente la stessa password / nome utente per i siti mutipul, perché i loro pigri e / o non si preoccupano e / o il dolore causato dal ritardo nel pensare a nuove password / ricordare quale va con quale sito / dimenticare e dover reimpostare la password è maggiore del dolore percepito di avere un Mallory per accedere al proprio account.
#4
+16
nealmcb
2011-05-25 02:54:44 UTC
view on stackexchange narkive permalink

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.

#5
+11
Rakkhi
2011-05-23 14:19:50 UTC
view on stackexchange narkive permalink

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.

#6
+10
Kim
2011-05-22 11:53:54 UTC
view on stackexchange narkive permalink

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.

Questo è vero, tuttavia, Google è più difficile da hackerare e bloccano la forza bruta e altre cose. Mi fido di Google molto di più, quindi diciamo, Klout.com o qualcosa del genere. Ma sì, ho capito cosa stai dicendo :)
#7
+7
Lie Ryan
2011-06-23 09:33:20 UTC
view on stackexchange narkive permalink

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.

D'accordo, "1000 password per 1000 server" è il mondo ideale;di solito è "1 password memorizzata in 1000 server".Se quella password è compromessa, devi cambiare la password in 1000 server (e ricorda che hai un account lì).
#8
+5
Lie Ryan
2012-09-22 02:30:25 UTC
view on stackexchange narkive permalink

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.

#9
+4
pepe
2011-06-23 07:40:15 UTC
view on stackexchange narkive permalink

# 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

#10
  0
Vicky
2016-05-26 19:58:24 UTC
view on stackexchange narkive permalink

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.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...