¿Está creando una aplicación web con entradas de base de datos MySQL cifradas?

Question

¿Está creando una aplicación web con entradas de base de datos MySQL cifradas?

#1 de AJ Henderson (5 votos)
#2 de Ángel (0 votos)

9

Tengo algo de experiencia en la creación de sitios web basados en PHP con acceso a MySQL, el almacenamiento de datos cifrados del usuario, pero todos los demás campos son texto sin formato. Mi proyecto más reciente requerirá que se almacenen datos confidenciales en la base de datos.

Quiero configurar un sistema en el que un usuario pueda acceder a sus propias entradas y ver los resultados en texto sin formato, pero incluso si pudiera acceder a los de otra persona, serían cadenas encriptadas e ininteligibles.

Tengo una idea de cómo lograr esto, pero quizás no sea óptimo o ya existen herramientas para hacerlo de una manera más eficiente.

1.) Almacene el nombre de usuario como texto sin formato, y la contraseña con hash con sha1 () o mejor algoritmo de hash más sal aleatoria, etc.

2.) Tome la contraseña del usuario (no la que tiene el hash, sino la que escribió) y úsela para definir una clave específica para ese nombre de usuario y contraseña, que luego se almacenará como una variable de sesión. Ya que la clave nunca se almacena en ninguna parte, excepto en la cabeza del usuario (en la forma de que sepa su contraseña de texto simple, que luego se convertirá en una clave de alguna manera, mezclándola con su nombre de usuario y algo de sal, hashing, etc.). Para iniciar sesión, esta debería ser una buena solución, ¿no?

3.) Cifre o descifre todos los datos de ese usuario con esa clave.

En mi opinión, aunque alguien haya accedido a la base de datos y haya visto una lista de nombres de usuario de texto sin formato y contraseñas cifradas, no pudo descubrir la clave específica ya que no está almacenada en ningún lugar. Por lo tanto, incluso si se obtuvo acceso, no pudieron descifrar el contenido de los campos de base de datos confidenciales. Por supuesto, estoy desarrollando formas para evitar que accedan a la base de datos de todos modos, pero como un esfuerzo general, esto parece ser un buen conjunto de pasos.

¿Podrían los expertos comentar sobre esto y ofrecer algún consejo? Muchas gracias.

Publiqué esto en el foro programmers.SE y me aconsejaron que esta era una mejor ubicación para la pregunta. Más específicamente por qué no debería hacerlo yo mismo. Si es así, ¿qué alternativas hay?

encryption databases php

pregunta Joey O 16.07.2013 - 15:40

fuente

2 respuestas

Lea otras preguntas en las etiquetas encryption databases php

¿Es Apple Face ID una buena función de seguridad? Herramienta de ataque de huella digital ssh

score 5 · Answer 1

De lo que estás hablando es de una clave derivada. La técnica que describe se utiliza con frecuencia para sistemas de alta seguridad, aunque le recomendaría que utilice el cifrado derivado de una clave de datos. Esto permite que la clave de datos se almacene con más de una clave derivada y limita el uso de la clave derivada. Esto permite compartir datos, llaveros y recuperar cuentas. Además, tenga en cuenta que la clave derivada en sí misma es tan fuerte como la contraseña, por lo que las funciones de derivación de derivación de clave lenta y salada deben utilizarse para garantizar que las claves derivadas de contraseña no puedan formarse para todas las contraseñas de los usuarios a la vez.

Las claves derivadas tienden a ser más débiles que las claves verdaderamente aleatorias, por lo que desea cifrar la cantidad mínima posible con ellas. Si solo encripta la clave de datos del usuario, puede descifrar la clave de datos del usuario y luego almacenarla en la sesión. Esa clave verdaderamente aleatoria se puede utilizar para cifrar y descifrar los datos del usuario.

Una mejora adicional es la de las claves asociadas con los registros y luego cifrar esa clave de registro con la clave de usuario para dar acceso al usuario. Si usa la criptografía asimétrica aquí, sería posible que un usuario le otorgue acceso de nivel de registro a otro usuario mediante el cifrado de la clave de registro con la clave pública del usuario con el que desea compartir y agregándola al conjunto de claves del otro usuario.

De manera similar, para la recuperación de la cuenta, las claves de usuario se pueden cifrar con una clave de recuperación pública. La clave privada podría mantenerse fuera de línea o asociada a un usuario administrador (con protección de clave derivada similar) y solo la usará el servicio al cliente cuando sea necesario para restaurar una cuenta.

score 0 · Answer 2

utilízalo, define una clave (...), que luego se almacenará como una variable de sesión. Dado que la clave nunca se almacena en ninguna parte, excepto en la cabeza del usuario (...)

Aunque temporalmente, la clave está almacenada en el servidor (por ejemplo, un manejador de sesión básico utiliza archivos en / tmp, un volcado de memoria de memcached podría revelar claves incluso después de caducar). Debe comprobar cómo el servidor mantiene las sesiones para verificar que no (fácilmente) regale esas claves.

Es posible que desee volver a cifrar ese valor almacenado en la sesión con un valor de cookie aleatorio. O no lo guarde en absoluto.

Bonificación si realiza todo el cifrado en el lado del cliente (utilizando javascript). Entonces el servidor nunca ve sus datos y, por lo tanto, no puede un atacante que los comprometa.

(Tenga en cuenta que el atacante aún podría reemplazar el código legítimo con uno malicioso y esperar a que el usuario acceda al sitio nuevamente para robarle sus datos. Esto ya era posible antes)