È possibile utilizzare una chiave GPG o SSH per l'autenticazione basata sul Web in modo sicuro?

Per un'applicazione Web, il problema principale è che il codice del sito Web (Javascript in un browser) non è in grado di leggere e scrivere file a piacimento. Bene, in generale, questo è più un vantaggio che un problema, ma qui significa che il codice Javascript non sarà in grado di accedere alle chiavi private SSH o PGP.

Ci sono cose che possono essere fatte, a seconda di quanto siano esperti di tecnologia gli utenti e di quante operazioni manuali tollereranno:

• È possibile utilizzare un'estensione del browser installata localmente che accede alle chiavi private SSH o PGP per conto del sito Web. Preferibilmente, è consigliabile un controllo utente: non vogliamo davvero un browser che firmi le cose solo perché un sito Web ha detto di farlo.

• Il server può fungere da server SSH e richiede ai client di connettersi con SSH e autenticazione client basata su chiave. L'utente eseguirà SSH in modalità "SOCKS proxy". Il server Web stesso ascolta solo localhost , cioè non raggiungibile se non attraverso tale proxy locale. In questa modalità, il server Web potrebbe anche essere HTTP, non HTTPS; questo sarebbe davvero sostituire SSL con SSH. Sul lato server, tenere traccia degli utenti dovrebbe usare mod_ident o qualcosa di simile (il server SSH sa chi è il client, ma le informazioni devono essere inoltrate al server HTTP, fortunatamente si trova sulla stessa macchina, quindi è possibile utilizzare l'identità a livello Unix.

• Il sito Web potrebbe visualizzare una "sfida" come un file scaricabile con contenuti casuali. L'utente ottiene il file, lo firma con GnuPG e incolla l'output (corazzato ASCII) in un campo di testo sul sito Web. Il server verifica la firma e la accetta come autentificazione dell'utente (purché il server conosca già la chiave pubblica dell'utente). Clunky, ma funziona.

Una variante basata su posta di quanto sopra può essere consigliabile, poiché le implementazioni PGP sono spesso incorporate nel software di posta elettronica, e anche perché apre la possibilità di non doversi fidare di una CA radice esterna. Sarebbe come questo:

• L'utente si connette al server Web con HTTPS. Il server utilizza un certificato autofirmato. Il browser avvisa a riguardo ("avviso rosso spaventoso") ma consente all'utente di procedere.

• Nel sito, l'utente inserisce il suo nome. Quindi il server invia una email firmata e crittografata (con PGP) all'utente; l'e-mail firmata contiene un nonce casuale e anche una copia dell'identificazione personale del certificato SSL del server. Anche il nonce casuale viene stampato sul sito Web stesso.

• L'utente verifica la firma PGP sull'e-mail del server, quindi controlla che l'identificazione personale corrisponda a quella che può vedere dal suo browser; questo convince l'utente che sta vedendo il vero certificato del server, quindi non c'è in corso Man-in-the- Attacco centrale . (Qui sostituiamo il sistema CA X.509 con la convalida basata su PGP.)

• L'utente verifica inoltre che il nonce visualizzato sul sito Web corrisponda a quello che vede nell'e-mail (questo è importante).

• L'utente risponde all'e-mail inviandone il contenuto, questa volta firmato con la propria chiave privata PGP e crittografato con la chiave pubblica del server. Il server verifica quell'email e quindi sa che il valore nonce è stato effettivamente ricevuto dall'utente desiderato.

• Il server invia il valore nonce come cookie al browser dell'utente. Ciò consente la navigazione senza infastidire l'utente con ulteriori round di autenticazione. Spetta al server decidere per quanto tempo accetterà il cookie come token di autenticazione valido.

Nello schema sopra, è importante notare che inviando indietro la sua risposta via e-mail, l'utente sta davvero autorizzando il server ad assumere che chiunque ritorni con il nonce (come incluso nell'e-mail) sia realmente l'utente stesso. Questo è il motivo per cui è importante controllare manualmente che il nonce corrisponda a ciò che viene mostrato nella pagina Web.

Is it possible to use OpenPGP/SSH key pairs to authenticate with a web application in a secure fashion to replace traditional password-based authentication?

Sì. È abbastanza possibile.

If it is possible, what will the authentication steps look like? Is there perhaps a known good implementation of such an idea for popular languages and platforms like Ruby, .NET, Java or Python?

Vedi la mia risposta per la prossima domanda.

If it isn't possible, what are the reasons? Is there perhaps a constraint on web browsers accessing the GPG keychain or SSH key file?

L'elaborazione delle chiavi SSH e OpenPGP in un'app Web è possibile con le librerie di terze parti (in particolare le librerie C o Java data la loro ricca ecologia), ma si perderebbe la soluzione più comune esistente - SSL / TLS.

La soluzione migliore sarebbe che gli utenti generassero il certificato client X509 firmato dal server per autenticarsi - perché allora l'app Web può semplicemente fare affidamento sul contenitore web (Catalina Tomcat, ApacheD, IIS, ecc.) per eseguire la crittografia e autenticazione per la tua applicazione.

Sotto il cofano Le chiavi OpenPGP hanno gli stessi esponenti RSA di un certificato X509, quindi strumenti come openssl possono convertire chiavi GPG / PGP in certificati X509 autofirmati *; lo stesso vale per chiavi SSH .

_{* Il web-of-trust OpenPGP si qualifica come "autofirmato" dal punto di vista X509 poiché X509v3 non può avere una catena di trust con radici multiple che sono stato in grado di determinare.}

Le risposte esistenti offrono buoni consigli: utilizza lo stack SSL nel browser.

Tuttavia, è effettivamente possibile fare esattamente ciò che vuoi, usando la crittografia JavaScript.

Esiste un'implementazione OpenPGP in JavaScript link Non posso garantire per la sua qualità.

Inoltre, è possibile che JavaScript HTML5 acceda ai file locali, ad es. link

Penso che sarebbe più una curiosità che un sistema pratico.