Mysql: cifrado bidireccional de datos confidenciales (direcciones de correo electrónico) fuera de Apache, PHP y MySQL

5

Almacenamos las direcciones de correo electrónico de los usuarios en nuestra base de datos, como muchos otros sitios web. Si bien nos enorgullecemos de las medidas de seguridad implementadas, a veces "solo lo suficiente" no es suficiente.

Hemos comenzado a buscar una solución que nos permita almacenar las direcciones de correo electrónico en un formato cifrado y recuperarlas en un formato legible, pero, y aquí está el problema, fuera de la fuente de nuestro código PHP. Es decir, si alguien alguna vez infringe nuestros servidores y recupera nuestro código fuente, las contraseñas de nuestra base de datos y todo lo relacionado con nuestra inteligencia comercial, nos gustaría que aún tuviera datos absolutamente inútiles sin el algoritmo de cifrado.

¿Cuál sería la mejor manera de hacer esto y hay soluciones ya hechas? Estábamos pensando en algo parecido a un módulo php o apache, o incluso un pequeño programa Go: cualquier compilación que se ejecutaría muy rápido y sería inutilizable si se la robara debido a su naturaleza compilada.

Lo que queremos es algo como esto:

Los correos electrónicos en la base de datos se almacenarán en este formato

gibbweswwvsknvknsdva
sadjfoaisjdoiasjdoiasj
skdjfajsfoiajsdoij
whatever

Entonces, cuando hicimos esto:

$email = $db -> getEmailById(30);
$email = decrypt($email);

la función de descifrado sería para el descifrado real, pero fuera de php. Podría llamar al comando del sistema y ejecutar un archivo binario, lo que sea. Pero cualquier devolución de datos es el correo electrónico utilizable real.

Este correo electrónico descifrado se puede usar como destinatario de un correo electrónico enviado por el sistema, o como información de contacto mostrada en el perfil de un usuario, etc., pero si el usuario rompe el DB de alguna manera, todo lo que ve es el gibberish anterior.

Editar: tdammers preguntó por qué esto tiene que estar fuera de PHP pero puede llamarse desde PHP. Debido a que utilizamos los valores reales de las direcciones de correo electrónico un par de veces por minuto, diferentes. Por lo tanto, nuestra aplicación web necesita un acceso rápido a los valores legibles en todo momento, pero tenemos que estar seguros de que si alguien toma nuestro código fuente de alguna manera o de la base de datos en sí, no tendrá valores utilizables. Puede ser cualquiera, desde un pirata informático, a una parte del código que se expone debido a un error crítico, o un ex empleado descontento 5 minutos después de ser despedido, lo que nos deja sin tiempo para revocar su acceso.

    
pregunta Swader 08.12.2011 - 09:29
fuente

6 respuestas

7
  

"Los cifrados son difíciles. La criptografía es difícil. Los cifrados son la parte fácil".

     

--Bruce Schneier

Crear tu propio algoritmo de creación de casa para cifrar el correo electrónico es, literalmente, el peor error que podrías cometer en la criptografía. No estoy siendo hiperbólico, de hecho es el peor error. El punto central de la criptografía moderna es que los algoritmos son públicos para que puedan ser revisados por pares. No nunca consideraría usar un algoritmo privado por ningún motivo. La clave es lo que es secreto, y esto hace que el sistema funcione.

En tu caso. La base de datos puede verse comprometida y los mensajes pueden permanecer seguros si cada cliente utiliza su propio par de claves asimétricas. La infraestructura de correo electrónico simplemente pasa a lo largo del texto cifrado sin ningún medio de descifrarlo. Así es como funciona Enigmail . De hecho, recomiendo usar Enigmail, ¿por qué reinventar la rueda?

    
respondido por el rook 06.12.2011 - 19:59
fuente
4

Hay que tener en cuenta dos aspectos: por un lado, usted cifra los datos para que estén protegidos "en el disco" y, por otro lado, debe asegurar el acceso a estos datos.

Los DB como Oracle (en la edición empresarial) tienen algunos complementos para proporcionar un cifrado de datos transparente. En efecto, tiene sus datos cifrados en el disco para que un atacante que obtenga acceso a los archivos de la base de datos no tenga texto sin cifrar.

Creo que hay al menos una solución similar para MySQL: enlace

Safenet tiene un producto ProtectDB / DataSecure que realiza este cifrado transparente (y algunas características adicionales, consulte a continuación) como dispositivo externo. Esto funciona con un par de versiones DB: enlace

El siguiente paso es controlar el acceso a estos datos. Puede limitar el acceso a las cuentas de usuario, las direcciones IP, pero si un atacante puede controlar su aplicación, puede leer sus datos. Además, podría imponer límites de consulta para que su aplicación no pueda leer más de X registros por hora. Además, debe usar el registro y tal vez alerta sobre los valores de umbral de consulta.

Una alternativa al cifrado transparente fue implementar un tipo de servicio web que sea su almacén personal de datos seguros. Solo esta aplicación debe poder manejar el cifrado. Una aplicación que necesita un correo electrónico tiene que consultar el servicio para acceder a un correo electrónico de texto simple. Debe colocar dicho servicio en una máquina separada.

    
respondido por el mdo 08.12.2011 - 13:02
fuente
4

En primer lugar, absolutamente, absolutamente, no intente inventar su propio algoritmo. No ganas nada y lo pierdes todo. Los algoritmos son fáciles de aplicar ingeniería inversa, incluso en formato binario. Y al crear su propio cripto, usted presenta la posibilidad muy real de que su sistema pueda ser resquebrajado sin ningún conocimiento interno, porque su cripto fue tan terrible.

Segundo, poner tus secretos en forma binaria en lugar de un script es como escribir tu contraseña al revés para que el atacante no pueda leerla. Si el atacante está determinado ( y claramente lo es, si se está molestando en ir tan lejos, entonces no ha hecho más que incomodarlo un poco. Realmente, este tipo de trabajo de extracción es el "hola mundo" del mundo de la contra-seguridad.

Finalmente, lo que estás pidiendo es fundamentalmente problemático. Desea un sistema que pueda descifrar automáticamente su contenido encriptado, pero desea que se construya de tal manera que si alguien sabe todo lo que el sistema sabe, entonces no podrá hacer lo mismo. Esa no es una expectativa completamente razonable.

Pero la situación tampoco es desesperada; la seguridad es un compromiso contra la conveniencia, y casi siempre se puede obtener más seguridad al eliminar cierta cantidad de conveniencia y autonomía.

La mejor seguridad que obtendrá es donde todos los parámetros criptográficos se almacenan en un archivo protegido por contraseña que nunca se descodifica en el disco. En su lugar, cada vez que inicia el sistema, ingresa manualmente una contraseña que se usa para extraer los parámetros operativos de la base de datos directamente en la memoria de trabajo. Solo tiene esa contraseña, solo puede iniciar o reiniciar los servidores, y ningún empleado debe tener acceso a esa información confidencial. De esta manera, si todo su sistema es robado o copiado por un técnico descontento, no podrá hacerlo. extrae tu extracto de tus secretos o incluso arranca tu sistema.  Además, siempre eres el que responde al buscapersonas a las 3am. (lo siento, convenio de compensación)

Alternativamente, puede vincular su cifrado a un token de hardware . Entonces el propietario del token es el propietario de los datos. Nuevamente, no hay riesgo de copiar, pero también si alguien roba ese dispositivo, han robado su base de datos.

    
respondido por el tylerl 12.12.2011 - 07:33
fuente
2

¿Podría Truecrypt o un enfoque similar ser una solución? Ubique la base de datos MySQL en un volumen encriptado de este tipo, que no requerirá otros cambios (guarde las acciones para montar el volumen encriptado en el inicio / desmonte después de que el demonio de MySQL se detenga).

Si el intruso tiene acceso a un servidor que funciona, intercambiando datos con, por ejemplo, una aplicación web, aún podrían interceptar los datos confidenciales, como yo lo veo. Sin embargo, si el servidor se apaga y se lo roban, Truecrypt será una protección lo suficientemente buena, si se ha elegido una frase de contraseña lo suficientemente buena.

    
respondido por el Konstantin Boyandin 08.12.2011 - 12:48
fuente
2

Hay una solución muy simple para tu problema:

  • Cifre las direcciones de correo electrónico utilizando un algoritmo estándar y bien evaluado. (Por lo tanto, está almacenando direcciones de correo electrónico cifradas en la base de datos).

  • Almacene la clave de descifrado en un archivo en su servidor. (No en el código fuente de PHP. El código fuente de PHP puede abrir este archivo, leerlo, almacenar la clave de descifrado en la memoria y usarlo desde allí).

De esta manera, un desarrollador o pirata informático que realiza una copia del código fuente no puede descifrar las direcciones de correo electrónico. Además, la clave de descifrado no se almacenará en el código fuente ni en el repositorio de control de fuente.

Por supuesto, un pirata informático que irrumpe en su servidor y roba el contenido de la base de datos y el contenido del archivo que contiene la clave de descifrado todavía puede descifrar las direcciones de correo electrónico. Pero esto es inevitable. En el modelo de amenaza en el que el atacante puede robar todo el contenido de su base de datos y tiene acceso completo al sistema que ejecuta la aplicación web, se encuentra en una página. Si la aplicación web puede descifrar, también lo puede hacer el pirata informático. No hay nada que puedas hacer al respecto; Es solo un hecho de la vida.

    
respondido por el D.W. 11.12.2011 - 03:02
fuente
1

Sé que tengo tres años de retraso en la fiesta, pero me gusta señalar algo que me perdí en las respuestas de quienes lo encontraron en Google.

La mayoría de las "fugas" de sitios web pirateados son el resultado de la inyección de SQL, y mucho menos de un servidor root-ed donde el pirata informático tiene acceso completo a los archivos de base de datos en bruto. La inyección SQL es una técnica de ataque en la que el pirata informático puede manipular las consultas realizadas por la base de datos, y tienen el código normal del sitio web para procesar las páginas.

La última parte es crucial: su código PHP renderizará las páginas como de costumbre. Esto significa que el código de descifrado de su dirección de correo electrónico se ejecutará normalmente y ayuda al pirata informático a descifrar la información. Todo lo que el hacker tiene que hacer es manipular qué registro se muestra (por ejemplo, DONDE ESTÁ id = 123--)

Si el pirata informático tiene acceso completo a sus archivos, probablemente también tenga acceso al código PHP y la clave en la memoria.

    
respondido por el Jason Smith 27.03.2014 - 21:38
fuente

Lea otras preguntas en las etiquetas