¿Puedo consultar datos encriptados por filas en mi base de datos?

Navega tus respuestas
3

Por favor, avíseme si alguna de mis suposiciones es incorrecta.

Supongamos que tengo una base de datos, en la que todas las filas de una columna de base de datos se cifran en el nivel de la aplicación mediante una única frase de contraseña, "SECRETO", utilizando una derivación de clave basada en contraseña:

TantoelsaltaleatoriocomoelIVaseguranquecifrarlosmismosdatosparadosfilasdiferentesproducirádiferentesvalorescifrados.Sinembargo,siunatacantetieneaccesodelecturaamibasededatosypuedeforzarelcifradodeunasolafila,entoncessabríamifrasedecontraseña"SECRETO" y podría descifrar todas las filas cifradas.

¿Esto significa que el principal beneficio de usar un salt aleatorio y IV para cada fila es que oculta la frecuencia de los valores de mis datos cifrados? Por ejemplo, la desventaja de no usar un salt aleatorio e IV sería que un atacante podría mirar mi base de datos y ver "50 filas tienen un valor X, 49 filas tienen un valor Y, y una fila tiene un valor Z", pero no sabría qué ¿X, Y y Z en realidad lo son a menos que también puedan descifrar el cifrado? ¿Hay más razones para usar un salt / IV aleatorio por fila?

Digamos que necesitaba consultar mi base de datos para los valores que están cifrados. ¿El uso de un salt aleatorio e IV hace que la consulta "Dame las filas que tienen valor N" sea imposible? ¿Cómo puedo proteger mis datos con encriptación y seguir siendo capaz de consultarlos, y a qué tipo de amenazas comunes sería vulnerable?

    
pregunta Steven 19.05.2017 - 20:02
fuente

2 respuestas

2

En primer lugar, no es la frecuencia solo la que está protegiendo. Si el atacante descifró el valor X en su ejemplo, ahora conoce las 50 filas. Digamos que las filas son usuarios, y el valor cifrado es una contraseña. El atacante ahora acaba de explotar los 50 usuarios a la vez. Eso es más valioso que saber que 50 entradas eran iguales.

La sal aleatoria y la IV por fila no hacen que tu consulta sea imposible, en sí misma, pero sí lo hace realmente difícil sin hacer muchos otros giros. Busque el término "cifrado homomórfico", que ofrece varias formas de realizar algunas búsquedas sobre datos cifrados. En la práctica, esto no es realmente escalable, o se hace en producción, pero no es imposible.

enlace

"Cuánta seguridad" se sacrifica por la funcionalidad, es realmente una pregunta que solo usted puede responder. ¿Cuál es tu modelo de amenaza? ¿Cuál es el valor de los datos que están protegidos? La seguridad debe estar al servicio de sus objetivos comerciales, no un fin en sí mismo. Tiene un costo que debe ser menor que el valor que aporta. Si el atacante obtiene el control de su función de búsqueda, obtiene todos sus datos de cualquier manera.

En la práctica, si sus datos pueden caber en la memoria, su mejor opción podría ser descifrar los datos, buscar en la memoria sobre el texto sin formato y dejar los datos cifrados en el disco. Si no puedes, es posible que debas filtrar información parcial al dividir los datos almacenados en subchunks de tamaño de búsqueda.

No desea renunciar a la naturaleza de enmascaramiento del mismo texto simple que encripta a diferentes textos cifrados si su información protegida es algo como contraseñas o números de tarjetas de crédito. Cualquier cosa en la que un atacante pueda ejecutar un cifrado de reenvío puede usarse para un ataque de texto simple conocido.

Ejemplo: Baddie (con acceso de lectura a su base de datos, pero no el secreto) se registra en su servicio como usuario legítimo y le proporciona una "contraseña" como su contraseña. Luego, abre la base de datos, encuentra su propio registro y ahora conoce a todos los otros usuarios que también eligieron "contraseña". Muy mal.

    
respondido por el JesseM 19.05.2017 - 20:23
fuente
1

Sí, el propósito principal de usar un IV / salt es garantizar que la misma entrada a una función de cifrado / hash no produzca la misma salida. Si no usa un IV / salt aleatorio, el mismo valor cifrado / hash aparecerá de la misma manera en su base de datos.

No es imposible consultar datos encriptados, solo muy, muy lento. Si necesita usar el campo cifrado en una cláusula where, join o order by, tendrá que usar una función para leer el IV / salt y luego descifrar el valor fila por fila.

    
respondido por el user52472 19.05.2017 - 20:34
fuente

Lea otras preguntas en las etiquetas

Volatility.exe sugiere dos perfiles para el volcado de memoria de XP. ¿Cuál debo usar? ¿Desde dónde los productos como BlueCoat y ForcePoint obtienen las categorizaciones de URL?