Tengo mis dudas sobre el tema que traigo hoy aquí: porque soy culpable (cuando necesito hacer algo mínimamente complejo busco a ver si alguien ha hecho algo parecido y lo publicó para reutilizarlo). También porque me parece una buena práctica que favorece la economía, robustez…

Sin embargo en NPM & left-pad: Have We Forgotten How To Program? expone algunas quejas que pueden ser relevantes.

Dice que parece que el objetivo de la comunidad alrededor de NPM fuera escribir el mínimo código utilizando bibliotecas de otros para conseguir sus objetivos:

It feels to me as if the entire job of an NPM-participating developer is writing the smallest amount of code possible to string existing library calls together in order to create something new that functions uniquely for their personal or business need.

Sin embargo, no hay ninguna garantía de que esas componentes estén bien (y lo vayan a estar en el futuro, si hay evoluciones de los sistemas):

There’s absolutely no guarantee that what someone else has written is correct, or even works well.

De hecho, esta es una de las grandes prevenciones que se suelen contar en seguridad: no sólo tienes que estar seguro de que tu código es seguro, sino también el que utilices de terceros.

El último argumento que señalé es el de que, según el autor, juntar llamadas a APIs no se puede considerar programar y que puede convertirse en hacer cosas demasiado complejas:

Finally, stringing APIs together and calling it programming doesn’t make it programming. It’s some crazy form of dependency hacking that involves the cloud, over-engineering things, and complexity far beyond what’s actually needed to create great applications.

Me parecen argumentos interesantes, pero que hay que manejar con cuidado: ni hayque volverse locos juntando piezas y creando auténticos ‘Frankensteins’; ni tampoco hay que programar todo desde cero, gastando tiempo en desarrollar cosas que podríamos aprovechar para cubrir lo que es específico a nuestras necesidades.

Los antivirus siguen siendo necesarios: es cierto que no paran lo que no conocen (o lo intentan, pero no siempre lo consiguen) pero colocan una barrera frente a muchos problemas conocidos y reconocidos.

En Why Antivirus Standards of Certification Need to Change hablan de antivirus y de un viejo tema por este sitio: el software de seguridad no siempre es seguro. Tavis Ormandy, del proyecto Zero de Google visita una empresa de desarrollo de antivirus y no podréis creer lo que pasó (frase escandalosa para que pudiera aparecer esto bien posicionado en determinados entornos). Él mismo lo contaba en Security Software Certification.

Ormandy came across one such problem recently.

During his work with Comodo, in whose antivirus solution he discovered “hundreds of critical memory corruption flaws,” the researcher noticed that the security firm was working on receiving its certification from Verizon

Ni que decir tiene, que consiguieron una buena calificación, lo que nos lleva a dos problemas: 1) el antivirus no está desarrollado de forma segura y 2) los que certifican el antivirus no están preocupados por esas cuestiones.

Podrían empezar utilizando alguna metodología ya conocida:

Specifically, the researcher recommends that Verizon integrate parts of Microsoft’s Security Development Lifecycle, including dynamic analysis, fuzz testing, and attack surface review, to test each certification candidate against the reality of today’s threats.

Pero el problema no era exclusivo para esta empresa:

Indeed, in its 2015 State of Infections report, Damballa found that a majority of high-profile antivirus solutions overlooked 70 percent of malware within the first hour.

Y, claro, la consecuencia es todavía peor: instalas el antivirus creyéndote seguro y no lo estás.

¡Atención!

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.