Tenga cuidado con las cosas de hash en las que las personas podrían determinar las características de la entrada. Una empresa usó el MD5 de los ID de los taxis para anonimizar, lo que se invirtió rápidamente. Sí, podría Prueba alguna modificación de hash casera que la haría menos obvia que solo un MD5 directo, pero eso es seguridad a través de la oscuridad. Solución de problemas casi cualquier función de hashing por cada número de cuenta de 8 dígitos es trivial, momento en el que sus datos son tan buenos como el de texto simple. La concatenación de los números de cuenta con el código de clasificación no será mucho mejor.

Lo que debes hacer en su lugar es hacer una tabla / programa / lo que sea que asigne tus datos confidenciales a IDs aleatorios. Su sistema requeriría acceso a esa tabla / programa para realizar la conversión, puede tomar medidas para asegurar esa tabla / programa (como almacenarlo en un volumen de TrueCrypt) mientras trabaja con datos verdaderamente anónimos.

Si considera que los números de las cuentas bancarias son confidenciales, sí, vale la pena incluirlos.

Cuando hablamos de hash, siempre deberíamos hablar de poner sal en el hash. En este caso, sería computacionalmente costoso que usted elimine cada hash por separado, que es el enfoque con el que siempre debe comenzar.

Cuando intente usar esto como un valor de búsqueda basado en el texto sin formato (número de cuenta bancaria + código de clasificación) si saldeaba cada fila individualmente, tendría que calcular el hash de cada fila recibida usando la sal de Cada registro individual. Esto ralentizaría el proceso de O (log (n)) a O (n), donde n es el número de registros que está almacenando.

Por lo tanto, recomendaría tener una sal en todas las cuentas bancarias, esto evitará que se usen tablas arco iris en general para revertir su hash, pero no evitará que alguien cree una tabla arco iris específica para su aplicación. Entonces, ¿qué se necesita para almacenar una tabla de arco iris para todos los números de cuenta posibles?

Hay 10 ^ 8 números de cuenta posibles y 10 ^ 6 códigos de ordenación posibles que dan 10^14 posible (número de cuenta + sortcodes). SHA-1 requiere 20 bytes para almacenar, por lo que almacenar todos los hashs posibles para todos los posibles bankccount + sortcodes tomar 20*10^14 bytes que es 1819 Terabytes (TiB). Así que parece que crear una tabla de arco iris para revertir todo hash no sería factible. SHA-256 requeriría 2910 TiB.

Vale la pena señalar que esto será reservable para cualquier persona con suficiente poder de cómputo, basado en SHA-256 y la velocidad aquí enumerados tomaría aproximadamente 80 días una sola computadora central para agrupar todas las combinaciones de código de clasificación / número de cuenta. Con una parte superior de la línea de escritorio moderno, supongo que esto podría reducirse a días de un solo dígito. Si esto le preocupa, puede pasar a una función hash más lenta como PBKDF2 ( vea también ) que luego puede configurar para que se ejecute tan lento como desee.

Recomendación

Recomendaría hacer hashing de estos valores usando SHA-256 o PBKDF2 y la función hash usando una semilla. Por favor vea el siguiente pseudo-código:

$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
}

Luego puede almacenar el resultado de esta función en su base de datos.