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: […]

En seguridad informática parece que vivimos el día de la marmota: los temas vuelven sistemáticamente, de tiempo en tiempo. Hoy, los avisos de seguridad y cómo la gente los ignora. Nos lo contaban en People ignore software security warnings up to 90 percent of the time.

Decimos de la gente pero, en realidad, probablemente la culpa sea de los que diseñan los sistemas: o avisan de cosas poco importantes, o cuando no es apropiado (¿alguien recuerda cuando configuró su teléfono o su portátil y empezó a pedirle cosas absurdas cuando lo que en realidad queríamos era volver a estar conectados y trabajando?)

Software developers listen up: if you want people to pay attention to your security warnings on their computers or mobile devices, you need to make them pop up at better times.

Según el estudio que se comenta, uno de los problemas fundamentales es que los avisos llegan cuando la gente está concentrada haciendo otra cosa:

… finds the status quo of warning messages appearing haphazardly—while people are typing, watching a video, uploading files, etc.—results in up to 90 percent of users disregarding them.

Algunos datos, el 74 por ciento de la gente ignora un mensaje de seguridad que aparece cuando estamos cerrando una ventana, y un 79 por ciento no presta atención a los mensajes mientras vemos un vídeo.

For example, 74 percent of people in the study ignored security messages that popped up while they were on the way to close a web page window. Another 79 percent ignored the messages if they were watching a video. And a whopping 87 percent disregarded the messages while they were transferring information, in this case, a confirmation code.

¿Cuándo sería un momento más apropiado? Aparentemente, cuando tenemos momentos de espera o de actividad menor: después de ver un vídeo, mientras se carga una página web, después de utilizar un sitio web…

people pay the most attention to security messages when they pop up in lower dual task times such as:

After watching a video

Waiting for a page to load

After interacting with a website