2012-06-15 13 views
7

Por el momento estoy trabajando en un proyecto que manejará información personal bastante sensible, aunque no son números de recuento, sigue siendo información personal confidencial y quiero hacer todo lo posible para encriptar y almacenar esta información dentro de un mysql lo más seguro posible. Así que ahora estoy buscando intensamente algunas medidas de seguridad que puedan manejar esta información sensible.PHP Mcrypt, ¿qué tan seguro es realmente?

Una forma fácil de encriptar/desencriptar cadenas y bloques de texto, sería usar mcrypt. Pero cuando busco en mcrypt aquí en stackoverflow, noté que mucha gente dice que mcrypt no es tan seguro.

Así que ahora me pregunto, ¿qué tan seguro es realmente? ¿Se necesitan muchas habilidades de pirateo, digamos habilidades de expertos, para descifrar y descifrar la información almacenada si la clave se almacena de forma segura? ¿Debo temer que un hacker con poca habilidad pueda descifrar la información cifrada que voy a almacenar dentro del servidor mysql? Entonces, ¿qué habilidades se necesitan para descifrar la información encriptada que está encriptada con mcrypt?

Si Mcrypt no se puede utilizar lo suficiente, ¿cuáles son las buenas alternativas que no son tan complejas como usar las extensiones gnupg?

+4

Tenga en cuenta que la tecnología es sólo una parte de la ecuación ... su aplicación también debe ser seguro. Centrarse exclusivamente en la tecnología puede hacer que suponga que es más seguro que usted. –

+1

* "Me di cuenta de que muchas personas dicen que mcrypt no es tan seguro". * - ¿No es tan seguro? ¿Es eso sin razonamiento? – hakre

+1

mcrypt en sí mismo no es una solución de un solo clic, admite varios algoritmos diferentes en varios modos diferentes. Es un pequeño engranaje que analiza los números reales, alrededor del cual tienes que construir tu sistema de seguridad. La mayoría de las veces, la inseguridad proviene de los desarrolladores que usan mcrypt de forma inapropiada porque no entienden el panorama general. – deceze

Respuesta

16

Una pequeña guía que puede seguir para evitar algunas trampas y aplicar algunas recomendaciones.

  • No reutilice la misma clave de cifrado y el mismo vector de inicialización (IV) para dos mensajes diferentes.

Si lo hace, correrá el riesgo de exposición del texto sin formato si un adversario logra interceptar dos o más mensajes durante el tránsito utilizando la misma clave y IV.

  • No utilice el modo ECB; Los modos OFB y CTR son algo mejores, pero se recomienda usar el modo CBC o CFB.

La principal razón para no usar BCE es porque este modo se filtra información sobre bloques de texto plano duplicados que pueden menoscabar su flujo codificado de los datos.

OFB y CTR son mejores, pero sufren el problema de seguridad antes mencionado de usar la misma combinación de teclas IV + más de una vez.

CFB y CBC son los más resistentes contra la reutilización de la clave IV +, pero los mensajes separados con el mismo prefijo común perderán la longitud de dicho prefijo. Además, CFB filtra la diferencia de los primeros bloques de texto sin formato no idénticos.

  • Asegúrate de que tienes una fuerte encriptación de clave

    Debe no ser elegido entre ASCII imprimible (por ejemplo no "mi super fuerte clave secreta"); Se preferiría PBKDF2 (que pronto se admitirá de forma nativa, hasta entonces Google). Debería ser obvio que esta clave debe mantenerse segura; si lo pierde, datos de adiós.

  • Utilice una buena fuente de entropía para generar el vector de inicialización.

    Mcrypt tiene una opción para utilizar MCRYPT_DEV_RANDOM o MCRYPT_DEV_URANDOM cuando llame mcrypt_create_iv().

Hope esto le ayudará a :)

+0

¡Muchas gracias, Jack! – HermesTrismegistus

Cuestiones relacionadas