it-swarm.it

Cosa trasferire? Password o hash?

Diciamo nel mio database che memorizzo le password con hash salt con un hash abbastanza costoso (scrypt, 1000 round di SHA2, qualunque cosa).

All'accesso, cosa devo trasferire sulla rete e perché? Password o hash?

È possibile proteggere tale accesso su un canale non crittografato come HTTP?

40
Konrad Garus

Se trasferisci l'hash dal client, ciò non offre alcun vantaggio in termini di sicurezza e rende inutile l'hash:
Se un utente può accedere inviando l'hash al server, allora hash è effettivamente la password.

61
AviD

Se il protocollo di autenticazione prevede l'invio al server di una password o di un hash della password, con semplice HTTP, questo è intrinsecamente molto debole, per due motivi:

  • Qualcuno che spia sulla linea potrebbe registrare ciò che il client invia. Se solo l'invio di questi byte concede l'accesso, l'utente malintenzionato potrebbe semplicemente inviarli di nuovo. È un attacco replay . Questo problema è ciò a cui allude @AviD nella sua risposta. Nessuna quantità di hashing lo risolverà. Alcuni protocolli tentano di correggere questo problema includendo una "sfida" dal server (un valore casuale, creato di nuovo per ogni connessione), da sottoporre a hash con la password sul client; ecco di cosa si tratta autenticazione HTTP Digest .

  • Anche se l'autenticazione ha funzionato, questo è ancora semplice HTTP, quindi qualsiasi dato verrà inviato dopo sarà vulnerabile alle intercettazioni e alle alterazioni degli attaccanti. Se il mezzo di trasporto non è protetto, l'autenticazione scoraggia solo gli attaccanti più poco sofisticati. Questo è dove HTTP Digest fallisce.

Pertanto, tu hai davvero bisogno di SSL (aka HTTPS), non solo per trasmettere la password o l'hash, ma anche il resto della conversazione tra client e server .


Di seguito suppongo che il protocollo sia eseguito all'interno di un tunnel SSL. Hai ragione a voler utilizzare un hash lento come bcrypt o PBKDF2; si noti che a salt è necessario anche per impedire la condivisione dei costi (ad es. tabelle pre-calcolate). L'hashing lento e salato viene utilizzato per far fronte alla debolezza intrinseca delle password. Ora, potresti voler scaricare alcuni degli sforzi di hashing sul client. Questo maggio funziona, ma solleva alcuni problemi pratici:

  • Poiché l'elaborazione della password deve includere un salt, uno nuovo per ogni istanza di password, il salt deve essere trasmesso al client, in modo che il client possa includerlo nell'hash che esegue. Ciò aumenta la complessità del protocollo: il client deve prima inviare il nome utente al server, quindi il server deve rispedire il salt e (solo allora) il client può iniziare a eseguire l'hashing della password. Si tratta di un ulteriore roundtrip di rete rispetto al solito "invia nome utente e password come one POST request".

  • L'hash lento riguarda l'accettazione di spendere molta CPU per ogni password, quindi l'attaccante anche deve spendere molta CPU per ogni password. Ma se la CPU esaurita è sul client, non possiamo aumentarla quanto vorremmo, perché: 1) ci sono client che hanno pochissima CPU (diciamo alcuni smartphone o tablet economici) e 2) il contesto Web implica usando Javascript, e le prestazioni di Javascript sono davvero pessime quando si tratta di hashing (diciamo almeno 20 volte più lento del codice C).

Pertanto la solita saggezza è che fare parte dell'hash della password sul client non vale la pena.

24
Thomas Pornin

Entrambe le opzioni non sono sicure.

Il trasferimento della password renderà il protocollo semplice. Il trasferimento dell'hash ti renderà vulnerabile agli attacchi di replay.

APOP è un'implementazione di accesso per il protocollo POP. Ciò consente al protocollo di mantenere la password privata da tutti i listener sulla rete. Uno svantaggio di ciò è che sia il client che il server devono conoscere la password in testo semplice, poiché si tratta del segreto condiviso. Prima di quello del protocollo sia il client che il server hanno <password> La comunicazione del protocollo è sostanzialmente così:

  1. Il client si connette al server e invia un token casuale (T1)
  2. Il server invia un token casuale (T2)
  3. Il client invia M = sha (T1 + T2 + <password: copia del client>) al server
  4. Il server controlla se sha (T1 + T2 + <password: copia del server>) corrisponde a M (l'hash appena ricevuto).

Qui, il server conosce sia la magia che la password ed è in grado di determinare se l'utente conosce la password corretta senza esporla a nessun ascoltatore.

La migliore pratica sarebbe quella di archiviare in modo sicuro gli hash nel database e fare affidamento su canali crittografati.

4