Una forma menos insegura de cifrar un campo en la base de datos para que aún pueda ser incluido en las consultas

Question

Una forma menos insegura de cifrar un campo en la base de datos para que aún pueda ser incluido en las consultas

#1 de Stephane (2 votos)
#2 de Four_0h_Three (1 votos)

3

Tengo una tabla donde todas las columnas deben estar cifradas (aparte de la PK). Esto se logrará utilizando AES en el nivel de aplicación. Sin embargo, hay un campo en particular que debe seguir siendo investigable.

Por ejemplo, una tabla de mensajes tiene:

MessageTitle (encriptado)
MessageBody (cifrado)
SenderID (cifrado pero coincidente)

Dado un texto simple, SenderID debería poder seleccionar todos los mensajes relacionados.

Algunas restricciones / decisiones:

Necesito cifrar los datos en reposo, incluida esta columna. No tengo otra opción.
El SenderID tiene un formato fijo, por lo que si elimino el valor, no sería difícil utilizar la fuerza bruta
He elegido cifrar campos específicos en lugar de toda la base de datos (TDE) para mitigar otras amenazas que no sean solo los discos robados.

Actualmente, mi solución preferida es cifrar el SenderID (y solo el SenderID) con un IV fijo. De esta manera, los datos se mantienen encriptados, pero aún podemos coincidir con ellos en las consultas.

Una desventaja de este enfoque es que los ataques de texto simple pueden ocurrir en los datos; Los DBA podrían crear registros con diferentes SenderID y tratar de encontrar un registro coincidente. Sin embargo, creo que esto se puede mitigar en el Servicio de cifrado con un control y control de acceso adecuados.

¿Esto parece una solución válida?

encryption databases sql-server

pregunta Dan Rowlands 16.07.2013 - 14:03

fuente

2 respuestas

1

Si es un hash, puedes calcular el hash y buscar usando ese valor ya que la misma frase hará el mismo valor de hash. Es posible que no necesariamente tenga que utilizar este hash, ya que asumo que SenderID es único, pero el uso de sal no es una mala idea. Además, ¿por qué solo tienen un ID de usuario y la contraseña? Si necesita poder buscar el cuerpo del mensaje, tendrá que recuperar los contenidos cifrados, descifrarlo y buscar una coincidencia.

Por ejemplo, la palabra bob siempre computará a 9f9d51bc70ef21ca5c14f307980a29d8 usando md5, de modo que si el ID del remitente es bob, el usuario ingresará bob. Su código codificará esa cadena y obtendrá 9f9d51bc70ef21ca5c14f307980a29d8, luego seleccione * del correo electrónico donde senderid = '9f9d51bc70ef21ca5c14f307980a29d8'

respondido por el Four_0h_Three 16.07.2013 - 14:37

fuente

Lea otras preguntas en las etiquetas encryption databases sql-server

¿Manejar datos HTTP sin cifrar para un sistema compatible con PCI - en el alcance de PCI DSS v3 pero no v2? C ++ memset () desbordamiento de memoria

score 2 · Accepted Answer

Teniendo en cuenta lo que nos has dicho, todavía usaría una función hash: eso es exactamente para lo que han sido diseñados.

Desafortunadamente, no puede agregar su valor de hash, ya que desea poder encontrar un registro específico basado únicamente en el valor de texto claro, pero aún puede usar un HMAC algoritmo para protegerse contra ataques directos: un atacante deberá tener acceso a la clave utilizada en el cálculo de HMAC para obtener un hash de un texto claro determinado: suponiendo que esté almacenando correctamente sus claves (probablemente el problema más crítico en dicha aplicación), su SenderID permanecerá oculto, pero podrá encontrarlo en cualquier momento con una simple búsqueda.

El uso de un HMAC también lo ayudará si su SenderID tiene una baja entropía (aunque no resolverá ESTO problema por completo).

Tenga en cuenta que cualquier persona que tenga (o pueda obtener) acceso a la clave utilizada en su cálculo de HMAC podrá intentar hacer coincidir un texto claro determinado con sus datos, pero creo que es algo que no puede evitarse.

Sin embargo, tenga en cuenta que, si bien puede (y debería) tener una clave diferente en cada instalación, NO podrá cambiar esa clave posteriormente o perderá la capacidad de encontrar sus registros. Una forma de evitar esto es agregar una versión cifrada de SenderID dentro de su registro: si necesita volver a escribir todo, puede usarlo para volver a calcular un hash nuevo.

Sin embargo, sugeriría que utilices una función hash moderna y sólida para tu HMAC. ( SHA-3 , por ejemplo, incluso si las especificaciones finales aún no se han publicado)