security - rojo - secure mail for gmail

¿Vale la pena cifrar las direcciones de correo electrónico en la base de datos? (10)

Ya estoy usando hashing salado para almacenar contraseñas en mi base de datos, lo que significa que debería ser inmune a los ataques de tabla rainbow .

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

¿Debería encriptarlos?

@Roo

De alguna manera, estoy de acuerdo con lo que estás diciendo, pero ¿no vale la pena encriptar los datos solo para que sea un poco más difícil para alguien obtenerlos?

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

Mi respuesta:

Diría que si tienes datos confidenciales que no quieres que caigan en las manos equivocadas, probablemente deberías hacerlo lo más duro que puedas para que un hacker lo obtenga, incluso si no es 100% infalible.

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 empeorando el problema, y no está del todo claro que el uso de la criptografía sea una mejora.

En esencia, el cifrado de sus correos electrónicos en la base de datos "por las dudas" no hace que la base de datos sea más segura. ¿Dónde se almacenan las claves para la base de datos? ¿Qué permisos de archivos se usan para estas claves? ¿La base de datos es accesible públicamente? ¿Por qué? ¿Qué tipo de restricciones de cuenta existen para estas cuentas? ¿Dónde se almacena la máquina, quién tiene acceso físico a esta caja? ¿Qué pasa con el acceso remoto / acceso ssh, etc. etc., etc.

Así que supongo que puedes encriptar los correos electrónicos si quieres, pero si ese es el alcance de la seguridad del sistema, entonces realmente no está haciendo demasiado, y en realidad harías 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; de ser así, ¡genial!

No digo que sea una mala idea, pero ¿por qué tener un candado en la puerta de Deadlocks''R''us que cuesta $ 5000 cuando pueden cortar el contrachapado de la puerta? ¿O entrar por la ventana que dejaste abierta? O peor aún, encuentran la llave que quedó debajo del felpudo. La seguridad de un sistema es tan buena como el eslabón más débil. Si tienen acceso de root, entonces pueden hacer lo que quieran.

Steve Morgan se da cuenta de que, incluso si no pueden entender las direcciones de correo electrónico, aún pueden hacer mucho daño (lo que podría mitigarse si solo tuvieran acceso SELECT)

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

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 en peligro?

¿Cuál es la posibilidad de que suceda?

El daño causado si se REEMPLAZAN direcciones de correo electrónico podría ser mucho mayor que si se EXPONEN. Especialmente si usted está, por ejemplo, usando la dirección de correo electrónico para verificar que la contraseña se restablezca a un sistema seguro.

La posibilidad de que las contraseñas sean reemplazadas o expuestas se reduce mucho si las hashaces, pero depende de qué otros controles tienes en su lugar.

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 (es decir, inyección de SQL, db de terceros). Con esto en mente, es razonable considerar el uso de un cifrado con una clave. Sin embargo, esta 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 texto sin formato, en caso de que algo se pase por alto durante una actualización, o un atacante logra recuperar el correos electrónicos

OMI: si planea encriptar un correo electrónico, también almacene un hash salado. Luego puede usar el hash para la validación y ahorrar la sobrecarga de usar constantemente el cifrado para encontrar una cadena masiva de datos. Luego, tenga una función privada separada para recuperar y descifrar sus correos electrónicos cuando necesite usar uno.

No confunda accidentalmente el cifrado con la ofuscación. Comúnmente ofuscamos los correos electrónicos para evitar el correo no deseado. Muchos sitios web tendrán "webmaster _at_ mysite.com" para ralentizar a los rastreadores al analizar la dirección de correo electrónico como un potencial objetivo de spam. Eso debería hacerse en las plantillas HTML: no hay ningún valor para hacer esto en el almacenamiento persistente de la base de datos.

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

Las declaraciones SQL se transmiten de cliente a servidor; ¿Está eso en la misma caja o sobre una conexión segura?
Si su servidor está en peligro, tiene una transmisión involuntaria. Si está preocupado por esto, entonces quizás debería proteger su servidor. Usted tiene amenazas externas así como amenazas internas. ¿Están TODOS los usuarios (externos e internos) debidamente autenticados y autorizados?
Durante las copias de seguridad tiene una transmisión intencional a los medios de copia de seguridad; ¿Esto se hace usando una estrategia de copia de seguridad segura que encripta como va?

Realmente tiene que sopesar el peor caso de alguien que obtenga esas direcciones de correo electrónico, la probabilidad de que alguien las obtenga, y su esfuerzo / tiempo extra necesarios para impli- car el cambio.

Tanto SQL Server como Oracle (y creo que también otros DB) admiten cifrado de datos a nivel de base de datos. Si desea encriptar algo, ¿por qué no simplemente abstrae el acceso a los datos que podrían encriptarse en el servidor de la base de datos y deja que el usuario elija si utiliza los datos cifrados (en este caso, el comando SQL será diferente) o no? Si el usuario desea utilizar datos cifrados, puede configurar el servidor de la base de datos y todo el trabajo de mantenimiento relacionado con la administración de claves se realiza utilizando la herramienta DBA estándar, creada por el proveedor de DB y no por usted.

Vale la pena cifrar los datos en las bases de datos, no lo hace un poco más difícil, pero es mucho más difícil cuando está cifrado de la manera correcta, así que detenga la filosofía y encripte los datos confidenciales;)

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 a algo más que su base de datos, probablemente desperdiciará todos sus esfuerzos. (Recuerde, su aplicación necesitará esa clave de cifrado para descifrarla y encriptarla para que eventualmente el hacker encuentre la clave de cifrado y el esquema de cifrado utilizado).

Pro:

Una filtración de su DB solamente no expondrá las direcciones de correo electrónico.

Contras:

Cifrado significa pérdida de rendimiento.
La asignación de acciones a la base de datos será más difícil si no imposible.

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

En general, estoy de acuerdo con otros que dicen que no vale la pena el esfuerzo. Sin embargo, no estoy de acuerdo con que cualquiera que pueda acceder a su base de datos también pueda obtener sus llaves. Eso ciertamente no es cierto para la Inyección SQL, y puede no ser cierto para las copias de seguridad que de alguna manera se pierden u olvidan. Y creo que una dirección de correo electrónico es un detalle personal, por lo que no me importaría el correo no deseado, sino las consecuencias personales cuando se revelen las direcciones.

Por supuesto, cuando tienes miedo a la inyección SQL, debes asegurarte de que dicha inyección esté prohibida. Y las copias de seguridad deben encriptarse por sí mismas.

Aún así, para algunas comunidades en línea, los miembros definitivamente no querrán que otros sepan que son miembros (como los relacionados con la salud mental, ayuda financiera, asesoramiento médico y sexual, entretenimiento para adultos, política, ...). En esos casos, almacenar tan pocos datos personales como sea posible y cifrar aquellos que son necesarios (tenga en cuenta que el cifrado a nivel de base de datos no impide que los detalles se muestren con la inyección de SQL), podría no ser una mala idea. Nuevamente: trate una dirección de correo electrónico como tal detalle personal.

Para muchos sitios, lo anterior probablemente no sea el caso, y debe enfocarse en prohibir SELECT * FROM través de SQL Injection, y asegurarse de que los visitantes no puedan acceder de algún modo al perfil personal de otra persona o solicitar información cambiando la URL.