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

Al igual que 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 probabilidad de que suceda?

El daño causado si se reemplazan las direcciones de correo electrónico podría ser mucho mayor que si se EXPONEN. Especialmente si, por ejemplo, está utilizando la dirección de correo electrónico para verificar el restablecimiento de la contraseña en un sistema seguro.

La posibilidad de que las contraseñas sean reemplazadas o expuestas se reduce mucho si los hash, pero depende de qué otros controles tenga 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 SQL, bases de datos de terceros). Con esto en mente, es razonable considerar el uso de un cifrado con una clave. Sin embargo, 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 texto plano, En la remota posibilidad de que algo se pase 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 la validación y evitar 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.

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

El mayor problema es, ¿dónde se almacena la clave de cifrado? Porque si el hacker tiene exceso a algo más de tu DB, todos sus esfuerzos son probablemente desperdiciado. (Recuerde, su aplicación necesitará esa clave de cifrado para descifrar y cifrar, por lo que eventualmente el hacker encontrará la clave de cifrado y el esquema de cifrado utilizado).

Pro:

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

Contras:

• El cifrado significa pérdida de rendimiento.
• Asignar acciones de base de datos será más difícil si no imposible.

No confunda accidentalmente el cifrado con la ofuscación. Comúnmente ofuscamos correos electrónicos para evitar el spam. Muchos sitios web tendrán "webmaster _at_ mysite.com" para ralentizar a los rastreadores de analizar la dirección de correo electrónico como un objetivo potencial de spam. Eso debe hacerse en las plantillas HTML no no hay valor para hacer esto en el almacenamiento de 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 sentencias SQL se transmiten del cliente al servidor; ¿es en el mismo cuadro o a través de una conexión segura?

2. Si su servidor está comprometido, tiene una transmisión no intencional. Si está preocupado por esto, entonces tal vez debería proteger su servidor. Tiene 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 los medios de copia de seguridad; ¿se hace esto utilizando una estrategia de copia de seguridad segura que encripta a medida que avanza?

Tanto SQL Server como Oracle (y creo que también otros DBs) admiten el cifrado de datos a nivel de base de datos. Si desea cifrar algo por qué no simplemente abstraer el acceso a los datos que podrían ser cifrados en el lado del servidor de la base de datos y dejar que el usuario elija si utilizar los datos cifrados (en este caso el comando SQL será diferente) o no. Si el usuario desea usar datos cifrados, puede configurar el servidor de base de datos y todo el trabajo de mantenimiento conectado con la administración de claves se hace usando la herramienta estándar de DBA, hecha del proveedor de la base de datos y no de usted.

Una copia de mi respuesta en ¿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?, 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 en que cualquiera que pueda acceder a su base de datos probablemente también pueda obtener sus claves. 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 siento que una dirección de correo electrónico es un detalles personales, así que no me importaría el spam, sino las consecuencias personales cuando se revelan las direcciones.

Por supuesto, cuando usted tiene miedo de inyección SQL entonces usted debe asegurarse de que dicha inyección está prohibida. Y las copias de seguridad deben estar encriptadas.

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

Para muchos sitios lo anterior probablemente no es el caso, y debe centrarse en prohibir SELECT * FROM a través de inyección SQL, y asegurarse de que los visitantes no puedan llegar a alguien de alguna manera perfil personal de else o información de pedido cambiando la URL.

Vale la pena cifrar datos en Bases de datos, no lo hace un poco más difícil, sino mucho más difícil cuando se encripta de la manera correcta, así que detenga la filosofía y cifre los datos confidenciales;)

Usted realmente tiene que sopesar su peor caso senario de alguien la obtención de esas direcciones de correo electrónico, la probabilidad de que alguien obtenerlos, y su esfuerzo/tiempo adicional necesario para impliement el cambio.

@ Roo

De alguna manera estoy de acuerdo con lo que está diciendo, pero ¿no vale la pena cifrar 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 ser fácilmente comprometidas.

Mi respuesta:

Yo diría que si tienes datos sensibles que no quieres caer en las manos equivocadas, probablemente deberías hacerlo tan duro como puedas para que un hacker consíguelo, incluso si no es 100% a prueba de tontos.