Un ejercicio curioso en Getting a program right, in nine episodes donde Bertrand Meyer nos acompaña donde desarrolla un programa sencillo y lo va mejorando mediante técnicas de verificación formal.

Aunque el testing ha ganado muchos adeptos hay que recordar lo que decía Dijkstra: las pruebas pueden demostrar la presencia de errores, no su ausencia.

in fact, I have always thought that the inevitable Dijkstra quote about testing — that it can only show the presence of errors, not their absence

Esto no es hablar mal de las pruebas, es sensacional poder encontrar partes de nuestros programas que están mal.

La verificación aporta otro tipo de valores, y de eso va lo que se puede leer allí. El programa es una búsqueda binaria, que es un concepto fácil de entender, pero no tan sencillo de hacer complemtamente bien.

Interesante.

De la mano de blockchain han venido los smart contracts: se trata de ‘programas’ o ‘codificaciones’ de intenciones, condiciones y consecuencias que gracias a esta tecnología permitirían que determinados contratos puedan ejecutarse sin necesidad de que los humanos intervengan (en la realización de los hechos del contrato en sí, se entiende).

Desde la ignorancia informada, uno siempre ha pensado que si se ha de codificar determinadas condiciones de la vida en un contrato la cosa ya es suficientemente compleja. Si a eso le añadimos la ejecución automatizada, es probable que haya que hilar más fino. Y, claro, aparecen los bugs y las vulnerabilidades.

De esto hablaban en Las 5 vulnerabilidades más habituales de los Smart Contracts y lo más gracioso es que los fallos se parecen mucho a los de los programas ‘normales’.

• Errores aritméticos con números enteros

Desbordamientos, falta de precisión, …

• Vulnerabilidades del límite de block gas

El límite de block gas es la forma que tiene Ethereum de asegurarse de que los bloques no crezcan demasiado. Simplemente significa que los bloques están limitados en la cantidad de gas que las transacciones contenidas en dichos bloques pueden consumir. En pocas palabras, si una transacción consume demasiado gas nunca cabrá en un bloque y, por lo tanto, nunca se ejecutará.

En determinadas circunstancias esto provoca que haya instrucciones de los contratos que nunca llegan a ejecutarse.

• Falta de parámetros o controles de precondición

Si hace falta que algo se cumpla a la hora de ejecutar un contrato, debemos estar seguros de que los datos que se reciben son adecuados.

• Frontrunning

El frontrunning potencial es probablemente el tema más difícil de prevenir en nuestra lista de vulnerabilidades comunes. Este puede definirse como la apropiación de una transacción no confirmada, y es consecuencia de la propiedad de transparencia del blockchain.

• Bugs de lógica simples.

No hace falta buscar, de todas formas, fallos muy sofisticados. Parece que es frecuente encontrar:

… el problema más común que detectamos es la presencia de errores simples en la lógica del smart contract. Estos errores pueden ser el resultado de una simple errata, una mala comprensión de la especificación o un error de programación mayor …

Interesante.

Esta entrada habla de Python, pero a veces por desconocimiento (o comodidad) no utilizamos todas las características de nuestros lenguajes favoritos y me pareció de interés.

En Reduce Memory Usage and Make Your Python Code Faster Using Generators hablan de los generadores, como un mecanismo para gastar menos memoria y generar un código más eficiente en Python.

Técnicamente, un generador es una función que utiliza yield en lugar de return nos dice el autor.

A generator looks a lot like a function, but uses the keyword yieldinstead of return. Let us take an example for better understanding.

Cuando hacemos una llamada tenemos un valor, pero con algunas característias interesantes. Por ejemplo, la función next(), que nos devolverá el siguiente valor generado por la función original (esto es, es una función que nos puede ir proporcionando valores sucesivos).

The important thing to note is how state is encapsulated within the body of the generator function. You can also step through one by one, using the built-in next() function:

En Python podemos utilizar la función range() para generar una sucesión de valores, que genera(ba) un coste importante (según el tamaño, claro) en espacio y tiempo al ejecutarse. Aunque allí no se dice, que hace mucho tiempo que teníamos xrange() y que en Python 3 range() también es un generador, con lo que el problema no sería tal.

En todo caso, parece que casi siempre merece la pena evaluar las consecuencias de las estructuras que utilizamos.

Uno de los consejos que se dan siempre en criptografía, es no inventar nada. El tema es suficientemente complejo para que alguien con poca experiencia pueda equivocarse y hacerlo mal. En Rolling your own encryption. What could possibly go wrong? hacen un pequeño recorrido (con código en Python) por diversos métodos de cifrado a modo de divertimento (y sin ninguna garantía de calidad).

Encryption is tricky to get right. Because some data and communications might be very sensitive or even life-critical for people, beginners are often - and quite rudely- shunned away from playing around with how it works. But if people don’t learn by making bad ciphers, they will have difficulty understanding why the good ones are good.

Uno de mis temas favoritos en cuanto a problemas de seguridad son los programas desarrollados para protegerla que resultan ser vulnerables. En esta ocasión podemos leer Some commercial password managers vulnerable to attack by fake apps que habla de gestores de contraseñas y algunas vulnerabilidades. Reconozcámoslo, la seguridad no es fácil: hay muchas cosas que se pueden hacer mal y es complicado hacerlo todo bien.

Algunos de estos programas utilizaban métodos débiles para identificar una aplicación y qué credenciales había que usar con ella (hacer las cosas más fáciles puede hacerlas demasiado fáciles).

… some of the password managers used weak criteria for identifying an app and which username and password to suggest for autofill. This weakness allowed the researchers to impersonate a legitimate app simply by creating a rogue app with an identical name.

Esto significa que si engañamos al usuario para que instale una aplicación falsa ‘adecuada’ podríamos conseguirlas.

“Our study shows that a phishing attack from a malicious app is highly feasible – if a victim is tricked into installing a malicious app it will be able to present itself as a legitimate option on the autofill prompt and have a high chance of success.”

La recomendación frente a esto es utilizar doble factor de autentificación: pueden robarnos las credenciales pero será difícil que tengan, además, el dispositivo para el segundo factor.

“The risk presented with autofill on compromised websites pertains only to the site’s credentials, not the user’s entire vault. It is always in the user’s best interest to enable MFA for all online accounts …

Había otros problemas, por ejemplo, no había limitaciones sobre el número de veces que se podía comprobar un PIN.

The researchers also discovered some password managers did not have a limit on the number of times a master PIN or password could be entered. This means that if hackers had access to an individual’s device they could launch a “brute force” attack, guessing a four digit PIN in around 2.5 hours.

Claro que, en este caso, el doble factor probablemente tampoco ayudaría.

Otro de mis favoritos en seguridad es lo que sucede muchas veces: problemas de seguridad detectados y anunciados anteriormente siguen allí.

The researchers also drew up a list of vulnerabilities identified in a previous study and tested whether they had been resolved. They found that while the most serious of these issues had been fixed, many had not been addressed.

Interesante.