Qual è il modo migliore per proteggere l'accesso a un sito Web senza SSL o chiavi già condivise?

Vuoi che il server di destinazione sia in grado di accedere al nome utente e alla password, e non all'attaccante con lo sniffer. Quindi il server di destinazione deve essere in grado di fare qualcosa che l'aggressore non può fare. Dato che l'attaccante può acquistare lo stesso tipo di PC rispetto al server, quella potenza extra deve essere qualcosa che il server conosce, ma non l'aggressore.

Ehi, ci è tali dati: la password! Questo è il punto, non è vero? È davvero una chiave pre-condivisa tra client e server.

Le password sono piuttosto pessime, per quanto riguarda la chiave, a causa dei limiti del cervello umano. Tuttavia, si può lavorare con quello. I migliori protocolli disponibili sono Scambio chiavi autenticati tramite password : possono escalation di una chiave a bassa entropia condivisa (la password) in una chiave ad alta entropia condivisa, con la quale puoi fare tutte le cose gustose della crittografia simmetrica, che terrà a bada gli squali (filo). E i protocolli PAKE possono farlo resistendo agli attacchi del dizionario offline ("offline" è la parola importante qui).

La cattiva notizia è che i protocolli PAKE e, più in generale, qualsiasi protocollo di autenticazione che può essere collegato in seguito con i dati scambiati in modo che l'autenticazione resista davvero all'attacco dell'attaccante attivo, sono difficili da ottenere. Il protocollo più semplice ma ancora sicuro risulta essere SSL con SRP (c'è un RFC per quello). La buona notizia è che SSL + SRP fornisce autenticazione reciproca basata su password tra client e server utilizzando nessun certificato di sorta (e quando le persone dicono che non vogliono usare SSL, ciò che di solito significa è che non voglio dilettarti nei certificati X.509 e nel dannato mercato PKI).

Sfortunatamente, il supporto SSL + SRP non è molto diffuso ( GnuTLS è una libreria opensource che conosce SRP).

se usi l'hash del client, diventa password del sito e non hai ottenuto nulla.

Il modo migliore è utilizzare SSL . Il meccanismo esiste per una ragione. Gli schemi alternativi tendono ad essere insicuri o follemente complessi.

Hai detto che volevi farlo senza usare SSL, ma non hai fornito ragioni o ragioni per cui. Non hai spiegato la situazione in cui ti trovi o cosa giustificherebbe di evitare SSL. Di conseguenza, anche se volessimo fornirti alcuni suggerimenti alternativi, sarebbe impossibile determinare se soddisfano i tuoi requisiti.

Se tutto ciò che ti interessa è autenticare l'utente sul server (e non preoccuparti di crittografare i dati successivi), Lampash's Hash sarebbe facile da implementare in quanto esistono già librerie di funzioni hash implementate in Javascript e PHP / ASP / ASP.net.

L'Hash di Lamport è un tipo di schema di password monouso che funziona come segue (Alice è l'utente, Bob è il server):

Registrazione iniziale

Al momento della registrazione, Alice invia [n, hash ^ n (password)] al server (dove hash ^ n è il risultato dell'hashing della password, quindi esegue l'hashing del risultato, quindi esegue l'hashing del risultato, .. ., n volte). Il server memorizza [n, hash ^ n (password)] nel database.

Autenticazione

1. Alice invia il suo ID (username) a Bob: "Alice"
2. Bob risponde con "n"
3. Alice invia x = hash ^ {n-1} (password) a Bob
4. Bob confronta hash (x) con il digest memorizzato nel suo database
   • Se corrispondono, l'autenticazione ha esito positivo e Bob sostituisce [n, hash ^ n (password)] con [n-1, x = hash ^ {n-1} (password)]
   • Altrimenti, l'autenticazione fallisce e Bob conserva ciò che è nel database

Considerazioni pratiche

• Molto probabilmente vorrai usare un salt con la password (Bob può inviare il salt in # 2)
• Una volta che n è abbastanza piccolo, Alice dovrà cambiare la sua password (o possono semplicemente cambiare il sale), e dovrà re-inviare [n, hash ^ n (salt + password)] a Bob
• Scegli n sufficientemente grande in modo che la registrazione non sia troppo frequente
• Poiché si tratta di un'autenticazione unidirezionale (l'utente è autenticato sul server, ma il server non è autenticato per l'utente), è possibile utilizzare man-in-the-middle.

Se Lampash's Hash non soddisfa i tuoi requisiti (ad es. hai bisogno dell'autenticazione reciproca), SRP è probabilmente la soluzione migliore, ma nel momento in cui lo hai implementato in Javascript e PHP / ASP / ASP.net, potresti aver noleggiato un server che supporta SSL che è chiaramente la scelta migliore dall'inizio.

La risposta è TLS (nemmeno SSL) senza AES come algoritmo di crittografia, poiché esiste un problema noto con la combinazione di TLS, AES e WebSockets, ad esempio. Tutto il resto (come la crittografia della password nel client usando javascript) non è sicuro. Certo, non può essere letto direttamente usando wireshark ma il javascript può provenire da un uomo nel mezzo. quindi prova a convincere la tua scuola? per passare ai server TLS. Questo è il modo più semplice e non richiederà alcuna modifica del codice dell'applicazione.

Se è possibile eseguire JavaScript sul client, è possibile impostare uno scambio di chiavi Diffie-Helman o un meccanismo di richiesta / risposta basato sull'hash della password (non memorizzare il testo in chiaro sul proprio sistema!) e utilizzarlo per fare una fantasia processo di autenticazione in cui viene restituita una credenziale crittografata per l'autenticazione.

Questi non fermeranno gli attacchi MITM attivi, ma manterranno gli attaccanti passivi dallo sniffare le password.

SSL non può essere infranto come le password in chiaro. Usa SSL. Penso che Scheier abbia qualcosa da dire sulle persone che progettano i propri crittosistemi.

I don't like SSL because it's broken.

È un'affermazione piuttosto drammatica da buttare fuori senza spiegazioni né riferimenti di supporto. Intendi tutte le forme di SSL incluso TLS o specificamente SSL v1-3?

È molto meglio di molte altre soluzioni tentate al problema.

L'unico modo per stabilire comunicazioni sicure è tramite la crittografia - e per un client basato su browser, se non stai utilizzando la funzionalità integrata di SSL, allora stai fornendo il codice per implementare la crittografia (sia esso Javascript, activex , java, flash ....) su una connessione non protetta. Quindi il codice può essere compromesso. Non importa se utilizzi rot13 o una chiave a 4096 bit con un algoritmo PFS: se viene gestito da codice consegnato in modo insicuro, modificare il codice per acquisire la password è semplice.

Se pensi che SSL sia rotto, risolvilo: è un modo molto più proficuo per passare il tuo tempo.

La prima cosa che controllerei è se il server supporta l'autenticazione http con l'autenticazione digest. Potresti essere in grado di abilitarlo tramite php.

link

Non è sicuro come SSL, ma potrebbe essere un semplice trucco per impedire alle persone della tua classe di sfogliare le tue password. Usa http auth per bloccare l'area del sito che devi proteggere. Vedranno tutto ciò che stai facendo, ma non riceveranno la password di autenticazione http. (otterranno qualsiasi altra password all'interno della sessione)