Los programadores y la criptografía

En why I don’t touch crypto explican un par de buenas razones para no tratar de inventar nada relacionado con la criptografía. Un buen recordatorio:

La generación de números (seudo)aleatorios es un problema difícil y hablan
de un fallo:

Last week’s issue in the random number generator in Cryptocat is a very good example.

The bug was an off-by-one error in their random number generator. The output of the function was still random numbers, looking at the output would clearly show random numbers. Given that fact, the natural bias for seeing code as being correct is only reinforced.

Comprender los conceptos no es suficiente, es muy fácil equivocarse:

I’m just plain not good enough. Crypto is a world where understanding the concepts, understanding the math and writing tests just isn’t good enough.

Contraseñas en Linux

En Arabesque estuvieron escribiendo una interesante serie sobre diversos aspectos de seguridad para el usuario en Linux (el índice en http://blog.sanctum.geek.nz/linux-crypto-introduction/”).

Tal vez volvamos sobre ella pero hoy me gustaría traer aquí el tema de las contraseñas: Linux Crypto: Passwords donde nos habla de pass como utilidad para gestionar las claves que utilizamos habitualmente.

Para los aficionados a los programas con interfaz textual puede ser una buena alternativa a otros métodos publicitados frecuentemente.

Las cabeceras de seguridad para los sitios web más importantes

Aunque la entrada que yo guardé en su día era otra, en Security Headers on the Top 1,000,000 Websites: March 2014 Report se puede encontrar justamente eso: el resumen de un estudio sober el primer millón de sitios más importantes en la web (según Alexa) y las cabeceras relacionadas con la seguridad que envían desde sus páginas web.

Normalmente estas entradas nos pueden servir para bajar un poco los pies a la tierra sobre lo que realmente se está utilizando en la industria y también para echarle un vistazo a todas las cabeceras en las que deberíamos pensar si somos nosotros los que tenemos que tomar la decisión de cuáles enviar.

Si miramos la serie a lo largo de tiempo también pueden ser útiles para ver cómo van cambiando los usos y costumbres.

Finalmente, me gustan porque permiten ver todo lo que se puede saber en la red, con unas pocas herramientas y ganas de hacer los programitas adecuados.

Veo que también han publicado:
Security Headers on the Top 1,000,000 Websites: November 2013 Report.
Security Headers on the Top 1,000,000 Websites: March 2013 Report.
Security Headers on the Top 1,000,000 Websites (noviembre 2012).

Algunas medidas proactivas para la seguridad en aplicaciones web

En Top 10 Proactive Web Application Security Measures.

– Content-Security-Policy
– X-Frame-Options
– anti-CSRF cryptographic nonces
– DAL (data/database access layer)
– Unwritable file system
– Forensically secure logging
– Secure credential/passwd/secret questions and answers storage
– SSL, cookies with secure flags, cookies with httponly and STS
– Security frameworks
– autocomplete=”off” and strong passwords

Sobre las sesiones (más o menos) permanentes

En How to build (and how not to build) a secure “remember me” feature Troy Hunt nos da ideas sobre el botoncito que tienen casi todas las aplicaciones web que permite que la próxima vez que volvamos a utilizarlas recuerden toda (o parte) de nuestra información a la hora de autentificarnos en el sistema.

Cosas que se pueden hacer mal, información que no sería necesaria pero que se almacena de alguna forma…. Y algunos ejemplos del ‘mundo real’ que parece que ya no deberían ser fáciles de encontrar.

Estimación de cores desde el navegador

En navigator.hardwareConcurrency explican una forma de estimar el número de cores del procesador del ordenador del usuario desde el navegador, a la hora de enviarle trabajos de cálculo, si es que tenemos interés en hacerlo.

Curioso.

Las cookies y la seguridad

Todo va cambiando, aparecen nuevas opciones y a veces no estamos al tanto de las novedades en temas que nos interesan. No es tan nuevo pero en C is for cookie, H is for hacker – understanding HTTP only and Secure cookies hay bastante información interesante sobre las cookies y los aspectos relacionados con la seguridad.

Interesante.

Algunas debilidades de HTTPS

Como ya tiene un tiempo y además es algo especulativo (siempre que hablamos de romper métodos de cifra se trata de resultados que teóricamente nos hacen pensar que algo podría ir mal), viene bien traer aquí Has HTTPS finally been cracked? Five researchers deal SSL/TLS a biggish blow….

Se criticaban los algoritmos de generación de números aleatorios (ya hemos hablado del tema en Números aleatorios y seguridad, por ejemplo):

The problem is that although RC4 is a cryptographic PRNG, it’s not a very
high-quality one.

Y también sobre el ataque:

This result, incidentally, was the basis of the attack that broke WEP, the original encryption protocol used in Wi-Fi networking, and forced its replacement with a newer encryption system called WPA.

Los consejos?

If you can, ditch RC4 from the set of symmetric ciphers your web browser is willing to use, and your web servers to accept.

Go for AES-GCM instead.

Usuarios y formación: ¿Batalla perdida?

Cualquier usuario que tenga que elegir entre el camino fácil y el camino seguro elegirá, casi con toda seguridad, el más ‘chulo’ (o el fácil), así que deberíamos confiar poco en que se hará lo correcto y en ese sentido se habla siempre de la formación y la concienciación.
De hecho, la experiencia nos dice que si la seguridad no va de la mano de la comodidad y la sencillez, habremos ganado unos cuantos enemigos más contra nuestro sistema: tratarán de evitar las medidas por los caminos que consideren necesarios.

En Schneier Says User Awareness: Tired, Dev Training: Wired comentaban sobre el consejo de Bruce Schneier:

we should be spending money on security training for developers. These are people who can be taught expertise in a fast-changing environment, and this is a situation where raising the average behavior increases the security of the overall system.

Esto es, mejorar la formación de los desarrolladores (y sus incentivos) para que los usuarios no se preocupen de estos temas.

Se puede leer la opinión de Schneier directamente en On Security Awareness Training donde casi al principio, afirma:

I personally believe that training users in security is generally a waste of time and that the money can be spent better elsewhere. Moreover, I believe that our industry’s focus on training serves to obscure greater failings in security design.