Non dovresti mai provare a proteggere una "vera" applicazione web con uno schema che hai inventato da solo. In quanto tale, non dovremmo discutere gli aspetti pratici su come implementeresti o utilizzeresti effettivamente un tale metodo.

Funzionerà?

Il tuo schema non invia una password via cavo. Quello che salta subito fuori è che invii la chiave privata al server, che non fa mai nulla con essa , senza motivo. Sì, si suppone che sia ancora protetto dalla password, ma perché?

Come altri hanno sottolineato, la chiave privata dovrebbe rimanere con il proprietario.

Anche se si considera la crittografia della password della chiave privata, ci sono (almeno) i seguenti problemi:

• Distribuire la chiave privata nel proprio schema è essenzialmente lo stesso di rendere pubblico l'hash della password: chiunque può ora eseguire un attacco con dizionario offline contro la password della chiave; e nessuno può fermarlo.
• Ancora peggio, possono ottenere la chiave per un dato accesso , il che significa che possono controllare se un utente esiste e quindi attaccare la password per il nome utente.

Con una piccola modifica, il tuo schema sarebbe una forma molto semplice di autenticazione con chiave pubblica:

• Il client crea una coppia di chiavi e invia la chiave pubblica al server
• Per accedere, il server invia una stringa casuale.
• Il client firma la stringa e la invia al server.
• Il server verifica la firma per assicurarsi che il client abbia la chiave privata

Qualcosa di simile in realtà è già possibile in https utilizzando certificati client. La stessa cosa è usata per ssh.

Il meccanismo Challenge-Response menzionato da ThoriumBR è un altro modo di autenticare, sebbene l'implementazione qui descritta presupponga che il server memorizzi la password in chiaro, il che è molto più pericoloso che inviarla su una connessione crittografata.

Sarà "migliore"?

No. Lo scenario da cui vuoi difenderti è presumibilmente che qualcuno entri nella connessione https crittografata. Se presumi che sia così, non solo sarebbero in grado di leggere la password, ma anche di rubare il tuo cookie di sessione e tutti i dati mostrati nella tua sessione. In tal caso, l'attaccante ha già vinto, indipendentemente dal fatto che abbia letto o meno la password.

Potresti ovviamente utilizzare la tua crittografia e autenticazione, ma la domanda è perché pensi che questo essere migliore della connessione https?

Lo scenario realistico non è che qualcuno interrompa la connessione https, è che qualcuno si intrometta nel database del server e cerca di "recuperare" le password in un attacco offline. Questo è ciò da cui la maggior parte degli schemi di autenticazione cerca di difendersi.

Il pericolo con le password non è che siano intercettabili, ma che possono essere indovinate.

Cosa dovresti fare nella vita reale?

Per un'applicazione web "reale", usa un framework consolidato e una libreria di autenticazione ben nota. Non scriverlo da solo, perché è facile sbagliare e molto difficile avere ragione.

Non utilizzare nulla SHA per l'hashing delle password, utilizza una funzione di hashing della password dedicata come bcrypt o PBKDF2 per rendere gli attacchi più difficili (vedi anche questa risposta). Puoi anche utilizzare o aggiungere un meccanismo TOTP per la tua app, che è meglio di una semplice password.

Addendum

Hai aggiunto quanto segue dopo che ho scritto la mia risposta:

Il mio requisito è che l'unica cosa che gli utenti devono fornire per un'autenticazione corretta è il loro nome utente / password e nient'altro, indipendentemente dal dispositivo che stanno utilizzando o dal fatto che abbiano effettuato l'accesso su quel dispositivo prima.

Questo spiega perché vuoi inviare di nuovo la chiave privata al server, anche se non cambia il motivo per cui è una cattiva idea.

Potresti comunque utilizzare un meccanismo di risposta alla sfida, come suggerito da ThoriumBR. Esistono anche meccanismi avanzati di risposta alla sfida come SRP che utilizzano una matematica intelligente per evitare di memorizzare la password sul server.

Tuttavia, tutti questi meccanismi e anche l'hashing lato client (vedi questa risposta), hanno una cosa in comune:

devono eseguire codice sul lato client.

In un'app web, questo può essere solo Javascript inviato dal server. L'implementazione del lato client non è il problema (c'è anche una libreria OpenPGP), ma poiché ti preoccupi della sicurezza della connessione https, hai un altro problema:

Qualsiasi uomo al centro potrebbe quindi semplicemente iniettare codice dannoso lato client per rubare la password, rendendo obsoleto l'intero meccanismo intelligente.

Come hanno detto gli altri, le chiavi private non vengono condivise. punto. Altrimenti, sono chiamate chiavi pubbliche.

Ma: l'accesso crittografico è piuttosto standard. HTTPS supporta che:

Autenticazione utilizzando certificati client HTTPS; e tutti i browser moderni hanno i mezzi integrati per generare le chiavi necessarie quando richiesto.

Il tuo problema è già stato risolto; l'utente genera una coppia di chiavi, ti dà la sua chiave pubblica, mantiene la chiave privata e, al momento della connessione, il server chiede al client di dimostrare di possedere la chiave privata (essenzialmente, lasciandogli firmare qualcosa) .

Fatto !

Altri metodi stabiliti crittograficamente includono almeno un metodo di cui sono a conoscenza:

Accesso singolo tramite ticket Kerberos - questo è estremamente ampio -spread in intranet che utilizzano Active Directory. Ancora una volta, i browser moderni (almeno Edge, Internet Explorer e Firefox) lo supportano immediatamente, sia su Windows che su Linux (non ho provato su OS X o FreeBSD)

Anche se mi piace l'idea di PGP per il login, non è così che dovrebbe funzionare. La chiave privata deve rimanere sul lato client, sempre e non essere mai condivisa con nessuno. Questa configurazione incoraggia le cattive pratiche e fornisce un'istruzione errata su PGP.

Quello che potresti fare è chiedere agli utenti di caricare la loro chiave pubblica sul server e poi presentare loro un challenge (fondamentalmente, una stringa crittografata) all'accesso, che richiede la chiave privata e ovviamente la passphrase associata ..

Il problema è che poche persone conoscono PGP o hanno una seria inclinazione a usalo. Se puoi farlo, fallo.

Come ha detto Anonymous, la chiave privata deve essere sempre privata. L'invio della chiave privata a qualsiasi entità nega qualsiasi sicurezza fornita dal tuo accesso.

Fondamentalmente, ciò che stai progettando è chiamato autenticazione della risposta di sfida e può essere fatto anche senza una coppia di chiavi:

• Una parte (il server) genera un token casuale e lo invia all'altra

• L'altra (il client) concatena la propria password con il token, l'ha hash e invia indietro

• Il server conosce sia il token che la password, concatena quei valori, l'ha hash e confronta con ciò che il client ha inviato

Se desideri utilizzare una coppia di chiavi, puoi utilizzare la coppia di chiavi per firmare:

1. Genera un valore casuale R1 e invia all'utente

2. L'utente riceve R1 e lo firma utilizzando la sua chiave privata

3. Il server controlla la firma rispetto alla chiave pubblica dell'utente

Questo è tecnicamente facile da fare, ma dubito che la maggior parte degli utenti avrà il know-how necessario per generare una coppia di chiavi e utilizzerà il coppia di chiavi per firmare le cose.

Un approccio alternativo che implementa gli stessi concetti è SRP. Ignorando la matematica nel protocollo, l'idea è che quando un utente si iscrive il client genera un verificatore di password che è sufficiente per verificare le credenziali, ma non per agire come loro e lo invia al server per l'archiviazione.

Al momento dell'accesso, le parti si scambiano messaggi in base a valori casuali che alla fine portano al server utilizzando il verificatore memorizzato per garantire che il client abbia la password corretta. I messaggi che il client invia al server sono unidirezionali derivati ​​dalla password e dal valore casuale, quindi la password non viene mai inviata in rete. Il messaggio casuale dal server garantisce che i messaggi dal client siano validi solo per il tentativo di accesso corrente (impedisce a MITM di essere in grado di riprodurre i tentativi di accesso se HTTPS fallisce).

Mentre il protocollo è scoraggiante da implementare , ci sono implementazioni fuori dagli schemi là fuori, ad es AWS Cognito e il suo client JS SDK, quindi è pratico da implementare in qualsiasi app web.

Sebbene lo schema descritto nella domanda abbia un problema significativo nell'abilitare attacchi bruteforce offline contro la password, è possibile riprogettarlo senza questa vulnerabilità.

Ad esempio, si può generare private chiave direttamente dalla password. Ciò evita del tutto la necessità di memorizzare le chiavi private: fondamentalmente la password diventa la chiave privata.

Tuttavia, in un'implementazione pratica di un'applicazione web, dovresti eseguire la crittografia in javascript lato client. E se HTTPS come trasporto è danneggiato, è molto probabile che consenta anche di compromettere quel pezzo di javascript, fornendo la password in chiaro.

Un tale schema implementato correttamente sarebbe leggermente più sicuro della pratica standard corrente di testo in chiaro su https + hashing sul lato server. Ma senza una revisione approfondita, è facile commettere errori sottili ma critici nel codice di crittografia e sarebbe meglio spendere sforzi per proteggere altre parti dell'applicazione.

Questo esiste già.

OpenPGP ha "autenticazione" come possibile utilizzo della chiave e una chiave PGP può essere usata per autenticare una sessione SSH se gpg-agent è usato in modalità ssh-agent. Lo uso quotidianamente come soluzione single sign-on con una smartcard, ma non c'è motivo per cui non funzioni con una chiave normale.

Esistono anche vari plug-in che consentono di firmare i messaggi durante un Handshake TLS utilizzando gpg-agent, consentendo agli utenti di utilizzare la propria chiave PGP per l'autenticazione del certificato client SSL.

Poiché la chiave non lascia mai il dispositivo dell'utente, non è nemmeno necessario generare una nuova chiave, gli utenti possono basta registrarsi con la chiave esistente.

È necessaria un'infrastruttura PKI sufficiente sul lato server per decidere quali chiavi sono valide per quali utenti. La maggior parte dei servizi (ad esempio gitlab, github e launchpad) ti consentono di caricare la tua chiave pubblica in un modulo nell'editor del profilo utente.