Está usted visitando una publicación en la hemeroteca de CSIRT-CV.
Para acceder al portal y contenido actual, visite https://www.csirtcv.gva.es
25/09/2013
Consejos prácticos a la hora de integrar criptografía
Me encuentro a diario con personas (principalmente gente que desarrolla o administradores de sistemas) que se encuentran en el proceso de mejorar la seguridad de sus productos / sistemas implementando criptografía como aliada.
Muchas veces se da el caso que existe más buena FE que conocimiento a la hora de abordar esa tarea, y se cometen errores muy inocentes que tiran por tierra el esfuerzo de adoptar una solución por haberla adoptado incorrectamente.
En este post me gustaría compartir 'tips' sobre cómo abordar estos procesos para que deriven en un mejor resultado.
Almacenamiento de contraseñas
Este es el punto en el que más fallos se cometen, en muchos casos debido a que existe mucha información 'legacy' muy bien posicionada en Google a la que llega la gente y la usa como referencia.
Veamos consejos a la hora de realizar esta tarea:
- Olvida y entierra la tentación de cifrar la base de datos con una única contraseña y almacenar dentro las contraseñas en claro. No, ese esquema no es seguro, delegas toda la seguridad en una única contraseña que resulta fácil de obtener (por ejemplo revisando el código del programa que cargue esa base de datos). Nunca utilices criptografía reversible para guardar contraseñas
- Fundamental: OBVIA EL ALGORITMO MD5, sí, es seguro que vas a ver muchos ejemplos en Google que hablan de MD5, de hecho se sigue usando en otras tareas, pero nunca es aconsejable su uso para esta tarea. En su lugar usa SHA-512, penaliza el rendimiento con respecto a MD5, pero es algo imperceptible
- Emplea técnicas de 'salting' a la hora de almacenar el hash de la contraseña. Usar salt significa que, si la contraseña es 123456, en vez de guardar la representación de 123456 en su forma 'hasheada' lo que haces es introducir otro elemento que impida a un atacante usar un listado de hashes de contraseñas ya precompilado. Es decir, lo que guardas es salt+123456 que obviamente genera un hash diferente a 123456 (y que un atacante podría tener ya hasheado con lo que se ahorra el proceso criptográfico). En un típico esquema de usuario / contraseña para una aplicación web, es ideal usar el correo electrónico como salt ya que es un dato conocido y accesible (normalmente se envían correos de confirmación de altas) de forma que, en el ejemplo antes descrito, al final el hash se haría contra fulano@mengano.com+123456
- De nota: Usa PBKDF2 sobre los hashes que guardes. PBKDF2 es un estándar RSA para derivación de claves. Sin entrar en las profundidades matemáticas, lo que hace PBKDF2 es hacer más costoso el tiempo de computación de un hash. Los algoritmos de la rama SHA son algoritmos que han sido diseñados para ser rápidos, es decir, para que el costo computacional no sea elevado, eso, visto desde nuestra perspectiva, significa que los hashes que vamos a almacenar si usamos únicamente SHA se pueden atacar por fuerza bruta a un costo muy pequeño. Si usamos PBKDF2 lo que vamos a hacer es que, generar el hash, 'cueste' bastante más. Como decía al principio esto es de nota y SÍ va a tener un impacto notable a la hora de procesar peticiones de login en tu aplicación. Para una aplicación pequeña y que requiera máxima seguridad, ideal. Para un Facebook, probablemente no. Existen implementaciones de PBKDF2 en todos los lenguajes típicos
Cifrar datos
Vamos a abordar el tema de cifrar datos, una práctica muy deseable a la hora de trabajar con documentos o con datos.
- Evita el uso de los algoritmos DES y RC4. En el caso de DES principalmente porque hay alternativas mucho mejores en cuanto a algoritmos de cifrado 'de bloque', el tiempo que inviertas en implementar uno mejor, va a ser idéntico a usar el desfasado DES. En el caso de RC4 la cosa cambia, es un algoritmo 'simpático', muy fácil de implementar al ser 'de flujo'. No requiere complicarse y por tanto resulta tentador usarlo (honestamente, para un desarrollo cuyo nivel de seguridad sea bajo puede ser una opción)
- Cuando uses un algoritmo 'de bloque', como AES, GOST o Blowfish, siempre usa el modo 'CBC' que impide que un mismo dato tenga el mismo aspecto en diferentes puntos de los datos cifrados. Si usas, por ejemplo, el modo ECB, significa que la representación cifrada de 'securitybydefault' siempre tendrá el mismo aspecto una vez cifrado, lo que puede facilitar el criptoanálisis.
- Algoritmos deseados: AES, Blowfish y si te fías de los rusos, GOST
Desplegar SSL
Vamos con la forma más optima de desplegar un servicio bajo SSL
- Usa certificados de 2048 bits. Ahora es lo mínimo exigible, de hecho, muchas CAs no admiten peticiones por debajo de esa longitud.
- Mejor certificados EV que certificados convencionales. Eso sí, son más costosos en tiempo y dinero. Siempre puedes empezar con uno tradicional e ir preparando los requerimientos de un certificado EV.
- Deshabilita SSL v2. Hoy día no existen razones reales de compatibilidad que hagan necesario el uso de esa versión del protocolo
- Obvia algoritmos de baja calidad, en concreto RC4, aunque lo deseable es configurar tu servidor para que solo use algoritmos de alta seguridad
- Habilita en tu servidor el uso de 'HTTP Strict Transport Security' esto instruye al navegador para que, una vez visitado un sitio bajo SSL, se niegue a hacerlo bajo HTTP lo que protege a tus usuarios de ataques 'sslstrip'
Fuente: Security by Default