Un programador aburrido

La tendencia ya la conocemos: gente súper-chachi que hace cosas súper-molonas y que se deja la vida en ello. Parece que es un modelo popular y que nos hace imaginar momentos gloriosos porque, ¡oh sorpresa!, casi siempre terminan bien.

I'm a rocker

Sin embargo, cuando hablamos de programas (y de sistemas informáticos en general) lo que esperamos para que todo vaya bien es un comportamiento aburrido: siempre igual, predecible, que no falle y que no haya que dejarse la vida para conseguir nuestros objetivos. Eso sí, esperamos que sean muy emocionantes y nos llenen la vida de ilusiones (vale, muchas veces tampoco, que al final todo es trabajo, resolver problemas y marcharnos a casa tranquilos).

Por eso me gustó leer I’m a boring programmer (and proud of it) donde habla justamente de estas cosas.

El autor prefiere el silencio y el orden:

Instead, like a librarian I enjoy quiet and order. When code is well organized, things are easy to find and less likely to break, avoiding a bunch of noise and heartache.

Le gusta analizar problemas, probar distintas perspectivas y compartir sus descubrimientos con otros:

Like a scientist I enjoy analyzing problems, trying different angles to solve them, and then sharing my findings. I want to understand how things work, and I want others to benefit from that understanding

También tiene su parte artística, utilizando la cratividad y aceptando la imperfección.

Like an artist I need to occasionally think outside the box, tap my creativity, and be able to see in abstracts. I want to embrace imperfection.

Finalmente, como un carpintero, le gusta construir cosas:

And like a carpenter, I really enjoy building things. Sometimes that means following a specific plan, and other times you just work with what you’ve got.

Todas estas características son interesantes y valiosas pero nos alejan del modelo ‘ninja’ o ‘estrella del rock’ que parece tan popular y llamativo.

Bien por él.

Libros sobre programación en C

Si escuchamos/leemos las tendencias modernas el C estaría olvidado en algún rincón y ya nunca nadie le prestaría atención más. Sin embargo, sigue teniendo su hueco en el corazoncito de mucha gente e incluso en los topes: Interactive: The Top Programming Languages 2017 así que, poca broma.

Programando juegos

En todo caso, a mi me pudo la parte más sentimental (algunas líneas de C tiramos en su momento y, pocas veces, alguna vez nos toca mantenerlas, actualizarlas y volver a mirarlas). Por eso recomiendo echarle un ojo a Some Books on C, algunos actuales (y disponibles para descargar) y otros que son clásicos.

Código seguro para dispositivos médicos

Como casi siempre, traemos un informe con un poco de retraso. Lamentablemente (porque siguen apareciendo casos) eso no hace que pierdan actualidad. Por ejemplo, podíamos leer estos días la llamada a 465000 pacientes con marcapasos para una actualización del software de sus dispositivos 465,000 Patients Need Software Updates for Their Hackable Pacemakers, FDA Says. No es la primera vez que hablamos de marcapasos, ni de actualizaciones obligatorias de software, aunque creo que no iban juntos en las otras ocasiones.

Sensor

El informe fue el resultado de un encuentro patrocinado por IEEE Cybersecurity Initiative and the National Science Foundation y Carl Landwehr de la George Washington University y Tom Haigh of Adventium Labs (ret.) fueron los organizadores.

Posteriormente elaboraron el informe [PDF] Building Code for Medical Device Software Security que es bastante básico pero puede servir como llamada de atención para mucha gente, iniciación para algunas personas interesadas y, definitivamente, como recordatorio para las personas con más experiencia.

Algunos errores comunes tratando de arreglar problemas de 'Cross Site Scripting'

El ‘cross site scripting’ es un fallo frecuente en desarrollo web que consiste en permitir a los usuarios inyectar código ejecutable (típicamente javascript pero también otros) en páginas que pueden ver y utilizar otros usuarios. De esta forma los atacantes pueden robar información, saltarse algunos sistemas de control de acceso…

Cruce roto

En Secure Coding 101: 4 Common Mistakes Developers Make When Fixing Cross-Site Scripting nos recuerdan cuatro errores frecuentes:

  • Utilizar listas negras. Por largas y completas que sean siempre será posible que algún atacante encuentre una forma de saltárselas. En seguridad informática siempre que sea posible hay que concentrarse en permitir lo que está bien, y no en prohibir lo que está mal.
  • Aplicar filtros en lugar de ‘escapar’ la salida. Es muy difícil filtrar correctamente todos los caracteres necesarios en una aplicación normal, es mucho mejor aplicar códigos que evitan que determinados caracteres sean interpretados como caracteres de control (comillas, metacaracteres, …).
  • ‘Escapar’ los caracteres de forma inconsistente. Cuando utilizamos esta técnica, hay que hacerlo siempre y en todas las partes de nuestro programa. No sólo para evitar algún problema que ya hemos encontrado (o nos han encontrado).
  • ‘Escapar’ los caracteres que no son. A pesar de que es una solución recomendada, tampoco es trivial de realizar. Por ejemplo, ¿qué sucedería si tus cadenas de texto que han sido tratadas de manera individual son concatenadas después?

La forma de programar

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…

Viejo ordenador

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.

¿Se desarrollan los antivirus de manera segura?

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.

Bicho

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!

Cifrado, seguridad y protección de la informacón: FBI contra Apple

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’.

Enigma

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

¿Cuál es tu segundo lenguaje de programación?

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.

Clase de programación 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.

El correo como sustituto de las contraseñas

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.

Candados

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.