it-swarm-eu.dev

Vantaggi dei certificati client per l'autenticazione client?

Non sono un esperto di sicurezza, quindi per favore basta chiedere in un commento se non ho chiarito la mia domanda abbastanza per una risposta.

Lo scenario

Abbiamo un server che esegue servizi WCF e un numero di client che si connettono. Questi client sono in realtà PC Linux che costruiamo. Dobbiamo stabilire comunicazioni sicure tra il nostro server e i nostri clienti (di nuovo le costruiamo e le distribuiamo ai siti dei clienti).

Client che si fida del server

Lo implementeremo consentendo al client di stabilire una connessione affidabile con il server tramite l'implementazione delle comunicazioni SSL.

Server che si fida del client

Ora abbiamo il compito di autenticare il client. Ovviamente questo viene fatto mantenendo una sorta di credenziali sul client. Una volta connesso, il client può inviare le credenziali al server e il server può convalidarle.

Un'opzione per queste credenziali è l'archiviazione di una sorta di Guid o di altri ID/password generati dall'applicazione basata su WCF. Alla ricezione delle credenziali, il servizio WCF esegue una ricerca nel database e verifica che siano corretti.

Un'altra opzione è quella di utilizzare i Servizi certificati per creare certificati client che vengono copiati sul PC client prima che vengano inviati. Dopo aver stabilito la connessione protetta, il client invia il certificato al server che autentica il certificato con Servizi certificati.

Le domande

Quali vantaggi ha l'uso di un certificato per autenticare il client rispetto a un nome utente/guida? Quali sono gli svantaggi?

Si prega di prendere in considerazione:

  • Sicurezza
  • Complessità di attuazione
  • Complessità della programmazione Integrazione con l'applicazione. Ciò include il flusso di lavoro per la creazione del token di autenticazione, l'associazione di metadati appropriati (autorizzazione/associazione), la gestione dell'autenticazione come la disabilitazione dell'accesso, ecc.
34
Shaun Rowan

La distribuzione di certificati client potrebbe adattarsi qui. I vantaggi dell'utilizzo di un certificato cert rispetto al nome utente sono piuttosto semplici. Chiunque può digitare un nome utente da qualsiasi dispositivo client. Se si utilizza una combinazione di nome utente con guid, la "sicurezza" o la certezza che il client si sta connettendo da un dispositivo client noto/autorizzato dipende dalla forza e dall'unicità del guid. Se c'è un modo per clonare o falsificare il guid (gli indirizzi mac possono essere falsificati abbastanza facilmente), il livello di affidabilità diminuirà.

I certificati client possono essere distribuiti ai clienti, con o senza controllo di validità (a parte la data di validità, CN, sci/sci, impronte digitali, ecc.). Meccanismi di controllo della validità su richiesta come ocsp richiederebbero il controllo dell'applicazione server con un server ocsp ogni volta che il client si connette/tenta di autenticare. Ma dalla descrizione, non ho letto che il controllo di validità è importante quanto essere in grado di legare il certificato al dispositivo client.

Un dettaglio importante con i client certs (certs in generale) è che può essere esportato e la maggior parte delle implementazioni non blocca la portabilità del certificato. Indipendentemente dal fatto che o come verranno archiviati i certificati client, senza misure adeguate, il certificato può essere facilmente copiato da un dispositivo all'altro. Alcune implementazioni memorizzano il certificato sul filesystem (i file che terminano con .cer, .der, .key, .crt di solito sono indicazioni che i certificati sono memorizzati nel filesystem). Implementazioni più potenti (dipendenti dall'applicazione) possono archiviare i certificati e le chiavi in ​​un keystore (ovvero Java). Il keystore può aggiungere una protezione aggiuntiva come garantire che la chiave privata non sia esportabile. Tuttavia, il la certezza che la chiave non è stata esportata è forte solo come il keystore stesso: i negozi di chiavi hardware (ovvero smart card, usb hsm, ironkey, ecc.) offrono una garanzia molto più forte che la chiave privata non è esportabile rispetto ai negozi di chiavi software.

A proposito, il punto sopra influisce anche sulle chiavi del server. La maggior parte delle implementazioni memorizza la chiave privata in un archivio di chiavi software ed è generalmente contrassegnata come esportabile. Inoltre, la chiave privata di solito non è protetta da password, quindi chiunque abbia accesso al server può andarsene con la chiave privata. Se un certificato può essere copiato, non offre non ripudio.

Per rispondere alla tua domanda, se esiste un buon modo per sfruttare una sorta di ID hardware (guid, numero di serie, certificato memorizzato in HSM, ecc.), Ciò fornirà probabilmente più sicurezza rispetto all'utilizzo di un ID basato su software (certificati client inclusi) . L'uso di certs client con protezione password abilitata per l'accesso alla chiave privata fornisce una convalida un po 'più forte perché non solo un client deve avere accesso alla chiave privata ma anche la password per usarla.

Se decidi di utilizzare i certificati client, dovrai costruire o utilizzare un'infrastruttura PKI esistente. Fornitori come Codomo, Entrust, Symantec (ex vrsn, thawte e geotrust), Godaddy e molti altri offrono infrastrutture sia pubbliche che private. Tuttavia, il costo dell'implementazione di un certificato client basato su software sarà probabilmente maggiore rispetto all'utilizzo di un ID hardware basato su software o forse persino di un ID univoco basato su hardware.

Se possibile, determina il livello di sicurezza che desideri avere e decidi se software, software + password o hardware sono sufficienti.

19
bangdang

Con l'autenticazione con certificato client, la chiave segreta (la chiave privata) non lascia mai il client e non va al server. Sia che ti fidi del server o meno (dovresti comunque verificarlo prima), la tua chiave privata non sarà trapelata. Questo è un vantaggio rispetto all'autenticazione basata su form tradizionale o HTTP di base.

È anche possibile utilizzare alcuni token/smart card crittografici hardware progettati in modo tale che la chiave privata non lasci mai il token (le firme coinvolte nell'handshake TLS si verificano a bordo).

Se si utilizzano i certificati client nel contesto di un'infrastruttura a chiave pubblica (molto probabilmente), è anche possibile usufruire dei vantaggi offerti dall'infrastruttura a chiave pubblica. Ciò è utile soprattutto per strutture di grandi dimensioni, ma è possibile:

  • Riconosci l'identità degli utenti che non avevi mai registrato prima.

    Ecco a cosa servono le autorità di certificazione. Se ti fidi della CA, ti fidi del certificato che emette. Se gli utenti sconosciuti accedono senza un account preesistente sul sistema e se presentano certificati di cui ti fidi, sarai in grado di riconoscere le loro identità, come garantito dalla CA. È possibile che si desideri ottenere ulteriori dettagli dall'utente, ma l'identità principale sarà stata dichiarata con la CA e vi avrà lasciato una traccia amministrativa.

  • La stessa identità dichiarata dal certificato può essere utilizzata su più siti Web indipendenti (a condizione che si fidino della stessa CA), eventualmente utilizzata come forma di Single Sign-On.

  • Un certificato compromesso può essere revocato direttamente dalla CA.

  • Tramite la CA, si disaccoppia il problema di dimostrare l'identità dell'utente dalla fornitura del servizio stesso. Anche altri metodi come OpenID raggiungono questo obiettivo, ma difficilmente forniscono lo stesso livello di sicurezza di ciò che le CA possono fare (a condizione che le CA svolgano correttamente il proprio lavoro). Il livello di affidabilità varia in base alla qualità della CA.

    Un vantaggio di ciò è che è possibile emettere di nuovo un nuovo certificato allo stesso utente con chiavi diverse (se il certificato precedente è scaduto o se la chiave privata è stata compromessa) e mantenere lo stesso identificatore (Oggetto) su tutti i sistemi che si fidano di questo CIRCA.

(Puoi anche utilizzare certificati client al di fuori del contesto di una PKI, ma devi definire le tue regole di fiducia, che possono essere abbastanza noiose.)

I certificati client possono anche essere utilizzati indipendentemente dal protocollo in esecuzione su SSL/TLS. Puoi anche usarli per S/MIME, ad esempio, se applicabile.

Un altro vantaggio è che, poiché l'autenticazione non avviene a livello HTTP, è effettivamente senza stato, se cose come lo stile architettonico REST per te sono importanti).

Alcuni servizi Web possono anche utilizzarlo per la sicurezza a livello di messaggio, lasciando potenzialmente una pista di controllo per il non ripudio di determinati messaggi, se necessario.

Lo svantaggio principale è che dovrai educare i tuoi utenti ai concetti di base della crittografia a chiave pubblica. Ciò è particolarmente importante se non si utilizzano i token hardware (ma si mantengono solo i certificati e la chiave privata nel software dell'utente).

  • A differenza delle password, gli utenti non ricordano la chiave privata/cert. Dovranno utilizzare una macchina in cui è stato installato il certificato (o in cui è presente un lettore di schede adatto per soluzioni hardware). Per tagliare gli angoli, alcuni potrebbero essere tentati di non prendersi cura delle proprie chiavi private come dovrebbero (normalmente sono protette da password).

  • Quando si spiega, la nozione di "certificato" può essere fonte di confusione. Anche gli esperti accorciano le frasi a volte. Se dici "usa il tuo certificato per accedere", ciò che realmente intendi è "usa la chiave privata e il tuo certificato per accedere": la chiave privata è implicita in questa espressione. Al contrario, se qualcuno ti dice "inviami il tuo certificato", allora non dovresti usare la tua chiave privata. Se cerchi la documentazione, troverai una serie di riferimenti ai file PKCS # 12 (.p12 o .pfx) e file di certificato PEM (.pem o .crt, tipicamente). In genere, il primo contiene la chiave privata mentre il secondo no (anche se può anche farlo). Tutte queste nozioni confonderanno gli utenti a meno che non sappiano cosa stanno facendo.

  • Le interfacce utente del browser per i certificati client sono generalmente piuttosto scarse. È abbastanza difficile dal punto di vista dell'interfaccia utente disconnettersi da un sito Web in cui è stato autenticato, ad esempio, un certificato client (come HTTP Basic). (Rende ancora più importante la protezione CSRF.) Se i tuoi client sono "macchine" e non utenti tramite un browser, questo non è un problema.

In termini di infrastruttura, se non si desidera utilizzare i servizi di una CA commerciale per i certificati client, sarà necessario distribuire la propria CA. Si noti che la CA utilizzata per l'autenticazione dei client può essere indipendente dalla CA utilizzata per l'autenticazione del server. È possibile eseguire un sito Web con un certificato emesso da una CA nota ma avere i certificati client attendibili dalla propria CA. Esistono vari strumenti per la gestione della CA, inclusi quelli open source . Alcuni possono persino eseguire la generazione di chiavi nel browser, in modo che la chiave privata sia pronta nel browser (il rovescio della medaglia è che l'utente deve riutilizzare lo stesso browser per importare il certificato una volta emesso).

La configurazione dei server richiede una certa comprensione di ciò che i certificati (certificati CA, certificato server), ma in realtà non è così complicato. La maggior parte dei server supporta in un modo o nell'altro.

I certificati client forniscono solo l'autenticazione. Potrebbe essere necessario ottenere ulteriori attributi (ad es. Da LDAP o da un database rispetto agli argomenti dei certificati). Dovrai sicuramente avere una logica di autorizzazione in aggiunta a questo, come sarebbe per qualsiasi altro sistema di autenticazione. È tipico mappare un DN soggetto a un identificatore locale nel proprio sistema.

(Esistono usi più avanzati in cui è possibile delegare l'autenticazione utilizzando certificati proxy o passare token di autorizzazione tramite certificati di attributi, ma questi sono più insoliti e non sono accettati da tutti gli stack di software.)

19
Bruno