SSO / OAuth è intrinsecamente danneggiato?

1

Per come la vedo io, l'intero concetto di OAuth / SSO implica che gli utenti possano avere una password centrale che possono usare su una moltitudine di siti senza comprometterli perché in realtà stanno accedendo al servizio che ospita la loro password .

Ora, escludendo l'utilizzo dell'autenticazione a due fattori, in quanto l'utente medio non utilizza questa funzione e utilizza la funzionalità SSO di Google come esempio, ma rendendosi conto che questo si applica a ogni servizio simile:

Ciò che mi impedisce di scrivere un'app che informa semplicemente un utente che supportiamo l'accesso con Google e invece di reindirli alla pagina SSO appropriata, fornisco semplicemente un posto per il nome utente e la password di Google. Quindi emulo l'utente e autorizzo la mia app attraverso il normale processo SSO dietro le quinte, quindi niente sembra anormale e memorizzi anche il nome utente e la password Google sul mio server privato per scopi dannosi in seguito?

E se la risposta non è nulla mi fermerebbe, perché non è obbligatoria l'autenticazione a 2 fattori su tutte queste implementazioni?

    
posta Andrew Hendrix 18.01.2017 - 01:09
fonte

1 risposta

4

A parte gli aspetti legali a cui allude Neil McGuigan nei commenti, è anche difficile emulare perfettamente, per esempio, Google. Per prima cosa, quando effettuo il login, Google mostra la mia immagine del profilo. In secondo luogo, mi chiede di eseguire la mia convalida 2FA (lo so, si presume che la maggior parte delle persone non la usi, ma per quelli che lo fanno, la sua assenza è una bandiera rossa).

Leggendo attentamente la tua domanda, ho appena notato questa affermazione:

I then emulate the user and authorize my app through the normal SSO process behind the scenes so nothing looks abnormal

Che cosa intendi esattamente con questo? Supponendo che a questo punto hai catturato le credenziali degli utenti, come puoi quindi girarti e usarli per eseguire effettivamente SSO? Non c'è modo per il tuo server di autenticarsi con quelle credenziali in modo tale da impostare i cookie corretti nel browser dell'utente, il che è importante per il funzionamento di SSO.

In realtà, se aveste intenzione di eseguire questo tipo di attacco, sarebbe meglio falsificare anche l'SSO, o ometterlo interamente, e solo memorizzare le credenziali per un successivo recupero.

Tuttavia, nessuno di questi è specifico per OAuth o SSO stesso. È solo un tentativo di phishing, indipendentemente da come è stato avviato.

    
risposta data 18.01.2017 - 07:11
fonte

Leggi altre domande sui tag