Come dice il lama, c'è poco da fare nella pre-hashing della password sul lato client: SSL ti protegge. Ovviamente questo presuppone che tu usi SSL per tutte le comunicazioni; se non lo fai, hai già problemi molto più grandi che dovresti affrontare prima.
Se un utente malintenzionato vede "SHA-512 (password + long_string)", l'utente malintenzionato può eseguire un attacco di dizionario offline su tale password, ovvero provare i potenziali valori della password finché non viene trovata una corrispondenza. Naturalmente, questo presuppone che l'autore dell'attacco sappia "long_string" ma poiché sia il client che il server lo sanno, e non è stato inserito dall'utente umano, allora si deve assumere che "long_string" sia fornito dal server prima dell'utente autenticazione, o è codificata nel codice client. Ad ogni modo, è irragionevole supporre che l'attaccante non ce l'abbia. L'attacco del dizionario verrà eseguito al ritmo di diversi milioni di tentativi al secondo, perché, ammettiamolo, un PC di base è davvero bravo a calcolare SHA-512.
In una certa misura, se "long_string" è veramente lungo (stiamo parlando di megabyte qui), allora il costo dell'hash può diventare non trascurabile e quindi rallentare l'attaccante. Tale lentezza è la metà (ma solo la metà) di ciò che rende una buona funzione di hashing della password. Nota che gli algoritmi crittografici sono sottili: "SHA-512 (long_string + password)" sarebbe molto più debole, a tale riguardo, di "SHA-512 (password + long_string)" (se non vedi perché, allora non toccare quella tastiera di nuovo). La seconda metà del buon hashing delle password consiste nel dissuadere gli attacchi paralleli, che, in questo caso, significherebbe che ciascun utente ha il proprio valore "long_string", distinto da quello degli altri utenti. La "stringa lunga" funge quindi da salt .
La tua alternativa, con "SHA-512 (username + password)", fallisce nelle parti lente, e assicura imperfettamente la parte non parallela (perché i nomi utente non sono unici in tutto il mondo, e vengono riutilizzati anche quando l'utente cambia i suoi parola d'ordine). A seconda di come "long_string" viene scelto nel sistema originale, la tua proposta potrebbe indebolire o rafforzare la sicurezza.
La risposta alla domanda esatta è che se l'attaccante vede i valori entrambi allora può scegliere quale attaccare, e questo può solo aiutarlo. Tuttavia, una risposta più approfondita è questa:
- È necessario inviare le password solo attraverso un tunnel protetto correttamente (SSL), a quel punto non vi è alcun motivo valido per cancellare la password sul lato client; grazie a SSL, il client sa che sta inviando la password al server giusto e solo a quel server. Basta inviare la password "così com'è".
- Se prevedi di utilizzare l'hashing come meccanismo di archiviazione sul server (cioè il server esegue l'hashing, non il client e il risultato è memorizzato nel database del server), allora il tuo nuovo sistema potrebbe essere leggermente migliore del precedente o leggermente peggiore, ma entrambi sono comunque deboli. Leggi la risposta ; Sarebbe molto imprudente progettare sistemi crittografici con password finché non lo capisci a fondo (non hai bisogno di concordare - La scienza senza dibattito non è più scienza - ma almeno devi capire i concetti) .