cifrado de mensajería segura

Question

cifrado de mensajería segura

#1 de markus-nm (1 votos)

0

Me gustaría saber su opinión sobre lo siguiente:

Estoy desarrollando un mensajero de Android, donde toda la comunicación se realiza desde la aplicación - > php - > mysql, desde donde lo sacará el receptor en orden inverso. Así que he estado pensando en cómo hacerlo seguro, y pensé en lo siguiente:

La primera vez que se instala la aplicación, el servidor genera una clave y la envía al usuario. La clave se utiliza para cifrar (quizás con AES256) la próxima comunicación al servidor. Luego, en la próxima comunicación DESDE el servidor, se recibe una nueva clave en el paquete cifrado por la clave anterior, y de esta manera, cada mensaje se cifra mediante una nueva clave. Luego, si está olfateando paquetes, debe haber estado allí la primera vez que se instaló la aplicación para tener la oportunidad de romper la seguridad. En el lado de PHP, tengo varias secuencias de comandos, pero estoy considerando tener una secuencia de comandos de "entrada", que recibe un identificador de cuál de las otras secuencias de comandos es para la comunicación, pero no es el nombre real del otro script a tratar. De esta manera, los hackers no sabrán el nombre de ninguno de los scripts, excepto el script de "entrada". Ya he configurado todo el código en los scripts de PHP con declaraciones de DOP / preparadas. Leí en alguna parte que las bases de datos mysql están encriptadas por defecto. ¿Hay alguna razón por la que deba tomar medidas adicionales para proteger los datos en la base de datos mysql?

¿Otras ideas?

encryption aes php mysql

pregunta Corey Hart 07.07.2017 - 13:19

fuente

1 respuesta

Lea otras preguntas en las etiquetas encryption aes php mysql

Saltar el mismo valor muchas veces ¿Gpg --digest-algo tiene algún efecto al verificar una firma?

score 1 · Accepted Answer

El esquema de cifrado completo que propuso no está del todo seguro según la definición de hoy; los usuarios de un mensajero esperarán "SEGURO ADELANTE", lo que significa que su servidor nunca debe poder leer / descifrar ningún contenido del mensaje que se envíe de un cliente a otro.

"Leí en alguna parte" no es una fuente válida para nada relacionado con la seguridad
mysql no es capaz de guardar su backend encriptado directamente, puede mantener el backend en un disco encriptado, pero el 99.99% de los posibles ataques ocurrirán cuando el sistema esté en funcionamiento, cuando el encriptado del disco sea inútil
cifrar el backend de la base de datos no ayudará a los atacantes que obtuvieron acceso a los datos de inicio de sesión privilegiados de mysql (como los que se usan en su script php)
incluso el cifrado de campos individuales de la base de datos a diferencia de toda la base de datos no ayuda a los atacantes que obtuvieron acceso a su código php a menos que se mantenga el secreto correcto de todos los mensajes

El cifrado simétrico ("quizás con AES256") solo es seguro cuando las claves se intercambian y se mantienen privadas. usted propone transferir la clave inicial en texto sin formato, confiando así en el primer intento de conexión para estar seguro. Este es un diseño horrible para aplicaciones seguras / intercambio de datos. ¿Por qué no usar SSL / TLS para asegurar la conexión con el servidor? Básicamente, hace lo que usted quería hacer, excepto que el paquete "inicial" se transmite a través de una conexión segura utilizando un método de cifrado asimétrico para entregar las claves simétricas utilizadas para el resto de la conexión. Y ahora solo debe preocuparse por la implementación del secreto hacia adelante.

Para obtener más detalles, la implementación adecuada de SSL / TLS y el secreto de envío, recomiendo leer la documentación de openSSL . OpenSSL ofrece todas las funciones criptográficas necesarias para implementar un mensajero seguro a través de Internet.