La soluzione migliore, come è stato affermato, è ottenere un vero e proprio piano di web hosting che consenta https. Non dovrebbe essere troppo costoso, anzi dovrebbe anche essere possibile trovare un provider gratuito per fornirlo.
In caso contrario, qual è il tuo caso d'uso? Sembra che tu abbia in mente un determinato gruppo di utenti per il tuo sito web. Se è così e non offri solo un servizio di notifica degli eventi basato su abbonamento a persone casuali su Internet, valuta la possibilità di fornire le basi per una connessione "sicura" su un canale diverso.
per me che ottenere il codice sulla loro macchina da un'altra fonte affidabile (inviando CD tramite posta ordinaria e informandoli via e-mail, inviando semplicemente il software come allegato a un'e-mail con firma digitale, ecc.) consente di precaricare il software con una chiave pubblica crittografica.
È quindi possibile negoziare una connessione sicura su un metodo di connessione non sicuro (come http) poiché il codice che determina se il server ha decrittografato in modo soddisfacente i dettagli crittografati con la sua chiave pubblica vive il cliente. Il risultato è un flusso di dati di applicazioni http "in chiaro", con la grinza che i dati dell'applicazione stessa siano crittografati.
Si tratta di molti problemi e di un metodo non standard. Si verificano problemi con l'implementazione poiché poche persone lo avranno provato per offrire consigli e con la sicurezza poiché poche persone hanno verificato la sua affidabilità *.
Il canale alternativo stesso potrebbe avere problemi di sicurezza. La posta può essere intercettata? I truffatori potrebbero impersonare la tua organizzazione e inviare la loro versione "sicura" del tuo software? I tuoi utenti sono abbastanza esperti da controllare le firme digitali sulle e-mail che invii? Queste sono tutte preoccupazioni che dovrai considerare e accettare come rischi o tentare di mitigare con nuove soluzioni, poiché hai meno indicazioni non solo su come implementare, ma anche su quali domande devi porre (dovrai chiedere più di questi tre!).
Quando parli con la direzione della ONG, considera di delineare la situazione in questi termini:
- Quest'ultimo metodo comporta un rischio significativo e finirà per costare loro più del tuo tempo da implementare rispetto a quanto semplicemente pagare per l'hosting: il programma deve essere aggiornato, soprattutto se il server (o la coppia di chiavi del server) cambia e viene continuamente distribuito a nuovi utenti dopo la distribuzione iniziale.
- Non fare nulla e utilizzare una password http con indirizzi e nomi (e potenzialmente indirizzi e-mail) potrebbe essere un disastro delle pubbliche relazioni se qualsiasi informazione trapelasse (e lo sarà), un rischio significativo. Ciò è aggravato dal fatto che le persone riutilizzano le password e la tua cattiva pratica potrebbe essere collegata a violazioni successive.
- In quanto tale hai riflettuto in modo significativo sulla situazione e non hai solo intenzione di suggerire la soluzione delineata in passaggio 4 perché "lo fanno tutti" (sebbene, nel caso in cui lo facciano tutti perché è la migliore pratica, non è certo una cosa negativa). Essere in grado di proporre la soluzione alternativa (se contorta ed eccessiva) delineata nei passaggi 1 & 2 è la prova di questa due diligence in corso.
- Sulla base di ciò, l'hosting https con un costo continuo basso (o nullo) è sia l'approccio meno costoso CHE meno rischioso.
* Jonathan Gray spiega il perché incontrerai problemi nella codifica di un sistema sicuro nella sua risposta, guarda la sezione che inizia con "TLS è anche un sistema molto più intrinseco"