email - plugin - plantillas contact form 7
¿Cuál es la mejor y más segura manera de almacenar las direcciones de correo electrónico de los usuarios en la base de datos? (10)
Por razones de seguridad, ¿vale la pena cifrar los correos electrónicos de los usuarios antes de colocarlos en la base de datos?
Sé que tenemos contraseñas de hash y salt, pero esa es otra historia, ya que realmente no necesitamos contraseñas originales. Con los correos electrónicos es diferente.
Sabiendo que la clave de descifrado estará en cualquier lugar cerca de la base de datos, ¿tiene sentido cifrar los correos electrónicos? Supongo que si alguien se mete en el sistema, también encontrarán la clave, si no inmediatamente, eventualmente.
¿Cuáles son las mejores prácticas? ¿Hay otras opciones disponibles si ejecuto mis propios servidores y no en un alojamiento compartido / virtual?
EDITAR: Tengo la intención de utilizar SQL Server. Y no, no es un software corporativo con requisitos de seguridad, solo un sitio de entretenimiento que tengo en mente.
Una de las cuestiones más frecuentemente citadas en la seguridad informática es que la única computadora verdaderamente segura es una que está enterrada en concreto, con la alimentación apagada y el cable de red cortado.
Con esto en mente, ¿la mejor manera de almacenar de forma segura las direcciones de correo electrónico? ¡No los guarde en absoluto!
tl; dr ¿Necesita su dirección de correo electrónico o una forma de enviarles correos electrónicos? Confíe en alguien que hará un mejor trabajo que usted o no use la dirección de correo electrónico en absoluto.
¿Por qué necesita mantener un registro de la dirección de correo electrónico de un cliente? Las únicas razones por las que me he encontrado son:
- Confirmación de cuenta y autenticación
- Correos electrónicos de transacción y marketing
Confirmación y autenticación
El núcleo de lo que queremos es la autenticación en dos pasos: algo que ellos saben y algo que tienen. Algo que saben es una contraseña y es fácil de probar, ya que serán los únicos que lo saben. Algo que tienen es más difícil de probar y tradicionalmente usamos una dirección de correo electrónico ya que es fácil de verificar. Estos días aunque hay otras cosas que podemos usar:
- Teléfono móvil
- Una cuenta con un sitio web de confianza (Facebook, Google, Twitter)
La verificación del teléfono móvil es simple. Envíeles un sms usando un servicio como twilio.com y pídales que le twilio.com un código de confirmación. Ahora sabemos que el móvil pertenece al cliente que quería registrarse. Con OpenID puede verificar las cuentas existentes con otros sitios de confianza, y el proceso de confirmación es manejado por ellos.
Para que el cliente se autentique, todo lo que proporcionan es su número de teléfono móvil y contraseña, o un token de autenticación OpenID. Tampoco se requiere una dirección de correo electrónico (bueno, el proveedor de OpenID podría, pero esa no es su responsabilidad).
Si estas no son una opción, aún puede confirmar una dirección de correo electrónico y luego usarla para la autenticación. La confirmación solo requiere que se almacene un token único y que se envíe un enlace a la dirección de correo electrónico. Almacene un hash con sal de la dirección de correo electrónico y utilícelo para hacer coincidir la cuenta de la misma manera que hacemos las contraseñas.
Transacción y correos electrónicos de marketing
La verdadera razón por la que queremos almacenar la dirección de correo electrónico! Así que podemos enviarles ofertas de cosas que creemos que necesitan para que puedan eliminarlas sin leerlas. En serio, ¿es el correo electrónico el mejor medio para esto? Si tenemos una cuenta de OpenID, ¿por qué no usarla para las notificaciones? Envía un mensaje de Facebook o escríbelo en su muro, envíalo en Twitter, envía un mensaje de texto a su teléfono móvil, crea una aplicación y envía notificaciones. Hay tantos canales mucho más efectivos que el correo electrónico.
Si desea utilizar el correo electrónico, utilice una plataforma de correo electrónico como Mandrill y MailChimp . Cuando se registren, cree un suscriptor en una lista de correo en MailChimp. Almacena la identificación del suscriptor con la cuenta. Para los correos electrónicos de transacción (restablecer contraseña, actualizaciones de cuenta), busque al suscriptor y pase el correo electrónico almacenado a Mandrill para enviar el correo electrónico. Para mercadeo masivo solo envíe a la lista de correo en MailChimp.
Lo único que está almacenado en la base de datos es la identificación del suscriptor. También ofrece todos los beneficios de usar una plataforma de correo electrónico, anular la suscripción, abrir y hacer clic a través de tarifas, seguimiento de comercio electrónico, etc. Las plataformas de correo electrónico harán un mejor trabajo de entrega de correos electrónicos que usted. También harán un mejor trabajo para proteger la privacidad de sus datos que usted. Permítales hacer el trabajo duro de la seguridad de la base de datos para que pueda concentrarse en obtener más clientes.
Creo que cuando la gente puede entrar en tu base de datos, de todos modos estás jodido :)
No tiene mucho sentido simplemente cifrar sus direcciones de correo electrónico. Además de que habrá una gran cantidad de otra información en su base de datos que no le gustaría que se recopile, la clave de descifrado estará al alcance al mismo tiempo que su base de datos está abierta.
Me gustaría sugerir que encuentre su nivel de seguridad e integridad de datos en un nivel superior. Así que la prevención de personas que ingresan a tu base de datos.
¿Y por qué serían tan importantes las direcciones de correo electrónico? La mayoría de las personas de todos modos recibirán spam o sus direcciones de correo electrónico estarán disponibles en algún lugar de la web.
Depende de la frecuencia con la que accedas a las direcciones. Si los lees de vez en cuando, podría tener sentido, pero este sería uno de los últimos problemas de seguridad en los que pasaría tiempo.
En general estoy de acuerdo con otros diciendo que no vale la pena el esfuerzo. Sin embargo, no estoy de acuerdo con que cualquier persona que pueda acceder a su base de datos también pueda obtener sus claves. Eso ciertamente no es cierto para la inyección SQL, y puede no serlo para las copias de respaldo que de alguna manera se pierden u olvidan. Y siento que una dirección de correo electrónico es un detalle personal, por lo que no me importaría el spam sino las consecuencias personales cuando se revelen las direcciones.
Por supuesto, cuando tiene miedo de la inyección SQL, debe asegurarse de que dicha inyección esté prohibida. Y las copias de seguridad deben estar encriptadas.
Sin embargo, para algunas comunidades en línea, los miembros definitivamente no quieren que otros sepan que son miembros (como los relacionados con la salud mental, la ayuda financiera, el asesoramiento médico y sexual, el entretenimiento para adultos, la política, ...). En esos casos, almacenar la menor cantidad de información personal posible y cifrar los que se requieren (tenga en cuenta que el cifrado a nivel de la base de datos no impide que los detalles se muestren mediante inyección de SQL), puede que no sea una mala idea. Una vez más: tratar una dirección de correo electrónico como tal detalle personal.
Es probable que este no sea el caso para su sitio de entretenimiento, y debería concentrarse en prohibir SELECT * FROM través de Inyección SQL, y asegurarse de que los visitantes no puedan acceder de alguna manera al perfil personal o la información de pedidos de otra persona cambiando la URL.
Encriptar el contenido de la base de datos siempre es una consideración delicada. Claramente, el contenido es inútil a menos que se pueda descifrar, y si eso tiene que suceder sin la intervención humana, entonces está almacenando tanto el texto cifrado como la clave en algún lugar. Si ese lugar está en la misma máquina, entonces uno podría preguntarse por qué te molesta.
Bueno, hay algunas razones por las que podrías querer hacer esto. Uno es porque se le exige que lo haga debido a alguna política de la compañía. Otra es que tal vez su base de datos esté alojada en un entorno más hostil que la máquina que accede a ella.
En general, el cifrado del contenido de la base de datos no le hará ganar ningún premio, pero si puede justificarlo, entonces claramente tiene al menos algo de motivación para hacerlo.
Esperemos que esta respuesta también responda a tu pregunta.
¿Vale la pena cifrar las direcciones de correo electrónico en la base de datos?
En resumen, no, no vale la pena cifrar las direcciones de correo electrónico del usuario. Tienes razón al pensar que un compromiso con la base de datos probablemente resulte en que alguien también obtenga acceso a las claves necesarias para romper tu cifrado.
No cifro los correos electrónicos de los usuarios. El punto es proteger la base de datos; Las claves son accesibles de todos modos si realmente desea utilizar los correos electrónicos una vez que están almacenados.
Verifique la dirección para la validez y la posible inyección de SQL, sin embargo.
Sí, podría ser útil para el usuario si lo hash con sal. Tenía un código antes del cual utilicé el uso de sal y hash, luego puedo descifrarlo. El flujo es que una vez que el usuario lo registre, lo procesará y lo procesará (cifrado). Entonces, si necesita recuperar los datos cifrados, habrá descifrado.
Si el servidor de la aplicación y la base de datos están en servidores separados, generalmente aumentaría la seguridad al tener toda o parte de la base de datos cifrada.
Incluso si están en la misma máquina, es posible que un pirata informático no descubra dónde se almacena su contraseña (aunque no me gustaría confiar en eso).
Por lo general, no cifraría los correos electrónicos en el nivel de la aplicación, sino que dependía del cifrado de toda la base de datos que ofrece la mayoría de las bases de datos empresariales.
Por supuesto, si está usando algo como MySQL, entonces no tiene más remedio que hacerlo en el nivel de la aplicación.
Normalmente les digo a mis clientes que no vale la pena cifrar una base de datos, sin embargo, si tiene requisitos de privacidad más estrictos, puede que tenga sentido hacerlo.
Si va a necesitar la dirección de correo electrónico en el futuro, tendrá que almacenarlos en texto sin formato.
Por supuesto, puede cifrarlos, sin embargo, esto es efectivamente la seguridad a través de la oscuridad en este caso. Básicamente, si el perímetro de su aplicación es seguro, sus datos dentro de él pueden ser de texto simple. El cifrado aquí le agrega complejidad al trabajar con los datos, pero en realidad no impide que un atacante obtenga sus datos en bruto.
Como usted dice, si atraviesa sus defensas perimetrales, es probable que obtenga fácilmente su clave de descifrado para descifrar los datos del correo electrónico. El cifrado puede ralentizar ligeramente al atacante determinado, pero no agregará ninguna seguridad real a sus datos.
El mejor escenario es escribir la dirección de correo electrónico (¡con sal!) Y almacenarla. Esto le permite verificar la dirección de correo electrónico contra un valor de entrada (por ejemplo) y verificar que la entrada de la dirección de correo electrónico sea la misma que la que almacenó; por supuesto, la principal desventaja de esto es que no puede saber cuál es el correo electrónico. la dirección no tiene ese valor adicional, por lo que si desea (por ejemplo) enviar un correo electrónico a sus usuarios con regularidad, no tendrá suerte.
Sospecho que está almacenando la dirección de correo electrónico porque es información útil, y querrá hacer algo con ella (como enviar un correo electrónico :), en cuyo caso, el cifrado solo aumenta la sobrecarga al trabajar con esa información, mientras que obtiene muy poco a cambio. .
En este caso, me concentraría en asegurar el acceso a la base de datos en sí (es decir, sus defensas "perimetrales") y me aseguraré de que sean lo más fuertes posible, al tiempo que deja los datos en la base de datos en texto sin formato.