Hacía mucho que no hablábamos de la seguridad (informática) de los coches. Hace algunas semanas leía Insecure wheels: Police turn to car data to destroy suspects’ alibis y me pareció interesante para comentarlo aquí.

En general, no somos muy conscientes de la falta de conocimiento sobre ello que tenemos ni tampoco de la falta de seguridad de los sisstemas de entretenimiento e información de los vehículos. Lo que el vehículo puede registrar, por ejemplo.

the relative lack of public awareness about and lack of security in vehicle infotainment systems

Esto se complica con las capacidades cada vez mayores, con mejores y más sensores, lo que todavía genera más información.

As automobiles become more automated, with self-parking and other “smart” features, they need more sophisticated sensors and computers, which means autos of the future will collect even more data, digital forensic and privacy experts say.

Todo ello puede, en un momento dado, ayudar a resolver un crimen. Pero también puede ayudar a cometerlo.

Just as the trove of data can be helpful for solving crimes, it can also be used to commit them

Y no parece haber (o no está muy claro) leyes que determinen los datos que el vehículo puede conservar. Ni lo que el fabricante hará con ellos.

No federal laws regulate what automakers can collect or do with the vast majority of our driving data.

No es raro tampoco adquirir un vehículo (o para el caso, cualquier dispositivo) y que contenga datos de sus ‘vidas anteriores’.

… each of the modules he bought had “owner’s home and work location, all saved Wi-Fi passwords, calendar entries from the phone, call lists and address books from paired phones, Netflix and other stored session cookies.”

De hecho, enviaron personas a los concesionarios para probar coches de segunda mano. Y en un porcentaje alto (hasta el 88%) encontraron datos personales de propietarios y usuarios anteriores.

While they were in the vehicles, they checked the infotainment systems to see whether there was any remnant personal information from previous owners. Eighty-eight percent of the shoppers found personal data left on the vehicles, such as home addresses or phone numbers.

¡Cuidado! ¿Sabrás borrar tus datos personales de tu vehículo cuando lo cambies? ¿Tiene algún mecanismo para evitar que alguien pueda ver, por ejemplo, tu agenda de contactos?

La proliferación del JavaScript en los clientes, pero también las aplicaciones móviles y, como no, la necesidad de separar la acción de la presentación ha hecho que prolifere el uso de APIs (interfaces de programación de aplicaciones) y es una cosa buena, ya lo decía Bill Joy the Sun Microsytems: ‘la gente más brillante no trabaja para ti’.

no matter who you are, most of the smartest people work for someone else

Así que si, además de tener APIs, las ponemos a disposición de otros es posible que les ayudemos y que nos ayuden. Pero claro, cualquier decisión que tomamos tiene consecuencias desde el punto de vista de la seguridad y de eso hablaba API Security Best Practices que nos recomienda cosas muy básicas, como utilizar https, autentificación, mecanimos de autorización y otras similares. Está bien recordar que en este contexto (a veces más restringido, porque hace falta autorización, o no es tan conocido como la web, o …) hace falta tener las mismas precauciones de seguridad que en cualquier otro proyecto.

Otro tutorial, esta vez sobre las ‘cookies’ en A practical, Complete Tutorial on HTTP cookies. Con ejemplos en Flask que es una tecnología cercana al Python que conozco poc y que, tal vez, debería explorar.

Incluye:

• Trabajar con cookies en el frontal y en el servidor.
• Seguridad y permisos de las cookies.
• Interacción entre cookies, AJAX y CORS.

Cuando maneja estas cosas en su día a día está bien refrescar y conocer lo que va habiendo (y cambiando). Cuando no, leer estos artículos es como una ‘gimnasia’ `para no despistarse si alguna vez lo llegamos a necesitar.

De vez en cuando alguien nos pone al día de los nuevos (y viejos) temas de seguridad web que tenemos que tener en cuenta. Son entradas que no hay que tomar como palabra de ley, porque siempre puede olvidarse algo o darle más importancia de la necesaria, pero nos sirven de recordatorio y para repasar.

En este caso hablamos de Web security knowledge you must understand it (Part I: HTTPS, TLS, SSL, CORS, CSP).

Interesante.

Ya hemos hablado otras veces de criptografía: que no hay que inventarla, que hay que usar métodos conocidos y reconocidos… Sin embargo, no es tan fácil ponerse a utilizar criptografía, sobre todo cuando lo que alguien quiere es tan sencillo como cifrar sus datos de manera razonable, sin tener que convertirse en un critptógrafo o un criptoanalista. Por eso me gustó leer Cryptography for programmers 2: Blocks and Randomness donde explican justamnente esa parte, los bloques y cómo se emplean en el cifrado y el tema de la aleatoriedad (otro ‘favorito’ de este sitio).

Si alguien está interesado la entrada forma parte de una serie de cuatro, dedicadas a los principios básicos, y otros temas interesantes, además de este.

Se habla de cifrado simétrico y asimétrico para luego hablar de la criptografía de bloques, que es la que suele utilizarse cuando se habla de cifrado simétrico.

Block cryptography is the default symmetric cryptography used nowadays, and so it will be the only symmetric cryptography that will be covered in the series.

La idea es cifrar una cantidad fija de bits mediante un algoritmo simétrico y los bloques nos permiten manejar estas cuestiones. Luego pasa a explicarnos qué tipo de bloques serían recomendables.

For the purpose of this post I would say as a programmer there is no reason you should be using anything other than AES. AES is the current standard, it is secure enough and will very likely continue to be for a long time, specially if you are using the variant with a 256 bit key, which I would recommend.

Luego habla de los generadores de números seudoaleatorios, que es un tema que hemos tocado más veces aquí.

Interesante.