È sicuro mischiare i metodi di autenticazione?

Se si immette una coppia di nome utente e password valida, si concede l'accesso a un "token" che viene utilizzato per l'autenticazione in relazione a un altro server, quindi si sta per lo più propagando la prima autenticazione. Dipende quindi realmente dalle specifiche del tuo setup.

Ad esempio, supponiamo di avere un file con certificato-con-chiave privata (come PKCS # 12 file, aka "PFX") disponibile su un server. Il server lo invierà a qualsiasi utente che si autentica correttamente con una password. L'utente può quindi importare il certificato nel proprio computer e utilizzarlo per connettersi a un altro server che richiede un certificato client. Per il sistema generale, si utilizza l'autenticazione basata su password, poiché un utente malintenzionato deve solo indovinare la password per ottenere il certificato e quindi ottenere l'accesso al secondo server. Tuttavia, l'autore dell'attacco potrebbe anche tentare di hackerare il primo server e ottenere il certificato, quindi sarà in grado di autenticarsi sul secondo server.

Come illustrato nell'esempio precedente, questa è una regola generica: quando si collegano i metodi di autenticazione come una catena di passaggi successivi, si tende ad ottenere qualcosa che è debole come il più debole dei collegamenti (per una volta, l'analogia della catena "funziona bene).

Esistono altri modi per combinare i metodi di autenticazione e sono noti come autenticazione a più fattori . Questo è ciò che accade quando un server richiede più autenticazione: puoi accedere ai dati se inserisci una password valida e che mostri un certificato valido. Contrariamente all'esempio sopra, il secondo metodo di autenticazione non è sbloccato dal primo; invece, il server richiede entrambi, indipendentemente l'uno dall'altro. Nella "catena analogia", l'autenticazione non è un collegamento successivo in una singola catena (l'attaccante deve solo rompere un link), ma tubi rinforzati nidificati (l'attaccante deve perforarli tutti).

Certo. Richiedere più metodi di autenticazione (noto anche come autenticazione a 2 fattori - sebbene in genere uno dei fattori sia un codice generato casualmente inviato alla tua email / telefono) in linea di principio ti rende molto più sicuro. Dovresti considerare che è più una seccatura per gli utenti, che può innescare più spesso meccanismi di ripristino dell'account e può far sì che gli utenti lascino il tuo servizio o siano notevolmente infastiditi. Potresti prendere in considerazione l'idea di fare ciò se gestisci una banca, ma non necessariamente implementarla se stai autenticando la scrittura su un blog.

La gestione dei certificati X509 non è un'attività comune nel browser e questi certificati scadono spesso, sono difficili / fastidiosi da trasferire tra browser / computer, quindi può portare a un'esperienza utente negativa. Ad esempio, non mi piace come startssl.com (che puoi usare per ottenere certificati SSL gratuiti per i siti web) utilizza i certificati del browser per autenticare gli utenti - spesso ho aggiornato la mia distribuzione negli ultimi sei mesi e non ho pensato di migrare il mio vecchi certificati - o anche se ho fatto i certificati del browser in genere scadono su una scala temporale simile ai certificati SSL, quindi devo comunque creare un nuovo account. Inoltre non mi piace come la mia unione di credito mi costringa a creare e fare clic su un segnalibro ogni volta che effettuo l'accesso (usa nome utente / password + clic su un segnalibro unico per un computer che non funziona mai come non trovo mai quello giusto o generare un nuovo segnalibro attraverso token al telefono su cui devo cliccare prima di poter accedere); in effetti ho spostato la maggior parte dei miei soldi da quella unione di credito in gran parte per la fase segnalibro nella procedura di accesso.

EDIT: ho interpretato la tua risposta in modo diverso da Thomas. Credo che il tuo sistema sia necessario dopo la configurazione dell'account, in modo da avere entrambi un certificato X509 e digitare il tuo nome utente e quindi la password. Se intendi che puoi accedere in entrambi i modi, (solo con il certificato o solo con il nome utente / password), Thomas ha ragione, sei debole quanto il link più debole.

EDIT2: per il tuo esempio aggiornato, vedo poco o nessun miglioramento della sicurezza semplicemente utilizzando un token di sessione generato dal server casuale per gestire le sessioni e avere sessioni di lunga durata che utilizzano cookie sicuri solo http.

Puoi spiegare qual è il beneficio che stai cercando di ottenere? È semplicemente una facilità da parte dell'utente ai tentativi futuri di accesso?

In che modo il tuo schema gestirà gli utenti che modificano i loro certificati X509. Supponiamo che un utente acceda dal computer 1 con il certificato 1. L'utente può accedere successivamente dal computer 2 con il certificato 2? Potrebbe un utente malintenzionato che ottiene nome utente e password U, creare un certificato falso e accedere successivamente come U? Chiunque abbia accesso temporaneo al browser di un utente può esportare banalmente i certificati del browser salvati? (Senza passare attraverso la seccatura di installare keylogger, ecc.).

Ottieni sicurezza rafforzata solo quando hai sempre bisogno di entrambi i fattori. Quando la compromissione di entrambi i fattori può bypassare l'altro fattore, hai una sicurezza più debole.

Le altre due risposte sono corrette; fin dove vanno. Interpreto la tua domanda in un contesto più ampio. Dal mio punto di vista, sembra che si tratti di una variante di ciò che la maggior parte della comunità chiama "step up assurance", e il NIST chiama " Escalation del livello di sicurezza " Sezione 6.1.5 nel documento di riferimento. Il fatto che tu imponga l'escalation all'inizio della sessione non è realmente pertinente al profilo della minaccia.

Come afferma @Thomas Pornin, se tutte le autenticazioni ONU / PW rivelano un token, la domanda passa ai semplici dettagli di implementazione. Ma se parli di escalation di sicurezza, allora la domanda diventa piuttosto interessante. Come valutiamo l'aumento della sicurezza / riduzione del rischio derivante da due autenticazioni sequenziali.

La risposta banale è di supporre che l'avversario sfrutterà solo la forza bruta e sommerà il tempo previsto per la rottura. Realisticamente, dobbiamo modellare la debolezza dell'implementazione UN / PW, l'implementazione di qualsiasi cosa tu stia proponendo come seconda autenticazione (tu dici "qualsiasi cosa, potrebbe essere un certificato", ma questo non ci dice nulla sull'implementazione ).

Analizza in che misura i due rinforzano o si sovvertono a vicenda. Sono veramente indipendenti o fanno affidamento sulla stessa certificazione di identità o registrazione? Le implementazioni sono veramente indipendenti o creano un artefatto che mi consenta di ignorare uno o entrambi.

Infine, la maggiore complessità derivante da due implementazioni di autenticazione vale il costo? la maggior parte degli schemi di sicurezza non fallisce in teoria, ma perché l'implementazione non corrisponde alla teoria. (questo è uno dei motivi principali per cui non eseguiamo il rollover della nostra crittografia.) Potremmo ottenere lo stesso aumento della sicurezza semplicemente aumentando la lunghezza UN / PW? O facendo un miglioramento corrispondente nel certificato?

E abbiamo placcato oro una parte non essenziale. Se metti uno schema di autenticazione placcato platino di fronte a un algoritmo di crittografia che è vulnerabile a BEAST o CRIME, o qualsiasi altra cosa, allora tutto lo sforzo che hai speso per la tua autenticazione superlativa è sprecato.

A mio parere il punto più probabile è la registrazione e la verifica dell'identità. In modo semplicistico, stai trattando l'UN / PW come una registrazione per l'autenticazione del certificato. Se questo è il caso, la domanda è accademicamente interessante, ma in pratica è meglio migliorare la resilienza della gerarchia dei certificati.