In che modo SSO migliora la sicurezza?

L'idea con un buon accesso singolo è che ci sono meno posti in cui le tue credenziali possono essere compromesse. Esistono tre motivi per utilizzare password diverse, in primo luogo, perché ogni posto univoco in cui è memorizzata la password (eventualmente con hash) è un altro posto in cui potrebbe essere compromesso. Secondo, perché se la tua password è compromessa, qualsiasi altro account che lo usa dovrebbe essere aggiornato e questo è difficile da fare. Terzo perché se la tua password è compromessa, potrebbero accedere a più account se fossero condivisi.

SSO è un grande vantaggio per i primi due. Un buon sistema SSO dovrebbe memorizzare le credenziali dell'account solo in una posizione (che si spera molto più fortificata). Tutta l'autenticazione viene eseguita contro questo negozio. Se il tuo account è compromesso, piuttosto che avere molti posti da aggiornare, una sola password deve essere cambiata e un account bloccato.

Non affronta in particolare la terza preoccupazione, ma in primo luogo rende meno probabile il compromesso. Inoltre, a seconda dell'account, le diverse password non rappresentano necessariamente una barriera. Ci sono un sacco di esempi segnalati di aggressori che usano un account compromesso per fare una catena dall'account all'account fino a quando non riescono ad arrivare all'account reale che vogliono. (Ad esempio, se possono accedere al tuo account di posta elettronica, possono utilizzare le reimpostazioni di password.) Un buon sistema di segnalazione dei compromessi e la possibilità di bloccare l'account possono aiutare a ridurre il rischio in caso di attività sospette viene rilevato.

L'argomento secondo cui le credenziali completamente uniche potrebbero essere più sicure di una buona configurazione SSO è probabilmente valido, ma nel mondo reale, molte persone riutilizzano le credenziali. SSO attenua gran parte del rischio di questo comportamento pur consentendo la comodità che la gente desidera.

Più password l'utente ha, più difficile da gestire.

Si dimenticheranno più spesso le loro password, il che significa che dovranno reimpostare un helpdesk o un sistema automatizzato. Tali procedure di reimpostazione della password sono spesso vulnerabili a tutti i tipi di attacchi diversi. Il personale dell'helpdesk può essere ingannato attraverso l'ingegneria sociale e le e-mail inviate dai sistemi di reset automatico possono essere intercettate.

L'alternativa sarebbe quando l'utente userebbe la stessa password per tutto, il che è una pessima idea, perché una password compromessa in un sistema comprometterebbe tutti i sistemi. Potrebbe sembrare che SSO stia facendo esattamente la stessa cosa, ma la maggior parte dei sistemi SSO funziona in modo che le applicazioni che lo usano non conoscano la password effettiva dell'utente. Solitamente l'utente si autentica solo nel sistema SSO che quindi invia un token di utilizzo monouso all'utente e all'applicazione.

Ho sostenuto l'uso di SSO nelle nostre applicazioni intranet per aumentare la sicurezza. In teoria, non è così. Molti database ben protetti diversi, ciascuno con una password casuale senza alcuna relazione con altre password di un utente, sono più sicuri ... in teoria. Ma in pratica, le persone riutilizzano le loro password e non tutte le password vengono memorizzate seguendo le migliori pratiche. Ciò significa che l'accesso al tuo sistema più strong è protetto dalla sicurezza del sistema più debole. Usando SSO, abbiamo un unico sistema che possiamo garantire meglio segue le migliori pratiche.

Potrebbero esserci altre opzioni, come forzare le password ad essere diverse, ma devo ancora vederne una che funzioni bene (anche una password diversa non significa molto se si tratta di My $ secret1, My $ ecret2, My $ ecret3, ecc., ma come stabilisci in che modo le password simili si trovano nel sistema numero 5 se hai password hash e salate appropriatamente nei sistemi da 1 a 4).

Pensarci in un altro modo, mettere tutte le uova in un cesto sembra sciocco in generale, ma abbiamo un insieme quantomeno sovrapposto di uova, dove se si rompe, si rompono tutte. In tal caso, è meglio mettere tutte le uova nel cesto più protetto.

Quindi un aspetto che ci è mancato in questo post è l'aspetto dell'aggiunta di ulteriori fattori di autenticazione a SSO. Ad esempio, diciamo che hai 10 siti ai quali accedi, tutti questi siti accettano solo la password del nome utente, che è la più facile da capire e decifrare. Come un altro poster menziona un buon SSO imposterà grandi password randomizzate per il login, sto pensando a 32+ caratteri, randomizzati con caratteri speciali, che possono essere cambiati ogni 30 giorni. Questo è qualcosa che una persona non ricorderebbe o non vorrebbe mai digitare, lo fai con password casuali rigenerate per ogni sito. Quindi hai ancora la fallibilità della password del nome utente, ma almeno ora è il più sicuro possibile. Dall'altro lato, l'IDVault in cui l'utente accede può ora essere protetto con l'autenticazione a 2 o 3 fattori, quindi l'utilizzo di bio o token o entrambi per accedere a IDVault è molto più sicuro rispetto alle password non-SSO di ciascun sito.

Alla fine si tratta di proteggere gli utenti da se stessi, se hai richiesto una password lunga, difficile da rompere, li memorizzeranno in un foglio di calcolo o in una nota cartacea il 99% delle volte.

Ovviamente, come un precedente poster menzionato, questo apre un punto di errore, questo di per sé può essere attenuato ma mai completamente scomposto. Alla fine, come professionista della sicurezza, è necessario valutare il rischio di un errore (mitigato o meno) e il rischio di password definite dall'utente facili da ricordare. Per me la risposta è ovvia ma questa è la mia opinione e potrebbe non essere la tua.