Diffida delle operazioni di hashing in cui le persone potrebbero determinare le caratteristiche dell'input. Una società ha utilizzato MD5 degli ID taxi per l'anonimizzazione, che è stata rapidamente annullata. Sì, è possibile prova qualche modifica hash fatta in casa che lo renderebbe meno ovvio di un semplice MD5, ma è sicurezza attraverso l'oscurità. Risoluzione quasi ogni funzione di hashing per ogni numero di conto a 8 cifre è banale, a quel punto i tuoi dati sono validi come testo in chiaro. Concatenare i numeri di conto con il codice di ordinamento non sarà molto meglio.

Quello che dovresti fare invece è creare una tabella / programma / qualsiasi cosa mappi i tuoi dati sensibili su ID casuali. Il tuo sistema richiederebbe l'accesso a quella tabella / programma per effettuare la conversione, puoi prendere le misure necessarie per proteggere quella tabella / programma (come la memorizzazione in un volume TrueCrypt) mentre lavori con i dati veramente anonimizzati.

Se consideri i numeri di conto bancario sensibili, allora sì vale la pena di eseguirne l'hashing.

Quando parliamo di hashing dovremmo sempre parlare di salare l'hash. In questo caso sarebbe dispendioso dal punto di vista computazionale pagare ogni hash separatamente, il che è l'approccio con cui dovresti sempre iniziare.

Dato che stai cercando di utilizzare questo valore come valore di ricerca basato sul testo semplice (numero di conto bancario + codice di ordinamento) se hai salato ogni riga individualmente, dovresti calcolare l'hash di ogni riga ricevuta usando il sale di ogni record individualmente. Questo rallenterebbe il processo da O (log (n)) a O (n) dove n è il numero di record che stai memorizzando.

Quindi suggerirei di avere uno solo di tutti i conti bancari, questo eviterà l'uso di tabelle arcobaleno generali per invertire il tuo hash, ma non impedirà a qualcuno di creare una tabella arcobaleno specifica per la tua applicazione. Quindi cosa occorrerebbe per memorizzare una tabella arcobaleno per tutti i possibili numeri di conto?

Ci sono 10 ^ 8 numeri di conto possibili e 10 ^ 6 possibili codici di ordinamento che danno 10^14 possibile (numero di conto + codici di ordinamento). SHA-1 richiede 20 byte da archiviare, quindi per memorizzare tutti i possibili hash per tutti i possibili bankccount + sortcodes prendi 20*10^14 byte che è 1819 Terabyte (TiB). Quindi sembra che creare un tavolo arcobaleno per invertire ogni hash sarebbe impossibile. SHA-256 richiederebbe 2910 TiB.

Vale la pena notare che questo sarà prenotabile da chiunque abbia una potenza di calcolo sufficiente, basata su SHA-256 e sulla velocità elencata qui ci vorrebbe un solo computer centrale circa 80 giorni per cancellare tutte le combinazioni di codice di ordinamento / numero di conto. Con un desktop moderno di altissimo livello, direi che questo potrebbe ridursi a giorni a cifra singola. Se ti interessa, puoi passare a una funzione hash più lenta come PBKDF2 ( guarda anche ) che puoi configurare per eseguire il più lentamente possibile.

Raccomandazione

Suggerisco di eseguire l'hashing di questi valori utilizzando SHA-256 o PBKDF2 e la funzione di hash utilizzando un global seme. Si prega di consultare il seguente pseudo-codice:

$salt = "A Random Long String I Did Not Copy From The Internet"
$iterations = 10000 // Make this number larger for the hash to be more secure/slower

function hashBankAccount($AccountAndSortCode){
    $result = hash("sha256", $salt . $AccountAndSortCode)
    // OR
    $result = hash_pbkdf2("sha256", $AccountAndSortCode, $salt, $iterations, 64);
    return $result
}

Puoi quindi memorizzare il risultato di questa funzione nel tuo database.