Quali sono gli svantaggi dell'autenticazione Single Sign-On?

13

Stavamo discutendo di implementare il single on nella nostra applicazione web, subito dopo aver analizzato ci siamo resi conto che i seguenti vantaggi erano i vantaggi del single sign on authentication. Nelle parole di Shwetha sul blog di Cymfony System Testing :

Advantages

  • Users select stronger passwords, since the need for multiple passwords and change synchronization is avoided.
  • Inactivity timeout and attempt thresholds are applied uniformly closer to user points of entry.
  • It improves the effectiveness/timeliness of disabling all network/computer accounts for terminated users.
  • It improves an administrator's ability to manage users and user configurations to all associated systems.
  • It reduces administrative overhead in resetting forgotten passwords over multiple platforms and applications.
  • It provides users with the convenience of having to remember only a single set of credentials.
  • This also improves security as users find it easier to remember their credentials and do not have to write them down, allowing for a more efficient user logon process.
  • It reduces the time taken by users to log into multiple applications and platforms.

Quali svantaggi esistono quando si implementa la tecnologia Single Sign-On?

    
posta BlueBerry - Vignesh4303 24.09.2012 - 07:41
fonte

4 risposte

9
  • Singolo punto di errore

  • Un singolo bersaglio di alto valore (attrae più attaccanti)

  • Divulgazione di informazioni necessarie tra il sito fidato e l'autorizzazione SSO

  • Attacco canale laterale contro passo di autenticazione (in teoria, dipendente dall'implementazione)

  • Mancanza di controllo sull'elenco degli utenti

  • Ancora un'altra interfaccia da mantenere (complessità aggiunta)

  • Potresti non sapere mai quanto è sicuro il tuo sistema o se c'è una violazione

  • Costo aggiunto

Questi sono tutti in cima alla mia testa. Immagino che qualcuno abbia compilato una lista canonica da qualche parte.

    
risposta data 24.09.2012 - 07:57
fonte
5

Questo è iniziato come un commento alla risposta di Tyler, ma a corto di spazio.

Sì, se lo implementate male, allora ci saranno dei bug che possono essere sfruttati - ma ci sono solo 2 punti pinch in cui SSO è diverso dai sistemi separati in questo senso - quando si passa dal sito SSO al sito dell'applicazione, e quando si termina una sessione SSO (e quindi sessioni sulle applicazioni attendibili).

Single point of failure

Solo se mal implementato.

Necessary information disclosure between trusting site and SSO authority

Come stai esponendo più informazioni al sito fidato? In effetti, ci sono molte meno opportunità di sfruttare l'applicazione quando non gestisce l'autenticazione stessa.

Lack of control over your user list

Come? Se controlli sia le tue applicazioni che l'SSO, perché hai meno controllo?

Yet another interface to maintain

La definizione di interfacce e l'appropriato isolamento tra componenti di sistema è una buona pratica. SSO ti costringe semplicemente ad applicare questa pratica. Penso che sia un vantaggio. Effettivamente mantenere un'unica implementazione del codice per l'autenticazione piuttosto che per più di un programma dovrebbe ridurre complessità e costi.

You may never know how secure your system is or if there is a breach

Com'è diverso dai sistemi standalone?

Added cost

Come per quanto riguarda l'interfaccia - non dovrebbe aggiungere complessità al codice, né richiedere hardware aggiuntivo. L'unico costo aggiuntivo che posso pensare è la necessità di un certificato SSL aggiuntivo, il che non è poi così tanto.

Se sei handing your security mechanisms to an opaque 3rd party allora la maggior parte dei punti è valida, ma non se stai implementando il sistema da solo.

C'è un leggero sovraccarico delle prestazioni con reindirizzamenti per gli utenti che accedono solo a una singola applicazione, ma non enormi.

    
risposta data 25.09.2012 - 17:01
fonte
2

Non dici se lo scope per SSO è intranet o internet . Se include Internet allora ho molto amore per i siti compatibili con SAML 2.0, tuttavia ci sono alcuni svantaggi dei siti SAML2.0 e SaaS:

  1. Molti fornitori SaaS (provider di servizi) non supportano tutte le asserzioni SAML 2.0, ad es. asserzioni di mover / movers / leavers in modo da non ottenere tutti i vantaggi di SAML2
  2. Accettare le asserzioni SAML2 con un fornitore SaaS può essere un lavoro abbastanza difficile da iniziare.
  3. se il sito SaaS richiede SSO federato per, ad esempio, gli utenti del personale, e quindi l'accesso continuato quando lo staff lascia, si entra in una orribile autenticazione in modalità doppia che indebolisce la soluzione generale. ho avuto questo con un sistema di busta paga in cui il personale è destinato a continuare ad avere accesso una volta che hanno lasciato la compagnia. vale a dire dove l'IdP (provider di identità) è la directory del personale interno.
  4. I prodotti conformi SAML2 (per la tua parte del firewall) sono costosi e dominati da una società (quindi difficile negoziare il prezzo)

a parte questo - se riesci a far funzionare tutti i siti SaaS per la tua organizzazione con SAML, collegati al tuo negozio di identità, avrai eliminato un grosso rischio, soprattutto dal momento che gli utenti scelgono la stessa password per tutti gli accessi aziendali.

La cosa peggiore che puoi fare (menzionata sopra) è cucinare il tuo schema SSO.

    
risposta data 10.12.2012 - 18:27
fonte
0

Poiché SSO consente l'accesso a più applicazioni, per sicurezza deve essere eseguito il backup con una password unica inviata tramite SMS o token RSA Secure ID.

    
risposta data 25.03.2016 - 06:57
fonte

Leggi altre domande sui tag