Non puoi.

Per inviare informazioni in modo sicuro su un canale non protetto, è necessaria la crittografia.

La crittografia simmetrica è fuori uso, perché dovresti prima trasportare la chiave, cosa che non puoi fare in modo sicuro su un canale non protetto [*].

Questo ti lascia con la chiave pubblica crittografia. Ovviamente potresti tirare il tuo, ma non vuoi essere un Dave, quindi è fuori, il che ti lascia con HTTPS.

_{[*] Puoi ovviamente provare a utilizzare un canale sicuro per scambiare la chiave, ad esempio lo scambio fisico di una chiave. Quindi puoi utilizzare la crittografia a chiave segreta, come Kerberos.}

TLS è davvero l'unico modo per farlo.

Ma cosa succede se lo crittografo con JavaScript?

L'autore dell'attacco può modificare il JavaScript tu inviare al client, o semplicemente iniettare il proprio JavaScript che registra tutte le informazioni inserite.

Quindi userò CSP e SRI per impedire l'aggiunta di script e la modifica dei miei script.

Sono contento che tu stia utilizzando strumenti moderni per proteggere il tuo sito, ma SRI in un contesto non protetto in realtà protegge solo dalla compromissione di una risorsa esterna. Un utente malintenzionato può semplicemente modificare le intestazioni CSP e i tag SRI.

Non c'è davvero alcun modo per farlo senza utilizzare la crittografia dall'inizio e l'unico modo standard per farlo è usare TLS.

Anche se accetto che dovresti utilizzare HTTPS, puoi renderlo ancora più sicuro utilizzando il Salted Challenge Response Authentication Mechanism (SCRAM, vedi RFC 5802) per l'effettivo scambio di autenticazione.

Non è banale da implementare, ma il succo è che, invece di inviare la password al server, invii una prova al server che conosci la password. Dal momento che derivare la prova utilizza un nonce dal client e dal server, non è qualcosa che può essere riutilizzato da un utente malintenzionato (come sarebbe l'invio dell'hash stesso).

Questo ha alcuni vantaggi aggiuntivi nell'usare HTTPS con l'autenticazione di base che descrivi:

1. Il server non vede mai la tua password durante l'accesso. Se qualcuno è riuscito a inserire codice dannoso nel server, non saprà comunque quale sia la tua password .
2. Se è presente un bug nell'implementazione HTTPS (pensa a Heartbleed), gli aggressori non saranno comunque in grado di acquisire la tua password. Perché, anche una volta che TLS viene bypassato, la password non è disponibile.
3. Se, per qualche motivo, non puoi usare HTTPS, è meglio che inviare la password in chiaro. Un utente malintenzionato non sarà in grado di indovinare la tua password in base allo scambio. Detto questo, dovresti comunque utilizzare HTTPS, perché la difesa in profondità è migliore.

Tieni presente che questo è sicuro solo se il client è in grado di eseguire lo SCRAM calcoli senza scaricare codice dal server. Potresti fornire un client grasso o gli utenti potrebbero essere in grado di scrivere il proprio codice che controllano. Scaricare il codice SCRAM su HTTP darebbe a un utente malintenzionato l'opportunità di modificare il codice SCRAM per inviare la password in chiaro o per esporla in altro modo.

In questo caso dovresti assolutamente distribuire TLS.

Se decidi di inventare un sistema di sicurezza del trasporto su HTTP, alla fine finirai per implementare comunque un sottoinsieme della funzionalità TLS. Ci sono molte insidie ​​di cui essere consapevoli quando si progetta e si implementa un tale sistema, che vengono ulteriormente amplificate quando si sceglie di provare a implementare il sistema con un linguaggio che non offre molte funzionalità di sicurezza.

Anche se hai implementato una corretta implementazione di un protocollo crittografico in JavaScript (che è già una grande sfida) non puoi fare affidamento sul fatto che l'implementazione sia resistente agli attacchi temporali, e il tutto si interrompe se qualcuno ha gli script disabilitati (ad esempio con NoScript).

Come regola generale, dovresti scegliere l'implementazione che consiste dei componenti più semplici, ben compresi e affidabili che richiedono di scrivere la minor quantità di codice critico per la sicurezza. Per citare Andrew Tannenbaum:

Un numero sostanziale di problemi (nella sicurezza delle applicazioni) sono causati da software difettoso, che si verifica perché i fornitori continuano ad aggiungere sempre più funzionalità a i loro programmi, il che significa inevitabilmente più codice e quindi più bug.

Devo implementare un algoritmo di crittografia come la crittografia a chiave pubblica RSA?

Se stai pensando di provarlo, potresti anche fare il massimo e usare HTTPS. Dal momento che non sembri un esperto, la crittografia "rotolare la tua" avrà senza dubbio implementazioni errate che la rendono insicura.

In realtà è del tutto possibile.

La password deve essere hash sul lato client, ma non con una funzione statica. Il metodo seguente utilizza due passaggi ed è ispirato all ' autenticazione dell'accesso al digest:

NOTA: il server conserva un HMAC della password e la corrispondente Key ( Digest );

1. Il client inizia richiedendo un nonce al server, il server restituisce la Key e il Nonce”;
2. Client calcola: HMAC (HMAC ( Password , Chiave ), Nonce ) e lo invia al server;
3. Il server calcola: HMAC ( Digest , Nonce ) e lo confronta con il valore ricevuto.

Questo ti protegge dalla riproduzione.

L'interesse principale che vedo non è una protezione dalle intercettazioni, ma per essere completamente sicuro che la password in chiaro non verrà memorizzata su il server, nemmeno in un registro di sistema (vedi Twitter o GitHub).

Nota: HMAC può essere sostituito da PBKDF2.

Esiste effettivamente un modo per autenticare un utente su una connessione non sicura: protocollo SRP (Secure Remote Password). SRP è progettato specificamente per consentire a un client di autenticarsi su un server senza che un utente malintenzionato Man-in-the-Middle sia in grado di catturare la password del client o persino di riprodurre l'autenticazione per impersonare in seguito il client, indipendentemente dal fatto che l'autenticazione sia riuscita o meno. Inoltre, l'autenticazione riuscita con SRP crea una chiave segreta condivisa che sia il client che il server conoscono, ma un MitM no. Questa chiave segreta potrebbe essere utilizzata per la crittografia simmetrica e / o HMAC.

Tuttavia, ci sono una serie di limitazioni di SRP:

1. L'utente deve essersi registrato in alcuni moda, poiché il processo di registrazione richiede la trasmissione di materiale equivalente a una password (sebbene il server non abbia bisogno di memorizzarlo).
2. Sebbene sia sicuro tentare un accesso SRP con un server non affidabile (cioè, non esporrà la tua password a quel server e sarai in grado di dire che il server non aveva la tua password nel suo database), Non è sicuro caricare una pagina web di accesso da un server non attendibile (potrebbe inviare una pagina che cattura ogni tua battitura e la invia da qualche parte).
3. Sebbene l'autenticazione riuscita tramite SRP generi una chiave segreta condivisa sicura, il codice per utilizzare effettivamente questa chiave in un'app Web dovrebbe essere caricato da un server e un utente malintenzionato potrebbe manomettere il codice per rubare la chiave simmetrica e apportare modifiche alle richieste e alle risposte.

In altre parole, mentre SRP può essere utile in situazioni in cui hai un client fidato che non ha bisogno di scaricare il suo codice su una connessione non sicura e hai anche qualche altro modo sicuro per registrare gli utenti, SRP non è adatto per un'applicazione web. Le app Web scaricano sempre il loro codice dal server, quindi se la connessione al server non è sicura, un MitM (o un altro aggressore di rete, ad esempio qualcuno che falsifica DNS) può iniettare codice dannoso nell'app Web e non c'è niente che tu, la vittima, può fare al riguardo. Una volta che il codice è presente, può acquisire qualsiasi password o altri dati immessi, rubare qualsiasi chiave generata e manomettere le richieste inviate o le risposte che ricevi senza che tu lo sappia.

È certamente possibile inviare una password in modo sicuro utilizzando HTTP. C'è anche uno standard per questo. Si chiama HTTP-Digest ed è definito in RFC 7616. Fa parte delle specifiche HTTP da un po 'di tempo. Originariamente era stato progettato per utilizzare solo l'algoritmo MD5 message-digest ("hashing"), ma le revisioni successive dello standard consentono al client e al server di negoziare quale algoritmo utilizzare.

Sfortunatamente, ci sono molti problemi con HTTP-digest e il più lampante è che il server deve avere la password in chiaro . Pertanto, sebbene sia possibile comunicare le password in modo sicuro utilizzando HTTP, non è possibile archiviare in modo sicuro le password sul server mentre lo si utilizza. Quindi, fondamentalmente, non è utile.

Come altri hanno detto, sarebbe meglio implementare TLS perché risolve più problemi contemporaneamente ed è abbastanza compatibile con le versioni future.

Come altri hanno detto TLS! TLS! TLS! (e anche con una lunghezza di chiave decente)

Ma se devi usare HTTP e qualsiasi server per l'implementazione, è per uso programmatico o per uso umano? Se per uso umano, stai guardando l'autenticazione di base o basato sulla forma? E i tuoi usi sono in grado di applicare un po 'di logica? non può essere usato da Joe public. È necessario proteggere qualcos'altro o solo la password stessa?

In tal caso potresti essere in grado di guardare:

• Usa un pad / generatore di password una tantum (i telecomandi RSA non sono economici e se hai quel tipo di denaro da spendere puoi permetterti TLS)
• Qualche altra autenticazione a 2 fattori come gli SMS (non senza i propri problemi).
• Un semplice meccanismo di sfida / risposta per offuscare la password, ad esempio la pagina mostra due numeri nel testo (nemmeno etichettati in modo sfacciato), l'utente deve iniziare la password con un calcolo semplice come la differenza tra i due numeri aggiunti a ciascuna cifra di un PIN, magari con elementi casuali prima e / o dopo, ad esempio 98634572dkkgdld. La modifica dei numeri di sfida dovrebbe interrompere gli attacchi di replay che non vengono provati immediatamente, ma se un utente malintenzionato riesce a catturare un numero sufficiente di tentativi, potrebbe essere in grado di risolverlo. Non puoi inserire alcuna logica di offuscamento negli script rivolti agli utenti, perché sarà visto e se lo schema è troppo complesso i tuoi utenti ti odieranno ancora di più.

Io ancora così con TLS, tuttavia, i certificati sono economici (anche gratuiti) in questi giorni, quindi gli schemi di offuscamento contorti non hanno davvero motivo di esistere più.