De vez en cuando nos salimos un poco más del tema y traemos alguna curiosidad. En este caso tiene que ver con amebas y problemas difíciles, de la mano de An Amoeba-Based Computer Calculated Approximate Solutions to a Very Hard Math Problem.

El problema difícil es el viejo conocido del viajante de comercio (Travelling Salesman problem TSP) y podemos hablar de computación biológica (y no la más habitual, que es la bioinspirada). No se si vale la pena recordar que el problema consiste en determinar un recorrido óptimo para visitar una serie de ciudades volviendo a la de origen y pasando una vez por cada una. A pesar de lo sencillo que es describirlo, es un problema que es costoso de resolver de forma exacta cuando el número de ciudades crece.

Por lo visto las amebas son capaces de generar soluciones aproximadas al problema (recordamos aquí que cuando los problemas son difíciles -desde el punto de vista del coste, aclaro- nos conformamos con tener soluciones aproximadas suficientemente buenas).

A team of Japanese researchers from Keio University in Tokyo have demonstrated that an amoeba is capable of generating approximate solutions to a remarkably difficult math problem known as the “traveling salesman problem.”

Por lo visto, lo resuelven hasta 8 ciudades con una calidad de la solución bastante buena, en un tiempo que crece de manera lineal:

Yet as these Japanese researchers demonstrated, a certain type of amoeba can be used to calculate nearly optimal solutions to the traveling salesman problem for up to eight cities. Even more remarkably, the amount of time it takes the amoeba to reach these nearly optimal solutions grows linearly, even though the number of possible solutions increases exponentially.

Por lo visto, este tipo de amebas son capaces de expandir su cuerpo en varias direcciones en busca de alimento, lo que las hace particularmente interesantes:

The reason this amoeba is considered especially useful in biological computing is because it can extend various regions of its body to find the most efficient way to a food source and hates light.

¿Cuándo podremos usar esto? De momento son solo experimentos de laboratorio que podrían ser la base para construir computadores biológicos de bajo consumo energético. Esto es, de momento, no.

For now, however, the Japanese researchers’ experiment remains in the lab, but it provides the foundation for low-energy biological computers that harness the natural mechanisms of amoebas and other microorganisms to compute.

Que Europa tiene un papel puramente seguidista en tecnología no es algo que vayamos a descubrir aquí y ahora. De los temas regulatorios ni hablamos. Creo que los factores que contribuyen a ello son muchos y merecerían un análisis que alguien debería hacer.

Los botines por descubrimiento de fallos (Bug Bounties) es algo que existe desde hace tiempo pero que en los últimos años ha cobrado mucha importancia: una empresa, organización o lo que sea paga a los que descubren fallos para agradecerles el hallazgo y también para incentivar que se lo comuniquen a ellos, en lugar de a los ‘malos’.

La revisión de software libre por diversos organismos y empresas también tiene una cierta tradición (podemos recordar el caso de Coverity Scan OOS. La empresa facilita los informes a los desarrolladores para que mejoren el software que tanta gente usa.

Finalmente, vale la pena recordar, que uno de los fallos de seguridad más importantes es la utilización de componentes de terceros (ver, por ejemplo Component Analysis).

Así que, con todo este preámbulo, me llevé un alegrón al conocer que In January, the EU starts running Bug Bounties on Free and Open Source Software . Esto es, Europa financia la búsquead y localización de fallos en programas de software libre.

Cuentan como se realizó un inventario del software libre que utilizan e incluso auditaron Apache y KeePass EU aims to increase the security of password manager and web server software: KeePass and Apache chosen for open source audits.

Ahora han decidido lanzar un serie de recompensas sobre los proyectos que han considerado más importante: incluyen Filezilla, Apache Kafka, Notepad++, Putty y otros… La lista.

el proyecto tiene su propia página web FOSSA y nos hace pensar que, a veces, se hacen algunas cosas bien.

Me reconozco un gran usuario de la línea de instrucciones en una terminal: cuando se maneja medianamente la productividad puede ser excelente. Por eso me gustó leer Some of My Favorite Shell Aliases From Over the Years donde Daniel Miessler nos da algunas recomendaciones. Los expresa en forma de alias, para tener que teclear menos.

Por ejemplo, para buscar:

$ alias f="find . -name"

O algo que pregunta muchas veces la gente nueva, ¿cómo se mi IP?:

$ alias gip="curl ipinfo.io/ip && curl ipinfo.io/org"

Un generador de contraseñas:

$ alias np="openssl rand -base64 24"

Y algunos más. Interesante.

Hay una cierta tradición de hacer listas de ‘verdades’ que los programadores creen sobre determinados aspectos (nombres, tiempo, fechas, …) y que no tienen por qué se ciertas. Típicamente tienen que ver con temas culturales y de internacionalización, que no son siempre tenidos en cuenta por los desarrolladores habituales. Recientemente podíamos leer Falsehoods Programmers Believe About Names – With Examples que nos trae de nuevo el tema de los nombres, y al que vale la pena echar un vistazo.

Creo que puede ser un texto interesante incluso para personas que no programan, por lo que se puede aprender de otras culturas y formas de hacer las cosas. Para desarrolladores, es posible que alguna vez tengan que enfrentarse a estos dilemas.

Algunos administradores que pueden hacerlo (seguramente, los mismos que pueden obligarnos a cambiar de contraseña, como contábamos en Los cambios frecuentes de contraseña son contraproducentes creen que añadir una restricción a nuestra contraseña indicando que contenga una cifra y un caracter especial (o variaciones similares) mejora las contraseñas. Lo cierto es que, si permitimos estos caracteres en las claves puede que mejoren (siempre que no se hagan substituciones obvias: l por 1, e por 3, …). Pero siobligamos a que estén, le estamos dando pistas a los ‘malos’: pueden hacer búsquedas en el espacio de claves, poniendo menos alternativas en algunas posiciones (el caso más delirante, que he visto en un par de sitios es ‘forzar’ a que esos caracteres estén en determinadas posiciones). Sin olvidarnos de que cuando eso contraviene nuestras propias costumbres en la generación de contraseñas, tenemos la receta segura para que no la recordemos, o la hagamos peor para estar seguros de recordarla.

De eso hablaban en How Password Constraints Give You a False Sense of Security y yo lo traigo aquí para animar a tantos y tantos administradores a no ser creativos en estas cosas.

Hace un poco de numerología con lo que ahorraría un hipotético atacante sabiendo que tiene que haber, digamos, un dígito:

Assume they can test about 31 billion passwords per second. Cracking their way through your reasonably complicated eight-character password could take, at most, 212,903 seconds. That’s 3,548 minutes, or roughly two and a half days.

Now, let’s talk about constraints for a minute. Assume that the service you’re using requires you to have an eight-character password. Abrams notes that takes 70.6 trillion passwords out of the mix, since every password from a single character long to seven character long is now invalid. That saves the cracking tool a whopping 2,277 seconds, or nearly 38 minutes. That’s not too bad.

Vale la pena leer el resto de argumentos numéricos pero, al final, la conclusión es que lo mejor es que la contraseña sea más larga, incluso en sistemas con restricciones.

Instead of worrying about the best way to make your shorter password harder to guess or brute-force, Abrams advises that it’s a lot better to pick a longer password, because even if a service has password constraints, they’ll have much less of an impact: […]