La criptografía casi nunca es la parte débil de un sistema (lo que no nos impide recordar que inventar criptografía es difícil y que es mejor no hacer experimentos con eso). Ya hace unos meses hubo un caso en el que el FBI solicitó a Apple que aligerara los medios de protección del iPhone de un terrorista, tratando de obtener la posible información que pudiera haber en su teléfono. Apple se negó y aquello hizo bastante ruido, que llegó incluso a los noticieros ‘normales’.

Me gustó ver Encryption isn’t at stake, the FBI knows Apple already has the desired key donde se comenta sobre el tema, y las ténicas que se utilizan para proteger la información del iPhone.

En primer lugar, para evitar los ataques de fuerza bruta contra el PIN, retrasan los intentos a partir del cuarto (cada vez cuesta más seguir probando), el teléfono se puede configurar para que se borre después del décimo intento fallido y finalmente, la forma de conseguir la clave de descifrado a partir del PIN también es lenta:

PINs, especially four-digit PINs, are highly susceptible to brute-force attacks. With four digits and hence only 10,000 possible combinations, it’s straightforward to simply try every number in sequence until you hit the right one. To combat this, the iPhone uses three specific techniques.

The first is that the iPhone imposes delays between PIN attempts. While the first four attempts can be entered back-to-back, the iPhone will force you to wait one minute before the fifth attempt, five minutes before the sixth, 15 minutes before the seventh and eighth, and a full hour before the ninth.

The second technique is that the iPhone can be configured to wipe the device after ten failed PIN attempts. When this option is turned on, the phone will discard its file system key after 10 bad PINs, rendering all the file system metadata (including the per-file keys) permanently inaccessible.

The third and final technique is that the computation used to derive the PIN key from the PIN itself is slow, taking approximately 80 milliseconds.

Por lo tanto, lo que el FBI trataba de conseguir era aligerar esas restricciones para lanzar sus propios ataques de fuerza bruta con ciertas garantías.

The FBI is asking for Apple to create a custom iPhone firmware that removes the escalating delays and omits the device wipe.

En definitiva, están reconociendo que el cifrado es bueno, y sólo tratarían de saltarse una de las barreras alrededor de ese cifrado.

Overall, the FBI’s request could be seen as a testament to just how good encryption is. The FBI can’t attack the iPhone’s encryption directly, and it can’t bypass the firmware signature mechanism. There’s no existing backdoor to the crypto.

Intersante

Después de la eterna discusión sobre qué lenguaje es mejor o peor y si dejamos de lado por un momento el hecho de que, probablemente, deberíamos elegir el lenguaje en función del proyecto y sus objetivos, es cierto que cada uno (y una) tenemos algún lenguaje en nuestro corazoncito.

En What’s Your Secondary Language? se concentran en la siguiente pregunta: una vez que tienes claro cuál es tu lenguaje favorito, ¿cuál sería el siguiente?

The important question is not “Which programming language is best?” but “What’s your secondary language?” The language you reach for to solve problems, prove that ideas work before implementing them for real, and to do interesting things with files and data.

En mi caso diría que mi lenguaje favorito es, siguiendo la línea expresada arriba, el que toca en cada momento: de vez en cuando C, pero también Perl (que no elegiría voluntariamente jamás, creo), u otros…

Pero cuando quiero hacer pruebas, jugar y desarrollar pequeños proyectos, elijo Python. Y últimamente, que hago más de esto que desarrollos más serios tengo que decir que casi se ha convertido también en el primero. Tampoco le hago ascos a un programita en la shell (shellscript) para un apaño rápido.

Eso sí, también tengo claro que no dejaría de hacer un proyecto porque tuviera que usar un lenguaje que me gusta menos, o aprender uno nuevo.

Una pequeña provocación en How to Fix Authentication: Email as a Password Manager que, en realidad, se parece bastante a lo que ya mucha gente usa cuando accede a sitios poco habituales. En estos casos, en muchas ocasiones, le damos al botón de reiniciar la contraseña, que nos llega al correo.

We want to propose dead simple and secure approach to authentication. Your email account is a password manager out-of-box. The idea is to remove passwords from classic authentication scheme and stick to email only: every time user wants to log in / sign up your app sends a link with one time password to their email

Según el autor tiene muchas ventajas que incluyen la simplicidad, no necesitar productos adicionales, gratuidad, …

No se si puede ser válido para cualquier producto pero, desde luego, es cierto que podría resolvernos algunos problemas.

Siempre que hablamos de seguridad en informática tenemos que recordar que algunas herramientas las terminan usando niños y que, con ellos, todavía debemos ser más cuidadosos con la gestión de datos y otros detalles.

Una opción es la táctica del avestruz: prohíbimos y nos quedamos tranquilos. Suponiendo que nos creamos que esa prohibición tiene algún efecto. Mi opinión siempre ha sido que deberíamos facilitar que los niños utilicen las aplicaciones (Siempre que tenga sentido, claro) y que sea fácil para sus padres poder controlar qué sucede con ese uso.

En todo caso, en Tech Toys And The Child Protection In The Age Of The IoT nos recuerda cómo se les ha ido la cabeza a algunos fabricantes y ponen características potencialmente peligrosas en los juguetes sin prestar mucha más atención. Y los padres las compran.

Let’s face it. Even the most powerful governments in the world are far from immune to hackers. Tell me now that you still believe that some cheap products like the internet-connected dolls and baby cams are better protected? Think again.

Hablan de la ‘internet of toys’, esto es la internet de los juguetes y los riesgos que se están asumiendo por puras estrategias que sólo se preocupan de la parte comercial.

No decimos que no haya que conectar los juguetes, o darles características que se consideran interesantes (si no, el juguete elegido será otro y ya está) pero con los niños hay que tener todavía más cuidado.

Moreover, for that alone, when dealing with children in an IoT context, their security and privacy must be your priority. In a tech toys context, the child protection must be paramount to you. You, the parent. You, the IoT maker. Right from day one.

Continúa dando algunos consejos intersantes: cifrar, compartimentalizar, proteger, no almacenar datos, actualizar, …

¡Atención!

De vez en cuando alguien se anima a preparar un resumen. A los que ya saben del tema les sirve para recordar algún aspecto en el que se habían despistado y a los que no, puede ser una buena forma de introducirlos y motivarlos.

En esta ocasión se trata de Martin Fowler y su The Basics of Web Application Security.

Interesante