C'è un vantaggio di sicurezza verso l'hashing di una password sul server? [duplicare]

Question

C'è un vantaggio di sicurezza verso l'hashing di una password sul server? [duplicare]

#1 da (2 voti)
#2 da (0 voti)
#3 da (0 voti)
#4 da (0 voti)

1

Sto lavorando su un sistema di autenticazione. Ora in questo sistema l'utente effettua l'accesso e invia una password con hash al server. È sufficiente o devo ripetere nuovamente la password?

Quindi fondamentalmente è questo password = > hash = > network = > hash = > database

più sicuro allora password = > hash = > network = > Banca dati? o l'hashing ha già cancellato le password in uno spreco di tempo e spazio?

o dovrebbe essere password = > network = > hash = > Banca dati?

Come bonus, una probabile futura espulsione è quella di far accedere gli utenti su un server remoto in cui i creditori devono essere salvati e utilizzati nelle future interazioni con il server, risultando in qualcosa del genere?

password = > network = > database1 = > network = > database2

questo significa dover avere 2 o 3 volte?

passwords hash

posta Thijser 11.08.2015 - 10:32

fonte

4 risposte

Leggi altre domande sui tag passwords hash

In che modo è possibile mitigare l'imitazione del compromesso chiave? Autenticazione del server durante l'handshake SSL

score 2 · Answer 1

Non c'è alcuna sicurezza aggiuntiva nell'hansare la password prima di inviarla al server, poiché ora questo hash diventerebbe la password. Ancora più importante è inviare la password su un canale crittografato (SSL / TLS) per impedire che venga inviata in chiaro e venga letta da altri sulla rete.

Per memorizzare la password dovresti fare hash + salt it, di nuovo per impedire che la password venga archiviata in chiaro. Se l'hashing fosse stato eseguito sul lato client e memorizzassi questo hash, sarebbe comunque come se avessi memorizzato la password in testo semplice, poiché questo hash è ora la password.

Quindi sempre hash (+ sale) la password sul server prima di memorizzarla.

score 0 · Answer 2

Dipende dal tipo di attacco.

Se l'attacco è di tipo man-in-the-middle, allora non avrà senso se lo si hash di nuovo prima che raggiunga il server, perché il primo hash era già trapelato.
Se l'attacco è sul lato server, sarebbe meglio mantenere password => hash => network => hash => database , poiché renderebbe il processo di brute-forcing più dispendioso in termini di tempo.
Se l'attacco è sul client stesso (ad esempio, alcuni keylogger sono installati sul computer client), allora tutti questi processi sarebbero uno spreco.

In questi giorni, solo l'hashing della password non è affatto affidabile . Dovresti esaminare il processo di salting per renderlo più affidabile e sicuro.

score 0 · Answer 3

Puoi usare scrypt , bcrypt o PBKDF2 per hashing e salendo le tue password prima di memorizzarle. L'hashing della password è l'atteggiamento di contenimento dei danni . Non lo vedo utile per rehash due o più volte. Puoi attaccare un hash sicuro usando una tabella arcobaleno , che puoi prevenire applicando un salt all'hash prima memorizzandolo. Vi consiglio di leggere questo post ( Perché gli hash salati sono più sicuri per memorizzazione password? ) per informazioni più dettagliate se sei interessato. Ho letto dei sistemi che utilizzano questo metodo e le loro password sono rimaste al sicuro per 20 anni anche se gli utenti hanno mantenuto la stessa password nel tempo.

score 0 · Answer 4

Se l'hash è inviato in testo normale, l'hashing prima dell'invio è lo stesso di niente; un utente malintenzionato può semplicemente intercettare l'hash e inviare una richiesta falsificata al server, concedendogli l'accesso. Se stai usando un qualche tipo di schema di crittografia (che dovresti), l'hashing due volte non ha senso.

Quello che dovresti fare è il seguente: ogni volta che invii la password al server la mandi protetta da un livello di crittografia. È possibile utilizzare HTTPS per questo scopo. Una volta che il testo cifrato raggiunge il server, viene decodificato e viene ottenuta la password in testo semplice. Questa procedura impedisce un attacco MitM, un utente malintenzionato che intercetta la password e la utilizza per l'autenticazione. Quindi, si desidera evitare di memorizzare la password in testo normale, nel caso in cui il database sia compromesso a un certo punto. A tale scopo, si hash la password e la si memorizza all'occorrenza quando richiesto (alla registrazione, ad esempio). Per autenticare, basta cancellare la password e confrontare il digest risultante con l'hash memorizzato.

Inoltre, è possibile implementare i sali hash per rendere più difficile l'operazione di cracking per coloro che riescono a ottenere gli hash memorizzati nel database.