it-swarm-es.com

¿Vale la pena cifrar direcciones de correo electrónico en la base de datos?

Ya estoy usando hashing salado para almacenar contraseñas en mi base de datos, lo que significa que debería ser inmune a mesa del arco iris ataques.

Sin embargo, tuve un pensamiento: ¿Qué pasa si alguien consigue mi base de datos? Contiene las direcciones de correo electrónico de los usuarios. Realmente no puedo hacer esto, porque los usaré para enviar correos electrónicos de notificación, etc.

¿Debo cifrarlos?

43
Roger Lipscombe

Bruce Schneier tiene una buena respuesta a este tipo de problema.

La criptografía no es la solución a sus problemas de seguridad. Puede ser parte de la solución, o podría ser parte del problema. En muchas situaciones, la criptografía comienza al empeorar el problema, y ​​no está claro que el uso de la criptografía es una mejora.

Esencialmente cifrar sus correos electrónicos en la base de datos, "en caso de que" en caso de que esté realmente haciendo que la base de datos sea más segura. ¿Dónde están las llaves almacenadas para la base de datos? ¿Qué permisos de archivos se utilizan para estas claves? ¿La base de datos es accesible públicamente? ¿Por qué? ¿Qué tipo de restricciones de cuenta están en su lugar para estas cuentas? ¿Dónde está la máquina almacenada, que tiene acceso físico a esta casilla? ¿Qué pasa con el acceso remoto/acceso a SSH, etc., etc. etc.

Por lo tanto, supongo que puede cifrar los correos electrónicos si lo desea, pero si ese es el alcance de la seguridad del sistema, entonces realmente no está haciendo mucho, y en realidad hará el trabajo de mantener la base de datos más difícil.

Por supuesto, esto podría ser parte de una extensa política de seguridad para su sistema, ¡si es así, ¡genial!

No estoy diciendo que sea una mala idea, pero ¿por qué tener un bloqueo en la puerta de los puntos muertos en los puntos muertos que cuestan $ 5000 cuando pueden cortar la madera contrachapada alrededor de la puerta? ¿O entrar a través de la ventana que dejaste abierta? O incluso peor, encuentran la clave que quedó debajo del felpudo. La seguridad de un sistema es tan buena como el enlace más débil. Si tienen acceso de root, entonces pueden hacer lo que quieren.

Steve Morgan hace un buen punto de que incluso si no pueden entender las direcciones de correo electrónico, aún pueden hacer mucho daño (que podría mitigarse si solo habían seleccionado acceso)

También es importante saber cuáles son sus razones para almacenar la dirección de correo electrónico en absoluto. Podría haber ido un poco por la borda con esta respuesta , pero mi punto es ¿Realmente necesita almacenar una dirección de correo electrónico para una cuenta? Los datos más seguros son los datos que no existen.

51
roo

Me doy cuenta de que este es un tema muerto, pero estoy de acuerdo con la lógica de Arjan detrás de esto. Hay algunas cosas que me gustaría señalar:

Alguien puede recuperar datos de su base de datos sin recuperar su código fuente (I.E. Inyección de SQL, DB de terceros). Teniendo esto en cuenta, es razonable considerar usar un cifrado con una clave. Aunque, esto es solo una medida adicional de seguridad, no la seguridad ... Esto es para alguien que quiere mantener el correo electrónico más privado que el simplexto, En el marco de la oportunidad, algo se pasa por alto durante una actualización, o un atacante logra recuperar los correos electrónicos.

Imo: Si planea cifrar un correo electrónico, almacene un hash salado de él también. Luego, puede usar el hash para validar, y evitar la sobrecarga de usar constantemente el cifrado para encontrar una cadena de datos masiva. Luego, tenga una función privada separada para recuperar y descifrar sus correos electrónicos cuando necesita usar uno.

11
Nicholas Riley

En común con la mayoría de los requisitos de seguridad, debe comprender el nivel de amenaza.

¿Qué daño se puede hacer si las direcciones de correo electrónico están comprometidas?

¿Cuál es la posibilidad de que suceda?

El daño hecho si las direcciones de correo electrónico se reemplazan pueden ser mucho mayores que si están expuestas. Especialmente, si está, por ejemplo, use la dirección de correo electrónico para verificar que se restablece la contraseña a un sistema seguro.

La posibilidad de que las contraseñas siendo reemplazadas o expuestas se reducen mucho si los has hecho, pero depende de los otros controles que tenga en su lugar.

9
Steve Morgan

Yo diría que depende de la aplicación de su base de datos.

El mayor problema es, ¿dónde almacena la clave de cifrado? Porque si el hacker tiene un exceso de algo más que su DB, probablemente todos sus esfuerzos se pierdan. (Recuerde, su solicitud necesitará esa clave de cifrado para descifrar y cifrar, por lo que finalmente, el hacker encontrará la clave de cifrado y el esquema de cifrado usado).

Pro:

  • Una fuga de su DB solo no expondrá las direcciones de correo electrónico.

Contras:

  • El cifrado significa pérdida de rendimiento.
  • Asignación de acciones de base de datos será más difícil si no imposible.
4
Davy Landman

No confunde accidentalmente el cifrado con la ofuscación. Comúnmente los enviamos correos electrónicos para prevenir el spam. Muchos sitios web tendrán "webmaster _at_ mysite.com" para reducir la velocidad de los rastreadores de analizar la dirección de correo electrónico como un objetivo de spam potencial. Eso debe hacerse en las plantillas HTML, no hay valor para hacer esto en el almacenamiento de la base de datos persistente.

No ciframos nada a menos que necesitemos mantenerlo en secreto durante la transmisión. ¿Cuándo y dónde se transmitirán sus datos?

  1. Las declaraciones SQL se transmiten desde el cliente al servidor; ¿Está en la misma caja o sobre una conexión segura?

  2. Si su servidor está comprometido, tiene una transmisión involuntaria. Si está preocupado por esto, tal vez debería estar asegurando su servidor. Tienes amenazas externas, así como amenazas internas. ¿Todos los usuarios (externos e internos) están debidamente autenticados y autorizados?

  3. Durante las copias de seguridad, tiene una transmisión intencional a medios de respaldo; ¿Se hace esto utilizando una estrategia de copia de seguridad segura que cifra a medida que va?

3
S.Lott

Tanto SQL Server como Oracle (y yo también creo que otros DBS) admiten el cifrado de datos en el nivel de la base de datos. Si desea cifrar algo, ¿por qué simplemente abstraer el acceso a los datos que podrían estar cifrados en el lado del servidor de la base de datos y dejarlo el usuario, elegir si usa los datos cifrados (en este caso, el comando SQL será diferente) o no. Si el usuario desea obtener datos cifrados por el usuario, puede configurar el servidor de la base de datos y todo el trabajo de mantenimiento conectado con la administración de claves se realiza utilizando la herramienta DBA estándar, hecha desde el proveedor de DB y no de usted.

2
massimogentilini

Vale la pena cifrar datos en las bases de datos, no lo hace un poco más difícil, sino más difícil, pero es más difícil cuando se cifra de la manera correcta, así que detener la filosofía y cifra los datos confidenciales;)

1
user3491125

Una copia de mi respuesta en ¿cuál es la mejor manera y más segura para almacenar las direcciones de correo electrónico de usuario en la base de datos? , solo por el bien de la búsqueda ...


En general, estoy de acuerdo con otros diciendo que no vale la pena el esfuerzo. Sin embargo, no estoy de acuerdo en que cualquier persona que pueda acceder a su base de datos también pueda obtener sus llaves. Ciertamente, eso no es cierto para la inyección de SQL, y puede que no sea cierta para las copias de respaldo que de alguna manera se pierden u olviden. Y siento una dirección de correo electrónico es un detalle personal, por lo que no me importan el spam, sino sobre las consecuencias personales cuando se revelan las direcciones.

Por supuesto, cuando tiene miedo de la inyección de SQL, debe asegurarse de que dicha inyección esté prohibida. Y las copias de respaldo deben estar encriptadas.

Aún así, para algunas comunidades en línea, los miembros definitivamente no quieren que otros sepan que son miembros (como relacionados con la salud mental, la ayuda financiera, el asesoramiento médico y sexual, el entretenimiento para adultos, la política, ...). En aquellos casos, almacenando la mayor cantidad de datos personales posible y cifrada aquellos que se requieren (tenga en cuenta que el cifrado a nivel de base de datos no impide que los detalles se muestren usando la inyección de SQL), es posible que no sea una mala idea. Nuevamente: trate una dirección de correo electrónico como un detalle personal.

Para muchos sitios, lo anterior es probablemente no el caso, y debe enfocarse en prohibir SELECT * FROM a través de la inyección de SQL, y asegurándose de que los visitantes no puedan llegar a la información personal o de pedido de otra persona cambiando la URL.

1
Arjan

Realmente tiene que pesar su peor escenario de alguien que obtenga esas direcciones de correo electrónico, la probabilidad de que alguien lo obtenga, y su esfuerzo/tiempo extra necesario para implementar el cambio.

0
Matt Hanson

@Roo

Estoy de acuerdo con lo que está diciendo, pero ¿no vale la pena cifrar los datos para que sea un poco más difícil para alguien que lo consiga?

Con su razonamiento, sería inútil tener cerraduras o alarmas en su casa, porque también pueden comprometerse fácilmente.

mi respuesta :

Yo diría que si tiene datos sensibles que no desea caer en las manos equivocadas, probablemente debería hacerlo tan difícil como pueda para un hacker para obtenerlo, incluso si no es 100% tonto a prueba.

0
Patrik Svensson