it-swarm.it

Autenticazione basata su certificato vs Autenticazione nome utente e password

Quali sono i vantaggi e gli svantaggi dell'autenticazione basata su certificato rispetto all'autenticazione tramite nome utente e password? Ne conosco alcuni, ma apprezzerei una risposta strutturata e dettagliata.

[~ ~ #] aggiornamento [~ ~ #]

Sono anche interessato a sapere a quali attacchi sono soggetti, ad es. come finora menzionato forza bruta, mentre nulla è menzionato per i certificati ... che dire di XSRF? Un certificato dovrebbe avere una durata più breve ed essere revocato mentre una password durerebbe più a lungo prima che una politica di amministrazione chieda di cambiarla ...

95
Stefany

1. Gli utenti sono stupidi

Una password è qualcosa che si adatta alla memoria di un utente e l'utente la sceglie. Poiché l'autenticazione riguarda la verifica dell'identità fisica dell'utente da remoto (dal punto di vista del verificatore), il comportamento dell'utente è necessariamente coinvolto nel processo, tuttavia le password si basano sulla parte del utente che è notoriamente mediocre nella gestione della sicurezza, vale a dire il suo cervello. Gli utenti semplicemente non capiscono di cosa tratta l'entropia della password. Non sono incolpando loro per quello: questo è un argomento tecnico, una specializzazione, che non può realisticamente diventare "buon senso" in qualsiasi momento 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 in modo positivo per quello negli ultimi milioni di anni, perché coloro che non potevano resistere ai loro strumenti di selce non sopravvivevano abbastanza da avere una prole.

I film di Hollywood possono essere usati come modello di come gli utenti pensano alle password, anche solo perché vanno anche al cinema. Invariabilmente, Arch Enemy ha una breve password e adora vantarsene e distribuisce indizi ogni volta che può. E, invariabilmente, un agente segreto britannico indovina la password in tempo per disattivare la bomba a fusione che è stata piazzata sotto il letto di fiori preferito della regina. I film proiettano una realtà distorta, esagerata, ma rappresentano ancora la base mentale su cui operano gli utenti medi: immaginano le password come sicurezza attraverso l'essere più "spiritose" dell'attaccante. E, invariabilmente, la maggior parte fallisce.

"La sicurezza della password" può essere in qualche modo migliorata da regole obbligatorie (almeno otto caratteri, almeno due cifre, almeno una lettera maiuscola e una lettera minuscola ...) ma tali regole sono viste come un onere dagli utenti e talvolta come un vincolo insopportabile alla loro innata libertà - così gli utenti diventano in grado di 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 quella strada.

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, la sicurezza si basa (in parte) su quanto l'utente medio gestisce la sicurezza di un oggetto fisico, e di solito fanno 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 verifichi la password a un certo punto conosce la password o un dato equivalente (non è del tutto vero nel caso di PAKE protocolli ). Con i certificati utente, il certificato è rilasciato da un'autorità di certificazione, che garantisce il collegamento tra un'identità fisica e una chiave pubblica crittografica. Il verificatore può essere un'entità distinto e può verificare tale collegamento e utilizzarlo per autenticare l'utente, senza ottenere la possibilità di impersonare l'utente.

In breve, questo è il punto dei certificati: separare coloro che definisci l'identità digitale dell'utente (ovvero l'entità che esegue la mappatura dall'identità fisica al mondo dei computer) da quelli che = autenticare utenti.

Questo apre la strada a firme digitali che portano non ripudio. Ciò interessa in particolare le banche che accettano ordini finanziari da clienti online: hanno bisogno di autenticare i clienti (che è denaro di cui stiamo parlando, 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 la certezza che sta parlando con il cliente giusto, ma non può dimostrarlo a terzi; la banca potrebbe costruire una trascrizione della connessione falsa, quindi è priva di armi contro un cliente che afferma di essere incastrato dalla banca stessa. Le firme digitali non sono immediatamente disponibili anche se l'utente ha un certificato; ma se l'utente può utilizzare un certificato per l'autenticazione, la maggior parte del duro lavoro è stata eseguita.

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 comporta mai la rivelazione di dati segreti al peer, quindi un utente malintenzionato che impersona 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 è una lattina piena di worm, come può dirti qualsiasi fornitore PKI (e, in effetti, te lo dico io). Soprattutto la gestione della revoca. La 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 memorizzano la loro chiave privata in qualche modo, nel loro "accesso esclusivo". Questo viene fatto nel software (i sistemi operativi esistenti e/o i browser Web possono farlo) o utilizzando hardware dedicato, ma entrambe le soluzioni hanno il proprio set di problemi di usabilità. I due problemi principali che si presentano sono 1) l'utente perde la chiave e 2) un utente malintenzionato ottiene una copia della chiave. L'archiviazione 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 attività disordinata dei driver di dispositivo, 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 sarà possibile utilizzare certificati da alcuni Javascript schiaffeggiati in un sito Web generico. Certificato richiede 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, che li rende molto più vulnerabili ad alcuni attacchi (ad esempio attacchi attivi in ​​cui l'attaccante tenta di fornire loro il proprio certificato del server falso).

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

Sommario

I certificati utente consentono una separazione dei ruoli che le password non possono svolgere. Lo fanno a spese dell'aggiunta di un'orda di problemi di implementazione e distribuzione, che li rendono costosi. Tuttavia, le password rimangono a buon mercato inserendosi in 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 protocolli PAKE inclusi) e, soprattutto, incolpando l'utente in caso di un problema (sappiamo che l'utente medio non può scegliere una password sicura, ma qualsiasi incidente è ancora colpa sua - è così che fanno le banche).

94
Thomas Pornin

sername/password

  • Pro: facile da implementare: richiede solo un po 'di codice e un archivio dati sicuro. A seconda della politica di sicurezza, è possibile generare automaticamente password o forzare la creazione di nuovi utenti.

  • Pro: facile da amministrare: le reimpostazioni della password (per alcune politiche di sicurezza) possono essere eseguite con strumenti automatizzati

  • Con: per una buona sicurezza, le password devono essere ripristinate in anticipo e spesso. L'oblio dell'utente o la mancata modifica delle password è un rischio per la sicurezza o una seccatura di usabilità.

  • Con: le password valide possono essere difficili da ricordare, il che porta al problema degli utenti di riutilizzare le password o di scriverle.

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

  • Con: tutte le parti della trasmissione delle password possono portare all'esposizione: siti Web che memorizzano le password localmente per facilità d'uso, componenti interni del 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 uno sforzo serio per prevenire l'esposizione e il requisito è sia per l'utente che per lo sviluppatore del sistema.

Certificati:

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

  • Pro: rilasciato da una parte fidata (la CA) che consente un sistema di gestione centralizzato per lo stato su più applicazioni. Se un certificato va a 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 negabilità plausibile. Con molte forme di rilascio di certificati, è molto più difficile per un utente dire che non erano loro. Avvertenza: sei ancora bravo quanto le politiche di emissione della tua CA.

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

  • Con: richiede ancora una password/pin: quasi tutti i meccanismi di archiviazione delle coppie di chiavi private vengono quindi sbloccati con un PIN. Le SmartCard possono avere la protezione antimanomissione e le funzionalità di 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 è agganciata la scheda. A volte i problemi con la password riappaiono su scala ridotta con PKI.

  • Con: Complessità dell'infrastruttura: la creazione di una PKI non è un compito facile e generalmente così costoso in termini sia di implementazione che di manutenzione che può essere utilizzato solo per sistemi di grandi dimensioni/costosi.

  • Con: i rapporti sullo stato del certificato e gli aggiornamenti non sono facili: revocare le credenziali di un utente che è stato danneggiato è oneroso a causa delle dimensioni e della complessità dell'infrastruttura. Di solito, una CA genera un elenco CRL che può o non può essere eseguito il provisioning all'interno di un server OCSP. Quindi ogni applicazione dovrebbe controllare ogni login 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 tale credenziale iniziano effettivamente a negare l'accesso. La velocità di aggiornamento dello stato può essere accelerata, ma a un costo di complessità del sistema maggiore.

Un paio di altre note:

Un certificato dovrebbe avere una durata più breve ed essere revocato mentre una password durerebbe più a lungo prima che una politica di amministrazione chieda di cambiarla ...

Non sono d'accordo con la premessa. Sui sistemi su cui ho lavorato che supportano password e PKI, la politica per i requisiti di aggiornamento della password è MOLTO più breve della politica per l'emissione di certificati. La revoca è una diversa lattina 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 che il rischio di esposizione a questi dati sia molto inferiore al rischio di esposizione tramite password. Ai fini pratici, si ritiene che le password abbiano una durata più breve.

Sono anche interessato a sapere a quali attacchi sono soggetti, ad es. come finora menzionato forza bruta, mentre nulla è menzionato per i certificati ... che dire di XSRF?

Stai mescolando mele e arance qui. La forza bruta può essere un attacco praticabile su entrambi i tipi di credenziali di autenticazione, ma XSRF è un attacco a un tipo di applicazione sottostante che sarebbe possibile indipendentemente dal meccanismo di autenticazione. A meno che tu non intenda che, dato che nome utente/password sarebbero stati immessi con una sorta di interfaccia di testo, potrebbero essere inclini a script tra siti su quell'interfaccia.

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

  • Forza bruta: poiché lo spazio delle chiavi della password media è più piccolo dello spazio delle chiavi di una chiave asimmetrica, una password è più facile da forzare. Tuttavia, una dimensione della chiave sufficientemente piccola su un certificato è anche in grado di forzare la forza bruta e la capacità di forzare le chiavi di attacco della forza aumenta con le capacità della CPU, costringendo una corsa al ratto con aumenti della dimensione della chiave.

  • Indovinare con intelligenza: restringere lo spazio delle chiavi a una serie 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 dipendenza da quanto sia grande un nerd l'attaccante è.

  • Ingegneria sociale - fattibile in entrambi i modi, anche se con un certificato archiviato nell'hardware, non devi solo ottenere il controllo dell'utente PIN ma anche l'hardware che memorizza la sua chiave.

  • Attacco interno - ottenere le credenziali dall'interno del sistema e quindi usarle per emulare un utente legittimo - dipende. Se le password vengono archiviate in modo non sicuro, ciò è più fattibile per un sistema basato su password. Ma se riesci a ottenere il controllo della CA, puoi emetterti 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 ignora. Questo è fattibile con SSL/TLS. Tuttavia, un uomo nel mezzo può anche intercettare parti di un trasferimento PKI, a seconda di come viene utilizzato 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 purché non sia possibile stabilire se il messaggio è tempestivo o unico.

32
bethlakshmi
  1. Nomi utente e password
    • Si tratta di quello che sai. Stai fornendo un codice segreto Word per l'autenticazione 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 password o assumere l'autenticazione di ricezione del computer.
    • 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 cosa positiva se l'accessibilità è importante. Per una banca ... questo è male. Per Facebook, non dovrebbe davvero importare.
  2. Certificati
    • I certificati sono un po 'più sofisticati. Il server invia i dati al client e il client firma i dati e li rispedisce. Ciò significa che il server non conosce la chiave privata in qualsiasi momento, quindi mentre un uomo nel mezzo o l'acquisizione del server comporteranno l'accesso, non dispongono della chiave.
    • I certificati sono un dolore da usare. Non li ricordi e possono essere rubati.

Il miglior sistema è una combinazione. Metti una password sulla chiave in modo da avere un'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.

8
Stephen

Sono d'accordo con i punti di Stephen. Presenti una domanda difficile da ricercare poiché il problema non è in genere un confronto tra l'uno e l'altro. Un buon modo per capire perché entrambi esistono e non sono generalmente classificati l'uno contro l'altro è quello di 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 poiché siamo mobili e tendono ad autenticarsi 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 wetware mobile. Una smart card è un ottimo modo per aggiungere l'autenticazione basata su certificato all'essere umano mobile e un altro fattore al processo.

8
zedman9991

Una password può spesso essere forzata e può essere socialmente ingegnerizzata, poiché, poiché il 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 su un sistema che richiede l'autenticazione basata su chiave pubblica è ottenere prima l'accesso a qualche altro computer per ottenere la chiave privata. Questo introduce un ulteriore livello di complessità in ogni attacco. L'ingegneria sociale per indurre una persona a rivelare la sua password non aiuterà, poiché la password decodifica solo la sua chiave privata, piuttosto che concedergli l'accesso direttamente al sistema di destinazione. L'ingegneria sociale per indurre una persona a rivelare la sua chiave privata insieme alla sua password è probabilmente molto più difficile.

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

3
yfeldblum

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

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

1
Martin

Vorrei aggiungere un'opzione: i dispositivi con password unica. Sono d'accordo con quello che altri hanno detto sui pro e contro di certificati e password: i dispositivi OTP richiedono alcuni componenti back-end per funzionare, ma a mio avviso possono essere integrati senza molta seccatura (Active Directory è un po 'diverso, ma altri i sistemi non sono troppo duri).

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

Entrambe le opzioni sono facili da aggiungere alle operazioni basate su Linux. Se vuoi farlo in Active Directory, dovrai acquistare un 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 esso, ma a costi proibitivi da quello che ho visto.

1
Mat Carlson