¿Sería esto lo suficientemente seguro? (Módulo ZF3 y Doctrine usando halita)

0

Recientemente se lanzó PHP7.2 con la biblioteca Sodium incluida para el cifrado.

Por supuesto, ya había módulos de cifrado disponibles, incluso trabajando con Zend Framework 2 o Symfony. Necesitábamos una implementación para Zend Framework 3 y no queríamos confiar en nuestros propios métodos de cifrado, creamos un ZF3 & Módulo de Doctrine 2 que utiliza implementación de encriptación de paragonie .

El propósito, en este momento, es poder cifrar y descifrar automáticamente en la lectura / escritura de ciertas propiedades, detectadas a través de un oyente enganchado en el ORM de Doctrine.

La forma en que lo hemos configurado es la siguiente:

Default

  1. Recibir una cadena (no cifrar null )
  2. Agregue sal en el código (config) a la cadena
  3. Utilice la clave privada in-code (config) para el cifrado

Obviamente, no es el método más sólido para extender una cadena, pero esto es para asegurarnos de que podemos cifrar los datos marcados con una etiqueta usando la configuración predeterminada. Datos como el nombre de una calle.

Opciones

  1. Recibir una cadena (no cifrar null )
  2. Agregue la sal y / o pimienta generadas de 32 caracteres antes (y después) de la cadena (almacenada en una tabla de db separada, aunque los registros se vincularon mediante una clave externa)
  3. Agregue sal en el código (config) a la cadena
  4. Utilice la clave privada in-code (config) para el cifrado

Este es el módulo que, en realidad, solo yo, hemos creado. La implementación real del cifrado / descifrado comienza alrededor de .

¿Por qué estoy preguntando?

Porque espero haber entendido todo bien y, por lo tanto, haber creado algo increíble. Sin embargo, como no soy un experto en criptología y no tenemos tal persona en la empresa, pensé preguntar aquí, con la esperanza de obtener algún comentario.

El código se proporciona tal como está y es de código abierto. Es extensible y reutilizable para que otros puedan usar el mismo servicio pero pueden usar su propio adaptador de cifrado. Sin embargo, no quisiera que usaran algo por debajo del promedio.

    
pregunta rkeet 10.04.2018 - 12:02
fuente

1 respuesta

1

Lo que hiciste bien

Estás usando una biblioteca

Elegiste usar una biblioteca para hacer el cifrado por ti. ¡Buen trabajo! De alguna manera la gente todavía arruina esto. No seas un Dave , nunca hagas rodar tu propio cripto (a menos que realmente, realmente entiendas lo que estás haciendo).

Lo que hiciste mal

Estás haciendo mal uso de la terminología

Una salt se utiliza para las contraseñas de hashing. Debe ser único por contraseña y, por lo tanto, no se puede ubicar en una configuración. Un pepper es similar a un salt, pero es el mismo para cada contraseña, y por eso puede estar ubicado en una config. Ninguno de estos tiene nada que ver con el cifrado.

Estás intentando "mejorar" el cifrado sin entenderlo

Agregar un valor único a cada cadena no es necesario porque (bueno) los algoritmos de encriptación usan vectores de inicialización o nonces para aleatorizar sus Salida al cifrar datos duplicados. Halite utiliza XSalsa20 MACed con un hash BLAKE2b con clave. No intente mejorarlo, simplemente agregará complejidad a su implementación sin ningún motivo.

Hay una razón legítima para rellenar los datos antes de cifrarlos, y es ocultar la longitud de los datos. Algunos algoritmos de cifrado permiten que un atacante determine la longitud del texto simple redondeado a un número de bytes, y otros permiten determinar la longitud exacta del texto simple. En este caso, sin embargo, debe rellenar todos los datos a la misma longitud (o un múltiplo de la misma longitud), y el relleno no debe ser aleatorio.

    
respondido por el AndrolGenhald 10.04.2018 - 17:27
fuente

Lea otras preguntas en las etiquetas