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.

Sobre paralelismo y concurrencia

Mucha gente no diferencia entre concurrencia y paralelismo, aunque ténicamente tienen sus diferencias, que podrían empezar a divisarse en:

Concurrent = Two queues and one coffee machine.

Parallel = Two queues and two coffee machines.

Aunque, según el autor la cosa va más allá. Dice, hacia el final:

We’ve discussed differences between parallel, computational systems and
concurrent, event handling systems. Areas of differences include:

* Determinism: desirable vs impossible
* Sign of parallel safety: same results vs correct results
* Parallelism bugs: easy to pinpoint vs impossible to define
* Queues: implementation detail vs part of the interface
* Preemption: nearly useless vs nearly essential

Me gustó leerlo.

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.

Una cámara móvil

Una vez que tenemos un bot que nos permite controlar remotamente nuestro proyecto (Segundo bot: avanzamos) y sabemos mover los motores (Movimiento suave con los servos) llega el momento de montar la cámara encima (Una cámara en la Raspberry Pi) y controlarla remotamente.
Recordemos que el control se hace mediante XMPP (por ejemplo, con programas como Pidgin, Google Talk o nuestro cliente de mensajería favorito); la idea era evitar abrir puertos en el router para controlarlo vía web y, sin embargo, poder enviar instrucciones desde internet sin problemas.

Para el montaje seleccionamos un par de cajas (como forma barata y simple de proporcionar el soporte para todo). En una caja más grande hicimos un par de agujeros (para poder colocar dos motores, aunque finalmente sólo hemos utilizado uno):

Hemos pintado la caja #raspi

A post shared by Fernando Tricas García (@ftricas) on

Dentro de la caja van las conexiones (baterías para alimentar los motores, y cables para controlarlos desde la Raspberry Pi, que se queda fuera de la caja).

Caja como soporte para los motores

A post shared by Fernando Tricas García (@ftricas) on

La cámara se monta en una caja más pequeña que se sujeta al servo seleccionado.

Y tenemos un prototipo de mejor aspecto #raspi

A post shared by Fernando Tricas García (@ftricas) on

Cuando se le da la instrucción de movimiento, la cámara va a la posición elegida, se detiene para hacer la foto y la envía por correo. Finalmente, vuelve a su posición inicial.
Toda la secuencia puede verse en el siguiente vídeo.

El código del proyecto está disponible en err-plugins (puede evolucionar más adelante; el código en su estado actual puede verse en pruebas.py).

Recientemente se publicó un proyecto similar en “Raspberry Eye” Remote Servo Cam. Tiene dos diferencias fundamentales: se han incluido movimientos en dos ejes (nuestro proyecto sólo se mueve a derecha e izquierda) y se controla mediante una página web.

¿Qué haremos a continuación?
Tengo varias ideas, pero no se todavía qué haré: sería interesante que la cámara tuviera cierta autonomía (¿detección de movimiento o cambios en la escena?); tampoco me importaría pensar en movilidad real (¿embarcar la cámara en algún tipo de dispositivo con ruedas? me encantó este hexápodo).
Yendo más allá, tal vez podríamos pensar en otros dispositivos de control (¿wearables?).

Por supuesto, ideas, comentarios, sugerencias… Serán bienvenidos.

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.

¿Quién está en mi red?

En nuestra red casera puede venir bien conocer las IPs de los dispositivos conectados: una posibilidad es asignar direcciones fijas a los nuevos dispositivos pero es una lata asignarlas, gestionarlas y las soluciones no escalan bien en cuanto se añaden nuevos aparatitos (que es algo cada vez más frecuente).

Por eso me gustó mucho cuando descubrí Fing que era una aplicación para android (ahora se puede instalar en android, iOs, e incluso en ordenadores de escritorio) y anduve buscando la forma de emularla en mi escritorio (algo que ahora ya no sería necesario).

Las sugerencias iban en dos direcciones: nmap, y arp que no son herramientas con las que esté muy familiarizado. Sin embargo, encontré en alguna parte un aviso sobre la existencia del proyecto WiFinder, cuyo uso propuesto era generar una alerta cuando nuevos dispositivos entraban en la red. Hize mi propio fork del proyecto y estuve trabajando un rato para tratar de obtener lo que buscaba.

La solución es un programita, macfinder.py (enlace a la versión que se comenta aquí, en macfinder.py la versión que podrá evolucionar) que me ha servido para juguetear un poco con Python y estas cosas de redes. Todavía me faltaría mejorar la entrada/salida y cómo lo voy a usar, pero las ideas fundamentales están disponibles:

import nmap # import nmap.py

...
nm = nmap.PortScanner() # creates an'instance of nmap.PortScanner

Necesitaremos escanear los puertos, con la instrucción:

nm.scan(hosts='192.168.1.0/24', arguments='-n -sP -PE -T5')
# executes a ping scan

hosts_list = [(nm[x]['addresses']) for x in nm.all_hosts()]

De la lista que obtenemos vamos guardándo los datos utilizando como clave la mac (que es lo que permanece fijo en cada dispositivo), dando de alta los nuevos dispositivos encontrados cada vez:

if not ipList.has_key(addresses['mac']):
	ipList[addresses['mac']] = ("", addresses['ipv4'])

La estructura de datos es un ‘hash’ indexado por la MAC y que contiene la ip y un nombre que podemos asignar al dispositivo (igual que se hace con Fing).

Para la persistencia utilizamos pickle.
Lectura:

ipList=pickle.load(fIP)

Escritura:

fIP = open(fileName,"w")
pickle.dump(ipList,fIP)

Finalmente, algo que no tengo muy claro: Fing no necesita permisos especiales para ejecutarse (o al menos no debería, siendo una aplicación móvil en su origen) pero para que el nmap obtenga las MACs es necesario ejecutarlo con privilegios elevados (el programa debe ejecutarse con sudo y tener los permisos necesarios). Pero todo el mundo sabe que no es bueno que un programa tenga privilegios altos durante mucho tiempo, así que aproveché para aprender a hacer eso en Python. Con el consejo de: Dropping Root Permissions In Python se incluye la función drop_privileges, que justamente hace eso, con:

user_name = os.getenv("SUDO_USER")
pwnam = pwd.getpwnam(user_name)

obtenemos los datos del usuario que ha lanzado el proceso con sudo.
Con:

# Try setting the new uid/gid
os.setgid(pwnam.pw_gid)
os.setuid(pwnam.pw_uid)

Asignamos los permisos del usuario en lugar de los permisos elevados.

Esto lo hacemos en el programa, claro, cuando ya no necesitamos los privilegios altos (esto es, justo depués de utilizar el nmap).

Si hay ideas para mejorarlo, consultas, …

¿Deberían informar los sitios web sobre sus mecanismos internos?

La pregunta la hace Troy Hunt en Should websites be required to publicly disclose their password storage strategy?: hemos olvidado nuestra clave en un sitio y pedimos recuperarla; nos llega un correo electrónico con nuestra clave; un sudor frío empieza a recorrer nuestra espalda.

O vale, no nos la manda, porque dicen que no pueden/no quieren, ¿lo estarán haciendo suficientemente bien? ¿Me importa? ¿Le importa a los usuarios?

Sobre el recordatorio de contraseñas:

Another reason this doesn’t make much sense is that many websites leak information about the password storage mechanism anyway. Ever used a “forgot password feature” and been emailed your password? There’s disclosure that they’re not hashing it so it’s either immediately accessible once the database is disclosed or accessible once the key is obtained and once a box is popped, this is very, very frequently a trivial task. There’s an entire site dedicated to naming these purveyors of poor password management over at plaintextoffenders.com so certainly there is voluminous public data on them already.

Y tampoco es tan sencillo:

Password storage isn’t always just as simple as “we use this hashing algorithm with this salt” and indeed the protections offered by, say, symmetric encryption may be as good as null and void if the key management strategy is bad. So how much information should be disclosed? Where do you draw the line between a simple statement as seen in the badges above and a more comprehensive – and perhaps revealing – statement of a website’s security position?

Vale la pena, en todo caso, darle un par de vueltas al tema antes de tomar decisiones en nuestros propios desarrollos.