Ad esempio, con Blowfish che restituisce qualcosa come:È sicuro archiviare un risultato PHP crypt() nel db?
$2a$12$DEzG.CRsHpxpTOAHooQ.wuR6Xe9h6PxFPhOcOvf.lqDNw1TVYVnEO
che contiene informazioni sul tipo di hashing ALG e contiene il sale. Molte risorse dicono di archiviare questo valore nel db e sarà sicuro. Ma qualcuno non potrebbe testare solo un elenco comune di password contro questi valori per crearne alcuni?
La sicurezza dell'hash delle password non viene dall'informazione nascosta. Hai già scartato il vero segreto, cioè la password che è la base per il valore hash. Il restante hash è semplicemente una sorta di impronta digitale di questi dati originali. La sicurezza deriva dal fatto che non è possibile ricavare i dati originali dall'hash. L'unica possibilità è provare tutte le password possibili e vedere quale produce lo stesso hash. La sicurezza qui deriva dal fatto che questo è molto dispendioso dal punto di vista computazionale e difficilmente riuscirà in un lasso di tempo utile.
Il sale viene introdotto solo per impedire a qualcuno di utilizzare un insieme già precompilato di password hash note, costringendo un utente malintenzionato a ripassare effettivamente tutte le password possibili con il sale unico. Il sale in sé non è segreto, né l'algoritmo di hashing.
In breve: sì, quel valore è assolutamente sicuro da memorizzare in un database.
L'hash generato da crypt() è specificamente destinato all'archiviazione. Qualunque sia il tuo schema di hashing delle password, se qualcuno si impossessa dei contenuti del tuo database, sarà in grado di forzare la tua password e non hai la possibilità di non memorizzare gli hash delle password. Gli algoritmi applicati da crypt() sono selezionati in modo specifico perché richiedono molto tempo per calcolare l'hash; questo non è evidente quando si prova solo una password, ma la forzatura bruta di migliaia di password diventa in modo non corretto lento.
Ma qualcuno non ha potuto testare solo un elenco comune di password contro questi valori per crearne alcuni?
Si può sempre fare indipendentemente dalla memorizzazione delle password. La funzione crypt non impedisce questo, ma lo renderà davvero molto lento. Se un utente usa una password veramente comune (come 123456) nessun algoritmo di hashing nel mondo lo proteggerà.
Se si disabilitano queste semplici password e si utilizza un buon algoritmo di hashing (quella fornitura di crypt()) si è fatto del proprio meglio per proteggere le password.
Se qualcuno ha accesso al tuo database, in tal caso, avranno accesso al sale in ogni caso, dal momento che dovresti utilizzare una password diversa per ogni password utente (che probabilmente memorizzerai nel database).
Il punto del sale è tale che i tavoli arcobaleno non funzionano. L'individuo dovrebbe re-hash ogni combinazione di password + sale per determinare la password. Si utilizza un sale diverso su ciascuna password, quindi deve rigenerare milioni di hash per ognuno.
altre buone informazioni sulla cripta si possono trovare qui: Why does PHP crypt() prepend the salt to the hash?
non è il vostro database sicuro? – CompanyDroneFromSector7G