Perché l'autenticazione del certificato client non è più comune

I tuoi tre punti sono abbastanza validi.

In breve: i certificati client non sono complicati per gli utenti Internet medi.

tl; dr

Il problema principale deriva dal fatto che l'autenticazione reciproca (TLS) non funziona allo stesso modo per entrambe le parti. La spiegazione seguente presuppone l'autenticazione TLS reciproca.

Il client si connette al server e prevede alcune conferme di identità dal server sotto forma di certificato server emesso da un'autorità attendibile. Se il certificato del server ha superato l'autenticazione TLS, abbiamo ottenuto il server giusto.

Quando il server è in ascolto sulla porta e il client si connette al server, il server dovrebbe autenticarsi e autorizzare il client. Il server deve associare il client remoto a un database utente locale per convalidare le autorizzazioni e fornire contenuto personalizzato. Ecco la differenza: il client autentica solo il server, ma il server autentica e autorizza il client.

Come puoi vedere, il client consuma solo risorse e non è necessario autorizzare il server remoto. Il server è un produttore di risorse e dovrebbe verificare se il client è autorizzato a ricevere i dati richiesti, quindi l'autorizzazione deve essere abilitata sul lato server. In uno schema di autenticazione email / password, il server esegue il mapping di email / password a un determinato account nel database locale. Il server riceve queste informazioni quando l'utente si registra sul server. Registrazione con certificato:

1. è difficile. Richiede strumenti sofisticati con sintassi criptica e conoscenza speciale;
2. richiede la gestione dei certificati.

È qui che gli utenti non istruiti falliranno. Puoi ricordare una combinazione di email / password, quindi passare da un account all'altro non è un problema. Il passaggio del dispositivo all'autenticazione client basata su certificati non andrà da nessuna parte. Quanto sarebbe facile per l'utente medio (che non è un esperto IT) spostare il certificato dal suo laptop Windows al telefono / tablet iOS, ad esempio? Sposta il certificato tra telefono / tavolo Android e laptop Mac?

Poiché il client non autorizza il server (non mantiene un database locale di server validi), il server può ruotare le sue chiavi ogni giorno e nessuno lo noterà. Il server funzionerà come al solito.

Non sono d'accordo con l'affermazione @ SyntaxxxErr0r che gli utenti finali sono pigri. Non sono pronti per eseguire la gestione dei certificati da soli. E i tentativi di insegnarli risulteranno in un cibo per potenziali hacker. Ancora una volta, l'utente medio di Internet non è un esperto IT e non è tenuto a esserlo. È un buon affare che gli utenti finali capiscano la combinazione di email / password ed è impossibile chiedere loro altro.

But still why not offer them for sites requiring high security where user is ready to go extra mile to ensure it (say bank sites) or sites that want to provide impression of high security (say bank sites again)?

Stessa storia. Internet banking è previsto per tutti, indipendentemente dalla loro formazione tecnica. Cioè, la mia nonna di 80 anni dovrebbe essere in grado di utilizzare i servizi di banca online per gestire la sua pensione e effettuare i pagamenti di base. Tuttavia, alcune banche rilasciano ai clienti un token hardware personalizzato, ma si tratta di un ulteriore investimento da parte delle banche. Letteralmente nessun sito in Internet selvaggio investirà in token hardware per ogni utente.

un'altra cosa da considerare: i siti Web offrono la reimpostazione della password tramite e-mail. Come sarà questo in caso di certificati? Prova a rispondere a queste domande e capirai perché l'autenticazione client basata su certificati non è diffusa in Internet e non sarà a lungo.

    

L'unico contesto in cui ho visto l'autenticazione del certificato client offerto anche come opzione è per le autorizzazioni API server-server.
Anche in questo contesto non ha davvero preso piede. Le chiavi API (in pratica solo lunghe coppie nome utente-password, adatte all'uso dei robot) sono portatili, facili da implementare (ricorda, gli sviluppatori sono altrettanto pigri come tutti gli altri) e facili da mantenere / ruotare.

Alcuni problemi particolari con l'utilizzo dei certificati client per l'identificazione / autenticazione / autorizzazione:

• È possibile trasmettere il cert pubblico out-of-band e utilizzare il proprio cert privato per l'identificazione, ma il ciclo di certs è un lavoro ingrato e occorre copiare il certificato tra i server paralleli nel cluster.
• È possibile utilizzare una normale catena di fiducia in cui una firma su un certificato sostituibile promette di essere chi si dice di essere, ma immagina il mal di testa di farlo funzionare in modo affidabile negli ambienti di sviluppo e di gestione.

Possiamo immaginare che tutto ciò sarebbe più facile se fosse già una pratica normale, ma non sarebbe mai così facile come i token / chiavi convenzionali, e i vantaggi sarebbero piccoli.

    

Probabilmente dovuto in parte al fatto che il processo era relativamente semplice abbastanza che chiunque poteva e poteva implementare un certificato in pochi minuti, ma anche abbastanza complicato da non riuscire a configurarlo correttamente.

Tuttavia, le persone hanno la tendenza a non configurarlo, perché non era già impostato. Fondamentalmente, la maggior parte degli utenti finali tende ad essere pigra.