Transmitir conceptos de seguridad a gente ya preparada es más fácil (aunque hasta en eso tengo dudas). Pero cuando hablamos de usuarios finales tenemos realmente un problema. Yo suelo decir que los usuarios (y muchos profesionales) conocen sobre seguridad lo que escuchan/leen en las noticias y esto es bastante preocupante.

De eso hablaban en Escape the Echo Chamber: Educating End-Users and Non-Security People.

El autor lleva tiempo dedicándose al tema, incluso ha escrito un libro:

Since that day in March (2014), I have studied this problem and what began as a set of practices for my family has evolved into a new book, How Not To Be Hacked. Below, I share the barriers that I discovered in educating regular people and how you can carry this forward within your own organization.

Las barreras serían:

• Los usuarios no quieren convertirse en expertos en seguridad.

No hay mucho que comentar sobre esto. Cada uno quiere hacer su tarea, acabarla pronto y bien.

• Demasiado preciso no es suficientemente preciso.

Si le preguntamos a algún técnico sobre algo la respuesta suele ser: ‘depende’ y esto es algo que al usuario no le sirve para nada al final. Tendríamos que cambiar este tipo de respuestas por las que sean suficientemente buenas (en lugar de perfectas).

• Falta de inteligencia emocional.

Tenemos que empatizar con los usuarios de tecnología, ayudarles, explicarles, y simplificarles los problemas.

Creo que compraré el libro.

En A Worldwide Survey of Encryption Products podemos leer un interesante informe en el que se puede leer la prometida lista de productos pero también una introducción donde se sugieren algunas ideas interesantes.

Se identifican 587 productores de este tipo de software:

The new survey also identified 587 entities that sell or give away encryption products, and of those, two-thirds are outside the US.

Se comenta sobre la eficacia de las instrucciones para añadir puertas traseras a los productos criptográficos que algunos gobiernos imponen:

Schneier argues in the paper that the survey findings call into question the efficacy of any US mandates forcing backdoors for law-enforcement access. He asserts that they show that anyone who wants to avoid US surveillance has hundreds of competing products to choose from. The report findings indicate that foreign products offer a wide variety of secure applications—voice encryption, text message encryption, file encryption, network-traffic encryption, anonymous currency—providing the same levels of security as US products do today.

Los mayores productores de criptografía serían, después de EEUU:

The most common non-US country for encryption products is Germany, with 112 products. This is followed by the United Kingdom, Canada, France, and Sweden, in that order.

Entre los datos se pueden encontrar siete productos identificados como españoles de, si no cuento mal, seis empresas diferentes:

• Boxcryptor
• Cellcrypt
• Cryptosec Mail
• Fleep
• OpenPGP Manager for Android
• QLink
• UppTalk

Mirando los enlaces veo que algunas de estas empresas tienen más productos y tampoco es fácil determinar el origen así que, como decíamos arriba, igual lo más interesante son las primeras páginas del informe y echarle un ojo a la lista para hacerse una idea.

Me dan un poco de miedo las analogías ‘médicas’ porque siempre hay quien termina tomándoselas al pie de la letra (recuerdo hace un montón de años escuchar una conversación en el tren de alguien que le contaba a otro como los virus informáticos se inoculaban con una jeringuilla).

En este caso la idea es muy sugerente: MIT tests ‘software transplants’ to fix buggy code, utilizar el código de programas que funcionan correctamente para ‘reparar’ programas con fallos:

La idea se basa en entradas de datos que hacen fallar el programa y otras que no lo hacen fallar.

To fix a buggy program, CodePhage requires two sample inputs, one that causes the program to crash, and another that does not.

Se utilizan para verificar en un ‘donante’ que se obtienen los resultados correctos y a partir de allí ya se sabe que se puede utilizar ese nuevo código para corregir el programa defectuoso:

It runs those inputs through a second program, known as the donor program, that has similar functionality. The Internet is awash with open source software that could provide parts for donor programs, though there’s no particular reason the donor code needs to be open source.

Si leemos algunos detalles más en System fixes bugs by importing functionality from other programs—without access to source code podemos ver que se trata de algo que deberíamos denominar, más bien, ‘microtransplantes’, porque se trataría de pequeños bloques de código.

En el artículo (seguramente no accesible para todos), Automatic error elimination by horizontal code transfer across multiple applications se puede ver, por ejemplo un fallo en el programa gif2tiff, corregido mediante la ‘donación’ desde ImageMagick:

#define MaximumLZWBits  12
if (data_size > MaximumLZWBits)
   ThrowBinaryException(CorruptImageError,
         "CorruptImage",image.filename);

Este código sería susceptible de un ataque de desbordamiento de memoria y el programa propondría corregirlo con:

if (!(datasize <= 12)) {exit(-1);}

Me encanta.

Traigo hoy un par de referencias sobre algo que muchas veces ya estamos haciendo los usuarios en la práctica (y que algunos proveedores han ‘estandarizado’ más o menos en lo que denominan sistemas de acceso sin clave): cuando no recordamos la contraseña utilizamos el botón de recordarla y accedemos al sitio. Posteriormente, si no es un sitio que visitamos con frecuencia la olvidamos y la próxima evez seguiremos el mismo procedimiento.

En este caso lo contaban en How to Fix Authentication: Email as a Password Manager. En este caso proponen que este sea el método de acceso y, por lo tanto, proponen que la contraseña remitida sea de un sólo uso. Las ventajas: no hacen falta aplicaciones extra, no hay problemas de sincronización (aunque a veces sabemos que los correos se ‘atascan’ o no podemos acceder a ellos de forma temporal), simple para los desarrolladores (al final los protocolos de recuperación de contraseña tienen su complejidad, recordemos Introducing the “Secure Account Management Fundamentals” course on Pluralsight), el registro y la entrada son iguales (con matices, supongo, por la cuestión de si estás ya registrado con una cuenta de correo diferente), sólo es necesario un click, podemos controlar la duración de la validez del enlace, y no necesitamos almacenar constraseñas (y, por lo tanto, no nos las pueden robar). No termino de estar de acuerdo con la ‘ventaja’ de evitar el Facebook Connect (y similares) salvo por evitar su complejidad. Y tampoco con que no se puede aplicar fuerza bruta: obviamente se puede, aunque nosotros ahora tenemos más control sobre la dificultad de encontrar los enlaces, frente a las contraseñas que los usuarios suelen elegir de manera inadecuada.

Como inconveniente, está claro que trasladamos toda la seguridad de nuestro sistema al proveedor de correo y a la gestión que el usuario haga de él. Hay más, claro, nunca nada es tan fácil como creemos al principio.

No habría que olvidar la vigilancia de las cuentas gestionadas de esta manera (observación de anomalías, cambios, novedades,…) que también parece ser una de las tendencias en seguridad de cuentas hoy en día.

En History of Email-Only Auth hay más información y opiniones de diversas personas sobre ideas similares.

Hoy traemos un vídeo reciente sobre la escasez de talento en temas de seguridad en la industria (en EEUU, por nuestros lares ahora parece que nos acabamos de dar cuenta de que los informáticos son importantes, lo de seguridad llegará dentro de una temporada).

En el vídeo se habla de muchos temas, algunos de los cuales hemos tratado por aquí y en clase (ejemplos inseguros y otros asuntos).

Aunque no pude dedicarle toda la atención que debería me pareció interesante porque incide bastante en el tema de la formación, la seguridad en el desarrollo (y no sólo la del sistema y esas cosas en las que pensamos normalmente cuando se habla de seguridad informática).