1. Gli utenti sono stupidi

Una password è qualcosa che entra nella memoria di un utente e l'utente la sceglie. Poiché l'autenticazione riguarda la verifica dell'identità fisica dell'utente in remoto (dal punto di vista del verificatore), il comportamento dell'utente è necessariamente coinvolto nel processo, tuttavia, le password dipendono dalla parte dell'utente che è notoriamente mediocre nel gestire la sicurezza, vale a dire il suo cervello. Gli utenti semplicemente non capiscono cosa sia l'entropia delle password. Non li biasimo per questo: questa è una materia tecnica, una specializzazione, che non può diventare realisticamente "buon senso" tanto presto. D'altra parte, la sicurezza di un token fisico è molto più "tangibile" e gli utenti medi possono diventare abbastanza bravi. Gli evoluzionisti direbbero che gli umani sono stati selezionati positivamente per questo negli ultimi milioni di anni, perché coloro che non sono riusciti a tenere i loro strumenti di selce non sono sopravvissuti abbastanza da avere una prole.

I film di Hollywood possono essere usati come modello di come gli utenti pensano alle password, se non altro perché anche quegli utenti guardano i film. Invariabilmente, l'Arch Enemy ha una password breve e adora vantarsene e distribuire indizi ogni volta che può. E, invariabilmente, un agente segreto britannico indovina la password in tempo per disattivare la bomba a fusione che è stata piantata sotto l'aiuola preferita della regina. I film proiettano una realtà distorta ed esagerata, ma rappresentano comunque la linea di base mentale su cui operano gli utenti medi: immaginano che le password forniscano sicurezza essendo più "argute" dell'attaccante. E, invariabilmente, la maggior parte fallisce.

La "robustezza della password" può essere leggermente migliorata da regole obbligatorie (almeno otto caratteri, almeno due cifre, almeno una lettera maiuscola e una minuscola ...) ma queste regole sono viste come un peso dagli utenti e a volte come un insopportabile vincolo alla loro innata libertà - così gli utenti iniziano a combattere le regole, con grande creatività, a cominciare dalla tradizionale scrittura della password su una nota adesiva. Il più delle volte, le regole di rafforzamento della password si ritorcono contro in questo modo.

D'altra parte, i certificati utente implicano un sistema di archiviazione e se quel sistema è un dispositivo fisico che l'utente porta con sé con le chiavi di casa o dell'auto , quindi la sicurezza si basa (in parte) su quanto bene l'utente medio gestisce la sicurezza di un oggetto fisico e di solito fa un buon lavoro. Almeno meglio di quando si tratta di scegliere una buona password. Quindi questo è un grande vantaggio dei certificati.

2. I certificati utilizzano la crittografia asimmetrica

L '"asimmetria" riguarda la separazione dei ruoli. Con una password, chiunque la verifichi conosce a un certo punto la password o un dato equivalente a una password (beh, non è del tutto vero nel caso dei protocolli PAKE). Con i certificati utente, il certificato viene emesso da un'autorità di certificazione, che garantisce il collegamento tra un'identità fisica e una chiave pubblica crittografica. Il verificatore può essere un'entità distinta e può verificare tale collegamento e utilizzarlo per autenticare l'utente, senza avere la possibilità di impersonare l'utente.

In poche parole, questo è il punto dei certificati: separare coloro che definiscono l'identità digitale dell'utente (cioè l'entità che fa la mappatura dall'identità fisica al mondo dei computer) da coloro che em> autentica gli utenti.

Questo apre la strada alle firme digitali che portano al non ripudio. Ciò interessa particolarmente le banche che accettano ordini finanziari da clienti online: hanno bisogno di autenticare i clienti (si tratta di denaro, una questione molto seria) ma vorrebbero avere una traccia convincente degli ordini - nel senso di: a il giudice sarebbe convinto. Con la semplice autenticazione, la banca ottiene una certa sicurezza di parlare con il cliente giusto, ma non può dimostrarlo a terzi; la banca potrebbe costruire una falsa trascrizione di connessione, quindi è senza armi contro un cliente che afferma di essere incastrato dalla banca stessa. Le firme digitali non sono immediatamente disponibili anche se l'utente dispone di un certificato; ma se l'utente può utilizzare un certificato per l'autenticazione, la maggior parte del lavoro è stato svolto.

Inoltre, le password sono intrinsecamente vulnerabili agli attacchi di phishing, mentre i certificati utente non lo sono. Proprio a causa dell'asimmetria: l'utilizzo del certificato non implica mai la rivelazione di dati segreti al peer, quindi un utente malintenzionato che si spaccia per il server non può apprendere nulla di valore in questo modo.

3. I certificati sono complessi

La distribuzione dei certificati utente è complessa, quindi costosa:

• L'emissione e la gestione dei certificati è un pieno di worm, come qualsiasi PKI il venditore può dirtelo (e, in effetti, te lo dico). Soprattutto la gestione della revoca. PKI è circa il 5% di crittografia e il 95% di procedure. può essere fatto, ma non a buon mercato.

• I certificati utente implicano che gli utenti memorizzino la loro chiave privata in qualche modo, sotto il loro "accesso esclusivo". Questa operazione viene eseguita nel software (i sistemi operativi esistenti e / o i browser Web possono farlo) o utilizzando hardware dedicato, ma entrambe le soluzioni hanno la propria serie di problemi di usabilità. I due problemi principali che sorgeranno sono 1) l'utente perde la sua chiave e 2) un aggressore ottiene una copia della chiave. La memorizzazione del software rende la perdita della chiave un problema plausibile (in balia di un disco rigido guasto) e la condivisione della chiave tra diversi sistemi (ad esempio un computer desktop e un iPad) implica alcune operazioni manuali che difficilmente saranno ben protette dagli aggressori. I token hardware implicano l'intera disordinata attività dei driver di dispositivo, il che potrebbe essere anche peggio.

• Un certificato utente implica operazioni matematiche relativamente complesse sul lato client; questo non è un problema nemmeno per un Pentium II anemico, ma non sarai in grado di utilizzare certificati da alcuni Javascript schiaffeggiati all'interno di un sito Web generico. Il certificato richiede una cooperazione attiva da parte del software lato client, e detto software tende ad essere, diciamo, ergonomicamente non ottimale in quella materia. Gli utenti medi possono normalmente imparare a utilizzare i certificati client per una connessione HTTPS a un sito Web, ma a costo di imparare a ignorare il popup di avviso occasionale, il che li rende molto più vulnerabili ad alcuni attacchi (ad es. Attacchi attivi in ​​cui l'attaccante cerca di fornire loro il proprio falso certificato del server).

D'altra parte, l'autenticazione basata su password è davvero facile da integrare praticamente ovunque. È altrettanto facile sbagliare, ovviamente; ma almeno non comporta necessariamente costi aggiuntivi incomprimibili.

Riepilogo

I certificati utente consentono una separazione dei ruoli che le password non possono eseguire. Lo fanno a scapito di aggiungere un'orda di problemi di implementazione e distribuzione, che li rendono costosi. Tuttavia, le password rimangono a buon mercato adattandosi a una mente umana, il che implica intrinsecamente una bassa sicurezza. I problemi di sicurezza con le password possono essere in qualche modo mitigati da alcuni trucchi (fino a includere i protocolli PAKE) e, soprattutto, incolpando l'utente in caso di problema (sappiamo che l'utente medio non può scegliere una password sicura, ma qualsiasi contrattempo lo farà è ancora colpa sua: è così che le banche lo fanno).

• Pro : facile da implementare: richiede solo un po 'di codice e un archivio dati sicuro. A seconda della policy di sicurezza, può generare automaticamente le password o costringere i nuovi utenti a crearle.

• Pro : facile da amministrare: le reimpostazioni delle password possono (per alcuni policy di sicurezza) essere eseguite con strumenti automatici

• Contro : per una buona sicurezza, le password dovrebbero essere reimpostate presto e spesso. La dimenticanza o la mancata modifica delle password da parte dell'utente è un rischio per la sicurezza o un problema di usabilità.

• Contro : le buone password possono essere difficili da ricordare, il che porta ai problemi degli utenti che riutilizzano le password o le scrivono.

• Contro : gli archivi di dati delle password sono un punto debole, se un intruso ottiene l'archivio delle password , ottiene il carico principale.

• Contro : tutte le parti della trasmissione della password possono portare all'esposizione: siti web che memorizzano le password localmente per facilità d'uso, interni componenti server che trasmettono in chiaro, file di registro nei prodotti COTS che memorizzano le password in chiaro. Con il segreto che fa parte della trasmissione, sei forte quanto il tuo anello più debole: ci vuole un serio sforzo per prevenire l'esposizione e il requisito è sia dell'utente che dello sviluppatore del sistema.

Certificati:

• Pro : non richiede la trasmissione del segreto. La prova della chiave privata non contiene informazioni segrete: attenua tutti i tipi di punti deboli di archiviazione / trasmissione.

• Pro : rilasciato da una parte attendibile (la CA ) che consente un sistema di gestione centralizzato per lo stato di più applicazioni. Se un certificato va male, può essere revocato. La correzione di una violazione della password deve essere eseguita separatamente per ciascun sistema a meno che non venga utilizzato un ID condiviso.

• Pro : il caso di non ripudio è più forte: nella maggior parte dei sistemi di password, il modo in cui l'utente viene inizialmente autenticato prima della creazione dell'account è piuttosto debole e i meccanismi di reimpostazione della password possono offrire un altro fattore di plausibile negabilità. Con molte forme di emissione di certificati, è molto più difficile per un utente dire che non erano loro. Avvertenza: sei ancora all'altezza delle politiche di emissione della tua CA.

• Pro : ha più scopi della semplice autenticazione - può fornire integrità e riservatezza pure.

• Contro : richiede ancora una password / pin: quasi tutti i meccanismi di memorizzazione di coppie di chiavi private vengono quindi sbloccati con un PIN. Le SmartCard possono avere funzionalità di protezione da manomissione e blocco per prevenire la forza bruta, ma ciò non risolve il fatto che l'utente abbia scritto il suo PIN su una nota adesiva accanto al computer in cui è inserita la scheda. A volte i problemi relativi alla password si ripresentano su scala minore con PKI.

• Contro : complessità dell'infrastruttura: la configurazione di una PKI non è un compito facile e generalmente così costoso sia nella distribuzione che nella manutenzione che può essere utilizzato solo per sistemi grandi / costosi.

• Contro : la segnalazione e gli aggiornamenti sullo stato del certificato non sono facili: revocare una credenziale utente danneggiata è onerosa a causa delle dimensioni e della complessità dell'infrastruttura. Di solito, una CA genera un CRL che può essere fornito o meno all'interno di un server OCSP. Quindi ogni applicazione dovrebbe controllare ogni accesso per lo stato CRL o OCSP. Ciò introduce una serie di ritardi nel sistema tra il momento in cui una credenziale PKI viene segnalata come compromessa e il momento in cui i sistemi che si basano su quella credenziale iniziano effettivamente a negare l'accesso. La velocità di aggiornamento dello stato può essere accelerata, ma a un costo maggiore per la complessità del sistema.

Un paio di altre note:

Si prevede che un certificato abbia una durata più breve e possa essere revocato mentre una password durerebbe più a lungo prima che una politica di amministrazione chieda di cambiarla ...

I non sono d'accordo con la premessa. Sui sistemi su cui ho lavorato che supportano sia password che PKI, la politica per i requisiti di aggiornamento della password è MOLTO più breve della politica per l'emissione dei certificati. La revoca è un diverso tipo di worm: è per l'evento meno probabile di compromissione della chiave privata. Poiché i dati della chiave privata non vengono trasmessi attraverso il sistema, si presume generalmente che il rischio di esposizione a questi dati sia molto inferiore al rischio di esposizione della password. Ai fini pratici, si considera che le password abbiano una durata più breve.

Mi interessa anche sapere a quali attacchi sono inclini, ad es. come finora menzionato la forza bruta, mentre non viene menzionato nulla per i certificati ... che dire di XSRF?

Qui stai mescolando mele e arance. La forza bruta può essere un attacco praticabile su entrambi i tipi di credenziali di autenticazione, ma XSRF è un attacco a un tipo sottostante di applicazione che sarebbe possibile indipendentemente dal meccanismo di autenticazione. A meno che tu non intenda che, poiché nome utente / password sarebbero inseriti con una sorta di interfaccia di testo, potrebbero essere inclini a cross-site scripting su quell'interfaccia.

In generale (mi scuso per la mia mancanza di terminologia ufficiale - I di solito guardo i termini tipici di attacco ma ho poco tempo):

• Forza bruta - perché lo spazio delle chiavi della tua password media è più piccolo dello spazio delle chiavi di una chiave asimmetrica, un la password è più facile per la forza bruta. Tuttavia, una dimensione della chiave abbastanza piccola su un certificato è anche in grado di forzare brute e la capacità di chiavi di attacco di forza bruta cresce con le capacità della CPU che costringono una corsa al successo con l'aumento delle dimensioni della chiave.

• Indovinare con cognizione di causa: restringere lo spazio delle chiavi a un insieme ragionevole di ipotesi è più facile con le password e non è così ovvio per la maggior parte degli algoritmi di chiavi asimmetriche, sebbene ci siano chiavi deboli nell'algoritmo RSA, quindi c'è una certa dipendenza da come un grande crypto nerd l'attaccante è.

• Ingegneria sociale - fattibile in entrambi i casi, sebbene con un certificato memorizzato nell'hardware, non devi solo ottenere il controllo del PIN dell'utente ma anche l'hardware che memorizza la loro chiave.

• Attacco interno - ottenere le credenziali dall'interno del sistema e quindi utilizzarle per emulare un utente legittimo - dipende. Se le password vengono memorizzate in modo non sicuro, ciò è più fattibile per un sistema basato su password. Ma se riesci a ottenere il controllo della CA, puoi rilasciarti un certificato legittimo e quindi dipende da come viene controllato l'accesso.

• L'uomo nel mezzo - dipende - un uomo nel mezzo può intercettare una password se la password non è crittografata in transito da un meccanismo di crittografia che lo bypassa. È fattibile con SSL / TLS. Tuttavia, un uomo nel mezzo può anche intercettare parti di un trasferimento PKI, a seconda di come viene utilizzato il PKI. Le firme PKI senza nonce o timestamp sono aperte agli attacchi di replica da parte di un uomo nel mezzo: può inviare nuovamente un messaggio intercettato a condizione che non sia possibile sapere se il messaggio è tempestivo o unico.

1. Nomi utente e password
   
   • Tutto dipende da ciò che sai. Stai fornendo una parola in codice segreto per autenticarti con il servizio.
   • Ciò significa che se viene intercettato nel flusso, può essere utilizzato. L'uso della crittografia lo rende improbabile ma ancora possibile. Qualcuno può fare un uomo nel mezzo per ottenere la tua password o prendere il controllo del computer che riceve l'autenticazione.
     
   • Un nome utente e una password possono essere utilizzati su qualsiasi computer in qualsiasi momento. Questa è una cosa negativa se la sicurezza è importante e una buona cosa se l'accessibilità è importante. Per una banca ... questo è un male. Per Facebook, non dovrebbe avere importanza.
2. Certificati
   • I certificati sono un po 'più sofisticati. Il server invia i dati al client e il client firma i dati e li restituisce. Ciò significa che il server non conosce la chiave privata in qualsiasi momento, quindi mentre un uomo nel mezzo o il controllo del server comporterà l'accesso, non hanno la tua chiave.
   • I certificati sono un dolore da usare. Non puoi ricordarli e possono essere rubati.

Il miglior sistema è una combinazione. Metti una password sulla chiave in modo da avere l'autenticazione a due fattori. Qualcosa che conosci (password) e qualcosa che hai (chiave). Tuttavia, maggiore è il livello di sicurezza, maggiore è il dolore. Questo è il grande compromesso in tutta la sicurezza.

Sono d'accordo con i punti di Stephen. Presenti una domanda difficile da ricercare poiché il problema in genere non è un confronto tra l'uno e l'altro. Un buon modo per capire perché entrambi esistono e non sono generalmente valutati l'uno contro l'altro è concentrarsi sull'uso. I certificati sono legati ai keystore a livello di macchina e quindi sono ottimi per l'autenticazione da macchina a macchina tra macchine specifiche pianificate in anticipo. Le password sono molto adatte alle persone in quanto siamo mobili e tendiamo ad autenticarci da numerosi sistemi in un modo difficile da prevedere in anticipo. Quindi i certificati sono tipici dell'autenticazione basata su hardware progettata in anticipo e le password sono utili per l'autenticazione basata su mobile wetware. Una smart card è un ottimo modo per aggiungere l'autenticazione basata su certificato all'essere umano mobile e un altro fattore al processo.

Una password può spesso essere forzata e può essere ingegnerizzata socialmente, perché, poiché il suo proprietario deve memorizzarla, è spesso molto più semplice di una chiave segreta.

Una chiave privata (di forza sufficiente - per RSA, 2048 o 4096 bit) non può essere forzata. L'unico modo per autenticarsi in un sistema che richiede l'autenticazione basata su chiave pubblica è ottenere prima l'accesso a un altro computer per ottenere la chiave privata. Ciò introduce un ulteriore livello di complessità a qualsiasi attacco. L'ingegneria sociale per convincere una persona a rivelare la sua password non aiuterà, poiché la password decrittografa solo la sua chiave privata, piuttosto che concedergli l'accesso direttamente al sistema di destinazione. È probabile che l'ingegneria sociale per convincere una persona a rivelare la sua chiave privata insieme alla sua password sia molto più difficile.

Inoltre, le password vengono trasmesse sulla rete dalla macchina dell'utente al sistema che l'utente desidera utilizzare . Le chiavi private non vengono trasmesse in rete, né in chiaro né in formato crittografato; piuttosto viene trasmessa solo la chiave pubblica.

Sembra che tu dimentichi che una pagina web può utilizzare sia certificati che password. Se arriva un utente con un certificato, la porta si apre e se non ha un certificato, deve accedere con nome e password come sempre.

In questo modo, gli utenti interessati ottengono il loro certificato c, tutti gli altri lo fanno alla vecchia maniera.

Vorrei aggiungere un'opzione: dispositivi con password monouso. Sono d'accordo con ciò che altri hanno detto sui pro e contro dei certificati e delle password: i dispositivi OTP richiedono alcuni componenti di back-end per funzionare, ma a mio parere possono essere integrati senza troppi problemi (Active Directory è un po 'diverso, ma altro i sistemi non sono troppo difficili).

Una combinazione di una password e una password monouso funziona molto bene. Puoi scegliere una soluzione più semplice come uno Yubikey con una password (è richiesta una connessione USB o NFC) o un portachiavi con codice visualizzato.

Entrambe le opzioni sono facili da aggiungere alle operazioni basate su Linux. Se vuoi farlo in Active Directory, dovrai acquistare il software per gestire il codice e installarlo su ogni server AD. L'utente inserisce quindi l'OTP all'inizio del campo della password, quindi la sua solita password. È possibile sviluppare il proprio modulo per questo, ma a costi proibitivi da quello che ho visto.