Come sostituire SSL / TLS?

Nessun SSL, nessuna sicurezza. Le cose nel mondo reale sono raramente semplici, ma qui è il caso. Questo è facilmente visibile come segue: qualunque cosa tu faccia in Javascript, sarà fatta in Javascript inviato dal server . Qualsiasi attaccante che è in grado di esaminare i dati può anche modificarlo a piacimento (ad esempio, il modo più semplice per spiare il Wi-Fi è eseguire il tuo falso punto di accesso, e quindi puoi naturalmente modificare tutti i dati così come vanno e vengono) ; quindi, un tale aggressore può semplicemente rimuovere o modificare qualsiasi soluzione basata su Javascript che si possa trovare e disattivarla. Oppure aggiungi un hook a anche invia la password in chiaro come parametro extra.

Ora, anche se potresti ottenere "Javascript sicuro" sul browser client, allora ti imbatterai in tutti i problemi che JavaScript cripto comporta e che sono dettagliati nell'articolo a cui ti colleghi. Ma questa è solo una considerazione secondaria, rispetto al difetto fondamentale spiegato sopra: senza SSL, non puoi assicurarti che ciò che viene eseguito sul browser client sia il tuo codice.

Cercare di gestire la password in modo sicuro su un sito Web non SSL è come cercare di eseguire la chirurgia cerebrale in sicurezza con solo un cucchiaino e un palanchino arrugginito. Basta non farlo. Se sono presenti dati sensibili che arrivano al sito Web (ad esempio nomi e indirizzi), è necessario applicare meccanismi di protezione ragionevoli. Se i dati non sono sensibili, allora perché avresti bisogno di password?

IMHO il generatore di numeri casuali è l'ultima delle tue preoccupazioni qui. Dal momento che il codice per invocare l'enceyption viene inviato in chiaro, è banale che qualcuno possa interagire con MITM.

Se il servizio richiede il livello di sicurezza fornito dalla crittografia e viene fornito da un sito Web, DEVE utilizzare HTTPS (e idealmente tutti gli elementi di sicurezza associati come cookie + httponly e HSTS sicuri).

L'unico modo per aggirare questo problema è scrivere un'app HTML5 (dove il codice viene scaricato raramente) - ma anche questo ha degli svantaggi significativi.

La soluzione migliore, come è stato affermato, è ottenere un vero piano di web hosting che consenta l'uso di https. Questo non dovrebbe essere troppo costoso, infatti dovrebbe anche essere possibile trovare un provider gratuito a fornire questo.

In caso contrario, qual è il tuo caso d'uso? Sembra che tu abbia in mente un gruppo di utenti per il tuo sito web. Se questo è il caso e non stai offrendo un servizio di notifica degli eventi basato su abbonamento a persone casuali su Internet, considera la possibilità di fornire una base per una connessione "sicura" su un altro canale.

Mi viene in mente che ottenere il codice dalla propria macchina da un'altra fonte affidabile (postare i CD via posta ordinaria e informarli via e-mail, semplicemente inviando il software come allegato a un'e-mail con firma digitale, ecc.) consente precarichi il software con una chiave pubblica crittografica.

È quindi possibile negoziare una connessione protetta tramite un metodo di connessione non protetto (ad esempio http) poiché il codice che determina se il server ha decodificato in modo soddisfacente i dettagli crittografati con la sua chiave pubblica risiede sul client. Un flusso di dati dell'applicazione http "in chiaro" è il risultato, con la ruga che i dati dell'applicazione sono crittografati.

Questo è un sacco di problemi e un metodo non standard. Vi imbattete in problemi con l'implementazione dal momento che poche persone lo hanno provato a offrire consigli e con sicurezza poiché poche persone hanno esaminato la sua affidabilità *.

Il canale alternativo può di per sé avere problemi di sicurezza. La posta potrebbe essere intercettata? I truffatori potrebbero impersonare la tua organizzazione e inviare la loro versione "sicura" del tuo software? I tuoi utenti sono abbastanza esperti per controllare le firme digitali sulle e-mail che invii? Queste sono tutte preoccupazioni che devi considerare e accettare come rischi o tentare di mitigare con nuove soluzioni, poiché hai meno indicazioni su non solo come implementarle, ma anche su quali domande devi porre (devi chiedere più di questi tre!).

Quando parli con la direzione delle ONG, considera di delineare la situazione in questi termini:

1. Quest'ultimo metodo comporta un rischio significativo e finirà per costare loro più tempo da implementare rispetto a pagare semplicemente per l'hosting: il programma deve essere aggiornato, specialmente se il server (o la coppia di chiavi del server) cambia e continuamente distribuito ai nuovi utenti dopo la distribuzione iniziale.
2. Non fare nulla e usare una password su http con indirizzi e nomi (e potenzialmente indirizzi e-mail) potrebbe essere un disastro nelle pubbliche relazioni se qualche informazione trapelasse (e lo sarà), un rischio significativo. Ciò è aggravato dal fatto che le persone riutilizzano le password e le tue cattive pratiche potrebbero essere collegate a violazioni successive.
3. Hai come tale dato il pensiero significativo della situazione e non stai solo andando a suggerire la soluzione delineata al punto 4 perché "tutti lo fanno" (anche se, nel caso in cui tutti lo fanno perché è la migliore pratica, questo non è una brutta cosa). Essere in grado di proporre la soluzione alternativa (se contorta ed eccessiva) delineata nei passaggi 1 e amp; 2 è la prova di questa due diligence condotta.
4. In base a questo, l'hosting https con un costo basso (o non) in corso è l'approccio meno costoso e meno rischioso.

* Jonathan Gray entra in perché ti imbatterai in problemi che codificano un sistema sicuro in sua risposta , guarda la sezione che inizia "TLS è anche un sistema molto più intrinseco"

Sostituisci prima il tuo host.

Ottenere i certificati SSL è più facile che mai grazie alle CA gratuite. LetsEncrypt , ad esempio, offre certificati di convalida del dominio SSL / TLS gratuiti in modo automatico purché tu possieda il nome di dominio. C'è più spiegazione in risposta di StackzOfZtuff sulle sue capacità.

Esistono istruzioni su come impostarlo sul sito della community con domande frequenti e un forum di assistenza.

Il problema con JS è la generazione di numeri casuali (che è vitale per la sicurezza della crittografia moderna). Sono disponibili librerie esistenti che aiutano a risolvere questo problema, ma è necessario assicurarsi che la libreria utilizzi crypto.getRandomValues così come la capacità di ottenere entropia dall'input umano (come l'attività del mouse o della tastiera). Ciò è particolarmente macchinoso per i dispositivi mobili, soprattutto se si considera il fatto che l'hardware stesso è meno capace di garantire la generazione casuale dei numeri.

Vorrei anche aggiungere un punto aggiuntivo su RSA. È possibile crittografare solo piccole quantità di dati con esso e l'importo dei dati è relativo alla lunghezza chiave utilizzata. Non solo, ma RSA è lento. Se hai bisogno di una discreta quantità di dati o stai facendo richieste multiple al server, ti consiglio di crittografare una chiave casuale (CSPRNG) con JS sul lato client usando la chiave pubblica del server e usando quella chiave per la crittografia simmetrica.

Modifica: TLS è anche un sistema molto più intrinseco che lavora molto duramente per proteggersi da ogni tipo di attacco. L'unico tipo di attacco che TLS non protegge efficacemente è una disconnessione forzata. Tutto, dall'autenticazione del server alla protezione man-in-the-middle alla protezione dagli attacchi di replay, viene gestito automaticamente da TLS a un livello non visto nemmeno dal programmatore medio di alto livello. Nella tua situazione, tieni presente che non puoi utilizzare connessioni TLS / (SSL) reali, il che è sfortunato. Ma vorrei chiarire che raccomando altamente contro qualsiasi implementazione personalizzata progettata per sostituire TLS.

Potenzialmente come ultima risorsa, in quanto non sarà buono come TLS end-to-end ... ma potresti forse inserire qualcosa come CloudFlare in primo piano per avere almeno TLS per l'endpoint del client?

Un'altra opzione è scrivere un plug-in del browser o uno script Tampermonkey (per ridurre il mal di testa multipiattaforma) e avere il codice JS pre-consegnato al browser. Lo dico solo come misura di ultima istanza.

Lo svantaggio evidente è che i tuoi utenti sono limitati a utilizzare quei computer che hanno già il plug-in o che devono scaricarlo di nuovo ogni volta che usano un nuovo dispositivo. Sarebbe anche difficile usare i dispositivi mobili con esso.