Pregunta:
Mysql: cifrado bidireccional de datos confidenciales (direcciones de correo electrónico) fuera de Apache, PHP y MySQL
Swader
2011-12-08 14:29:27 UTC
view on stackexchange narkive permalink

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 recuperarlos en un formato legible, pero, y aquí está el truco, fuera de la fuente de nuestro código PHP. Es decir, si alguien alguna vez viola nuestros servidores y recupera nuestro código fuente, las contraseñas de nuestra base de datos y todo lo que tenga que ver con nuestra inteligencia comercial, nos gustaría que aún tuviera datos completamente inútiles sin el algoritmo de cifrado.

¿Qué? sería la mejor manera de hacerlo, y ¿existen soluciones listas para usar? Estábamos pensando en algo parecido a un módulo php o apache, o incluso un pequeño programa Go: cualquier cosa compilada que se ejecute muy rápido y que no se pueda utilizar si se la roban debido a su naturaleza compilada.

Lo que queremos es algo como esto:

Los correos electrónicos en la base de datos se almacenarían en este formato

  gibbweswwvsknvknsdvasadjfoaisjdoiasjdoiasjskdjfajsfoiajsdoijwhatever  

Entonces, cuando lo hicimos esto:

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

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

Este correo electrónico descifrado se puede usar como el 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 el usuario corta la base de datos de alguna manera, todo lo que ve es el galimatías anterior.

Editar: tdammers preguntó por qué esto tiene que estar fuera de PHP pero invocable desde dentro de PHP. Porque utilizamos los valores reales de las direcciones de correo electrónico un par de miles de veces por minuto, además de diferentes. Por lo tanto, nuestra aplicación web necesita acceso rápido a los valores legibles en todo momento, pero debemos estar seguros de que si alguien toma nuestro código fuente de alguna manera o la base de datos en sí, no tendrá valores utilizables. Puede ser cualquier persona, desde un pirata informático hasta una parte del código expuesta 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.

Lo siento, quería escribir que almacenamos "direcciones de correo electrónico", no "correos electrónicos". Gracias por los avisos sobre los otros sitios. ¿Debo esperar a que un moderador mueva la pregunta, o simplemente debo volver a publicar allí?
El hecho de que algo esté compilado no significa que no se pueda descompilar y examinar. Compilado NO es igual de seguro.
Lo sé, pero es igual a "más seguro que no compilado", ¿no es así?
`un ex-empleado descontento 5 minutos después de ser despedido y no nos deja tiempo para revocar su acceso` - su algoritmo es incorrecto: ** primero ** revocar el acceso, * luego * hacer la conversión a ex-empleado
Seis respuestas:
Rook
2011-12-07 00:59:58 UTC
view on stackexchange narkive permalink

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

--Bruce Schneier

Creando tu propia casa elaborar un algoritmo para cifrar el correo electrónico es, literalmente, el peor error que podría cometer en criptografía. No estoy siendo hiperbólico, de hecho es el peor error. El objetivo de la criptografía moderna es que los algoritmos son públicos para que puedan ser revisados ​​por pares. Nunca consideraría usar un algoritmo privado por ningún motivo. La clave es lo 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 transmite el texto cifrado sin ningún medio para descifrarlo. Así es como funciona Enigmail. De hecho, recomiendo encarecidamente usar Enigmail, ¿por qué reinventar la rueda?

Oh, lo siento, quise decir que almacenamos direcciones de correo electrónico, no correos electrónicos. Actualizaré la pregunta principal. Nos gustaría que las direcciones permanezcan seguras, la información de contacto de nuestros usuarios. No almacenamos correos electrónicos reales en la base de datos, solo la información de contacto.
Se aplica la misma idea. La idea sería entonces generar un par de claves usando la contraseña de un administrador (idealmente, una contraseña realmente buena que todos los administradores conozcan desde fuera del sistema) para cualquier momento en el que se necesite ver los detalles de un usuario. Si está buscando usar esa información dentro del sistema, digamos para enviar correos electrónicos generados automáticamente, entonces eso es un poco (mucho) más complicado de mantener seguro, ya que debe almacenar ambos lados de la clave (o la contraseña que hizo la clave) para que el sistema decodifique el mensaje.
Eso es lo que estoy buscando, sí. Se actualizó ligeramente el OP.
mdo
2011-12-08 18:02:38 UTC
view on stackexchange narkive permalink

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

DBs como Oracle (en la edición empresarial) tienen algunos complementos para proporcionar un cifrado de datos transparente. De hecho, 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: http://www.gazzang.com/products/ezncrypt-for-databases.html

Safenet tiene un producto ProtectDB / DataSecure que hace este cifrado transparente (y algunas características adicionales, ver más abajo) como dispositivo externo. Esto funciona con un par de versiones de DB: http://www.safenet-inc.com/products/data-protection/database-protection/

El siguiente paso es controlar el acceso a estos datos. Puede limitar el acceso a las cuentas de usuario, 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, debería utilizar el registro y quizás alertar sobre los valores de umbral de consulta.

Una alternativa al cifrado transparente era implementar un tipo de servicio web que sea su almacén de datos seguro personal. 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 en texto plano. Debe colocar dicho servicio en una máquina separada.

Esto parece bastante prometedor, lo echaré un vistazo tan pronto como encuentre un par de minutos de tiempo libre y lo publicaré con opiniones y pensamientos. ¡Gracias!
tylerl
2011-12-12 12:33:56 UTC
view on stackexchange narkive permalink

Primero que nada, absolutamente, absolutamente, no intente inventar su propio algoritmo. No ganas nada y pierdes todo. Los algoritmos son fáciles de aplicar ingeniería inversa, incluso en formato binario. Y al construir su propia criptografía, introduce la probabilidad muy real de que su sistema pueda ser descifrado sin ningún conocimiento interno, porque su criptografía era tan terrible.

En segundo lugar, poner sus secretos en binario formulario en lugar de formulario de script es como escribir su contraseña al revés para que el atacante no pueda leerla. Si el atacante está determinado (y claramente lo está si se está molestando en llegar tan lejos) entonces no has hecho más que molestarlo un poco. Realmente, este tipo de trabajo de extracción es el "hola mundo" del mundo de la contraseguridad.

Finalmente, lo que está pidiendo es fundamentalmente problemático. Quiere un sistema que pueda descifrar automáticamente su contenido cifrado, pero quiere que se construya de tal manera que si alguien sabe todo lo que el sistema sabe, no podrá hacer lo mismo. Esa no es una expectativa del todo razonable.

Pero la situación tampoco es desesperada; la seguridad es una compensación 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 que todos los parámetros criptográficos se almacenan en un archivo protegido con contraseña que nunca se decodifica en el disco. En cambio, cada vez que inicia el sistema, escribe manualmente una contraseña que se utiliza para extraer los parámetros operativos de la base de datos directamente en la memoria de trabajo. Solo usted tiene esa contraseña, solo usted puede iniciar o reiniciar los servidores, y ningún empleado tiene que 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á extraer sus secretos o incluso iniciar su sistema. Además, siempre eres tú quien responde al buscapersonas a las 3 a. M. (lo siento, compensación de conveniencia)

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, ha robado su base de datos.

hm. Dado que tenemos una configuración de servidor de clúster en los EE. UU., Y estamos en Europa, y nuestro clúster es administrado de forma remota por un administrador de servidor de otro país, este tipo de configuración lo hace doblemente complejo. Agregue al problema el hecho de que ahora tenemos un tipo de nivel de sysop en nuestro equipo de TI que tiene ALGUNOS privilegios de reinicio (solo para cuando algo sale terriblemente mal y el administrador del servidor original no está disponible instantáneamente por alguna razón), toda la infraestructura parece trabajar en nuestra contra ... FMI, sin embargo, ¿cómo podría uno implementar algo como su solución anterior? ¿El archivo que nunca se decodifica en disco?
Swader: consulte también http://security.stackexchange.com/questions/9411/db-passwords-more-secure-in-a-php-apps-ini-config-files-or-apache2-environmen - Cuando se usa PHP podría usar algún almacenamiento volátil para almacenar su contraseña solo en RAM (por ejemplo, memcache). Pero tome medidas para proteger este servicio.
Konstantin Boyandin
2011-12-08 17:48:35 UTC
view on stackexchange narkive permalink

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

Si un intruso obtiene acceso a un servidor en funcionamiento , intercambiando datos con, digamos, 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 suficientemente buena, si se ha elegido una contraseña suficientemente buena.

No, eso no funcionará. Se accede con frecuencia a nuestra lista de correos electrónicos (un par de miles de veces por minuto en promedio) y se actualiza, y nuestros servidores están en los EE. UU., Mientras que estamos en Europa, no hay temor al robo físico. Lo que queremos es la capacidad de arrastrar cada correo electrónico solicitado a través de un algoritmo de cifrado / descifrado separado. Más detalles en el OP
D.W.
2011-12-11 08:02:17 UTC
view on stackexchange narkive permalink

Existe una solución muy sencilla para su problema:

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

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

En de esta manera, un desarrollador o hacker que se haga con una copia de su código fuente no podrá 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 hacker que irrumpe en su servidor y robe el contenido de la base de datos y el contenido del archivo que contenga la clave de descifrado aún puede descifrar las direcciones de correo electrónico. Pero esto es inevitable. En el modelo de amenazas 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, está bloqueado. Si la aplicación web puede descifrar, también puede hacerlo el pirata informático. No hay nada que puedas hacer al respecto; es solo una realidad.

Bien, eso no está nada mal, sí. Veré qué puedo hacer con respecto a eso: dado que accedemos a la base de datos con mucha frecuencia para recuperar los correos electrónicos, podríamos encontrarnos con algunos speedbumps literales si confiamos en las llamadas de PHP, el análisis y el uso del contenido del archivo como clave de descifrado. Por otra parte ... si PHP tuviera que llamar a un script externo de todos modos, podría no haber mucha diferencia. Definitivamente echaré un vistazo a esto, gracias.
@Swader, su código PHP solo necesita abrir y leer el archivo de claves una vez después del arranque (no en cada solicitud HTTP), y luego puede almacenar la clave en la memoria, por lo que esperaría que el impacto en el rendimiento sea menor.
Tienes razón. Definitivamente necesito comprobar esto.
¿Alguna recomendación sobre algoritmos de seguridad decentes y lo suficientemente rápidos para nuestro problema?
Jason Smith
2014-03-28 01:38:21 UTC
view on stackexchange narkive permalink

I know I am three years late to the party, but I like to point out something I missed in the answers for those finding this in Google.

Most "leaks" from hacked websites are the result of SQL Injection, and much less from a root-ed server where the hacker has full access to the raw database files. SQL injection is an attack technique where the hacker can manipulate the queries performed by the database, and have the normal website code render the pages.

That last part is crucial: your PHP code will render the pages as usual. This means that your email address decryption code will execute normally and helps the hacker decrypt the information. All the hacker has to do is manipulate which record is shown (e.g. WHERE id=123--)

Should the hacker have full access to your files, then he most probably also has access to the PHP code and key in memory.



Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...