Comunicazione sicura
Il protocollo di comunicazione deve essere sicuro. Se il canale di comunicazione non è sicuro, l'autenticazione non è sicura. TLS / SSL è un modo per proteggere il protocollo di comunicazione. Se non si utilizza TLS / SSL, sarà necessario creare un framework per creare un protocollo di comunicazione sicuro su un collegamento non protetto. Se eseguito correttamente (autenticazione del server, autenticazione del client, scambio sicuro delle chiavi, crittografia, autenticazione dei messaggi, gestione robusta dei downgrade, ecc.) Il protocollo sarebbe complesso. Per tutti gli scopi pratici si finirebbe per reinventare TLS / SSL.
Così come scritto solo # 4 e # 5 sono sicuri e per la maggior parte delle applicazioni # 4 dovrebbe essere la scelta primaria. Questo non vuol dire che devi sempre usare # 4 ma dovresti essere in grado di articolare chiaramente il motivo per cui in questo scenario # 4 è inferiore a un'alternativa.
Zero conoscenza (negabilità)
Una variante del n. 5 può essere utile in applicazioni di nicchia in cui la conoscenza zero o la negabilità sono requisiti di base del progetto. Comprendere che aggiunge ulteriore complessità, quindi se non si ha bisogno di denigrazione si sta costruendo un sistema più complesso senza migliorare la sicurezza. Maggiore complessità significa costi più elevati e maggiori possibilità di introdurre punti deboli che possono essere sfruttati.
Un esempio di dove sarebbe utile l'autenticazione a zero conoscenze sarebbe un servizio di backup online. Se il server ha le chiavi di crittografia, il servizio può essere costretto a rivelarle (potenzialmente in modo nascosto e senza il dovuto processo). Se il server non ha mai le chiavi di crittografia, non possono essere forzate a rivelare ciò che non sanno.
La crittografia dei file raw è piuttosto semplice. La chiave di crittografia viene generata dalla password dell'utente utilizzando un KDF. I file sono criptati lato client e trasmessi al server. Il server non ha mai la password o la chiave di crittografia dell'utente. La sfida è come autenticare l'utente (per verificare lo stato dell'account, la fatturazione, consentire i caricamenti, ecc.). Il processo predefinito dell'utente che invia la password (n. 4) sconfigge la crittografia dei dati lato client. Pertanto, il sito potrebbe richiedere all'utente di eseguire l'hash della password sul lato client e di fornirlo al server. L'hash dovrebbe essere prodotto in modo diverso dalla chiave di crittografia (stesso kdf ma diverso numero di round o stessa password ma un prefisso statico). Un miglioramento rispetto a quello che hai presentato sarebbe che il server non deve memorizzare direttamente l'hash di autenticazione dell'utente. Il server può memorizzare un hash dell'hash che impedisce la falsa autenticazione anche se l'elenco delle password è compromesso.
Crittografia asimmetrica per autenticazione
Un'opzione non elencata consisterebbe nell'utilizzare un certificato lato client per autenticare il client. La creazione, la gestione e l'archiviazione / backup sicuri del CERT devono essere fatti completamente dal lato del cliente o non ha senso. La chiave privata può essere crittografata con la password lato client per una maggiore sicurezza. TLS / SSL supporta i certificati lato client, quindi se questo è un requisito di progettazione, inizierei invece a reinventare la ruota. Un vantaggio dell'ECC rispetto a RSA è che è più amichevole con dispositivi a bassa potenza e con limitazioni di memoria come le smartcard, quindi questa soluzione sta diventando più realistica, sebbene la formazione degli utenti sia ancora una sfida.