Estamos creando una aplicación base que necesita cifrar SSN, DOB, etc. ...
La aplicación se implementa en muchos clientes.
¿Está "OK" usar la misma clave SALT para el cifrado / descifrado AES?
Usted escribe Salt , pero sus ejemplos incluyen datos recuperables y usted menciona un algoritmo de cifrado: AES. La sal generalmente se agrega a los hashes para evitar colisiones y socavar el valor de las tablas de arco iris, como se menciona en otras respuestas. Sin embargo, las otras respuestas discuten las contraseñas, mientras que usted parece estar protegiendo los datos recuperables (SSN, DOB, etc.). Los hash, sal, verificadores de contraseña y tablas de arco iris no se aplican.
En su lugar, debe usar un IV (Vector inicial) con cifrados simétricos basados en bloques y CBC (Encifrado de bloques de cifrado) para evitar la misma clase de ataque que protege un Salt contra: ataque conocido de texto simple del material criptográfico.
Por ejemplo, Mary y John tienen la misma fecha de nacimiento (por ejemplo, el 1 de mayo de 1984). Si tiene una clave maestra para cifrar todos los datos y no utiliza IV aleatorios, cualquier persona con acceso al cryptext en la base de datos puede ver que ENC(Mary_BDATE, Key) == ENC(John_BDATE, Key) .
Sin embargo, con IV aleatorios únicos, entonces ENC(Mary_BDATE, Key, IV1) != ENC(John_BDATE, Key, IV2) . Aquí, el IV (como una sal) se almacena con el cryptext en claro, no es necesario mantenerlo en secreto.
Por cierto, puede obtener el mismo efecto de un IV único al anteponer los datos de texto sin formato con un bloque de tamaño Nonce. Es decir, ENC(Nonce1||Mary_BDATE, Key) != ENC(Nonce2||John_BDATE, Key) . En este caso, cuando descifras, descartas el Nonce prefijado. No hay necesidad de almacenarlo ya que es el primer Bloque en el cryptext.
Tenga en cuenta que, en cualquiera de los casos anteriores, el requisito de almacenamiento es esencialmente el mismo: las longitudes IV y Nonce deben ser iguales y ambas tienen la misma longitud que el tamaño del Bloque. Hay algún beneficio al usar una IV sobre la preparación previa de Nonce, ya que el texto sin formato del paso Descifrar no requiere manipulación.
Además, realmente debería usar IV únicos para todos sus datos, incluso si cree que los datos podrían ser únicos (por ejemplo, en el caso de SSN). En primer lugar, el SSN es un rango de valores relativamente pequeño, por lo que no hay muchas opciones para el cifrado del texto simple. Más importante aún, debido a que la longitud del texto simple es tan pequeña, puede haber algunos ataques de compromiso clave conocidos en un campo tan pequeño. En general, los cifrados de bloque simétricos están diseñados para resistir este tipo de ataques. Sin embargo, cuando los datos son todos menos que (y mucho menos que) una longitud de bloque, solo hay mucho que puede hacer el cifrado. Al agregar un IV aleatorio, distribuye el cifrado en dos bloques y agrega más entropía al cryptext. Esto hace que el ataque de texto simple conocido y varios ataques clave sean más difíciles.
NO está bien.
Alguien puede obtener su sal, construir una tabla de arco iris y descifrar fácilmente todos los datos de todos los clientes. El objetivo principal de una sal es negar los efectos de las tablas de arco iris.
Ni siquiera debería usar la misma sal con un cliente. Solo genera una nueva sal con cada nueva clave. Puede almacenar el texto cifrado y la sal en conjunto, no es necesario proteger la sal.
Daré un ejemplo de por qué deberías usar diferentes sales para cada entrada en un escenario común de un atacante que llegue a tu base de datos.
Di que soy un atacante que acaba de conseguir tu base de datos. Ya que usted, el desarrollador consciente de la seguridad, hasheado todas las contraseñas, debería ser difícil para el atacante obtener las contraseñas y darles a los usuarios el tiempo suficiente para cambiar sus contraseñas, ¿no?
¡No es así! Resulta que tengo una colección bastante grande de hash precomputados para las entradas con una longitud de n chars a n + k chars (GBs y GBs de datos ... tarda mucho tiempo en producir esto una vez) y probaré todos los diferentes usuarios en su contra .
Viste esto y decidiste usar un salt en todas las entradas para el hashing de contraseñas, aunque es el mismo.
No importa, pasaré mucho tiempo intentando forzar la contraseña para 1 usuario y luego de un par de días o semanas (puede ser menos si usa las 1000 contraseñas más populares y solo el valor de sal) forza diferentes contraseñas obtengo esto: mysaltp@ssw0rd . Ahora recomputo mi tabla hash con mysalt al comienzo de cada entrada (esto solo toma aproximadamente la primera vez que calculé mi tabla hash). Luego procederé a encontrar la contraseña para cualquier usuario que haya usado una contraseña de longitud n a n + k caracteres.
Si usas un sal diferente para cada uno, tengo que recalcular cada combinación de contraseña única entre n chars y n + k chars con el hash agregado que lleva a significativamente más. Además, un huevo podrido (el usuario que usó password1234 como su contraseña) no estropeará el grupo y hará que sea mucho más fácil obtener las contraseñas.