2009-05-21 12 views
6

Quindi, gli hash sono utili perché cambiano le combinazioni password/nome login/valore salato in un codice che non può essere invertito. Il client invia questo hash al server. Il server confronta l'hash con un elenco di hash memorizzati per verificare se è possibile concedere l'accesso all'utente del client. Ma come posso impedire a un utente malintenzionato di intercettare la password con hash e scrivere il proprio client che invia questo hash al server?Mi manca qualcosa sull'utilità degli hash

risposta

10

Gli hash sono utili se qualcuno riceve una copia di backup del database o ottiene l'accesso in sola lettura al live db. Non possono quindi elaborare la password e inviarla al tuo sistema live. Questo è il motivo per cui li hai salt, in modo che un hacker con accesso di sola lettura non possa impostare la sua password e quindi cercare se qualcun altro ha la stessa password.

Come è stato sottolineato, non interrompono l'intercettazione delle richieste (Man in the middle attacks) per impedire che sia necessario utilizzare connessioni protette con crittografia e firma dei pacchetti. HTTPS & SSL sono i modi più comuni per farlo.

+0

La risposta del cartman è stata la più importante, ma tu mi hai aiutato a capire il difetto nel mio ragionamento. Grazie! – Dabblernl

1

si utilizza una connessione protetta al server e si invia la password in chiaro su di esso. il server lo blocca e lo confronta con l'hash nel db. il punto di hashing è che se la password del server db è compromessa, la password non può essere recuperata da esso.

1

Dipende dal metodo di intercettazione.

Se la macchina dell'utente è compromessa al punto in cui il software dannoso può leggere i propri cookie, beh, non c'è molto che si possa fare.

Per interrompere l'intercettazione della comunicazione di rete, assicurarsi di utilizzare SSL (ad es. HTTPS non HTTP). L'HTTP è probabilmente più vulnerabile in una rete domestica o aziendale, in particolare in una rete wireless protetta male. HTTPS ti darà una certa protezione contro una rete compromessa. Questo include anche sniffer di pacchetti su reti locali.

L'ultima opzione da considerare è computer utilizzati da più persone. Gli internet cafè sono un esempio. I PC di lavoro possono essere un altro. È possibile impostare un timeout basso per ridurre al minimo il rischio di questo.

Un'opzione che alcuni potrebbero obiettare è il filtraggio degli indirizzi IP, il che significa che si invalida la sessione se si ottiene una richiesta da un IP diverso. Questo è un approccio approssimativo che potrebbe causare più problemi di quanti ne risolva. Fondamentalmente ci sono molti casi legittimi in cui l'indirizzo IP dell'utente cambierà. Molte reti aziendali funzionano in questo modo. Il roaming wireless, inclusa la banda larga mobile, modifica frequentemente l'IP, in particolare quando l'utente si sposta (ad esempio su un treno).

2

Nessun hash non viene utilizzato in questo modo. Il client invia prima la password (suggerisco che SSL sia utilizzato), il server calcola quindi l'hash basato su quella password con salt e lo confronta con i suoi dati nella memorizzazione della password. In questo modo non è possibile per utenti malintenzionati impossessarsi delle password.

4

Nel caso di intercettazione man-in-the-middle possibile una soluzione semplice è un protocollo challenge-response.

La forma più semplice è la seguente: l'utente invia il suo nome al server, il server seleziona un numero casuale (challenge) e lo invia al client.Il client combina la password con la sfida in un modo predeterminato, blocca il risultato e lo invia al server. Il server fa lo stesso: combina e hash e controlla se ha lo stesso risultato del client inviato.

Ogni volta che viene selezionata una diversa sfida e quindi il valore calcolato sarà diverso anche per la stessa password, quindi il successivo invio del valore calcolato non porterà all'autorizzazione corretta.

Non è necessario memorizzare la password non elaborata sul server - potrebbe memorizzare solo l'hash della password e il client potrebbe anche utilizzare l'hash e combinare tale hash con la richiesta.

+0

Non ti richiede di memorizzare la password nel tuo server? Non è una buona idea, vero? – sybreon

+0

Non necessariamente, è possibile memorizzare solo un hash della password e il client utilizzerà anche l'hash anziché la password. Il punto chiave qui è la sfida che cambia ogni volta ed è combinata con la password o l'hash della password. – sharptooth

+0

Assicurati solo di usare una fonte di casualità correttamente decisa e sicura, altrimenti un determinato uomo nel mezzo potrebbe dedurre l'algoritmo del tuo numero casuale durante un periodo di monitoraggio e rompere il sistema con un semplice hash di password e un numero casuale :) – workmad3

1

In molti sistemi, il valore che viene sottoposto a hash non è statico, ma utilizza uno nonce ogni volta che viene richiesta un'azione che richiede l'autenticazione. Il server invia un valore univoco al client, che viene combinato con il segreto e l'hash. Questo può impedire di ripetere attacchi man-in-the-middle.

Problemi correlati