Sobre la autentificación de dos factores

Enséñame la patita. Vale, no tenía otra foto con patitas. Llevamos una temporada en la que uno de los mantras de los de seguridad en temas de autentificación es: ‘utiliza autentificación de dos factores’. Ya saben: normalmente una contraseña que nos sabemos y algo más (típicamente un mensaje que recibimos de alguna forma o algún dato generado de alguna forma). Aunque los beneficios están claros, me resisto a recomendarla abiertamente porque cuando funciona lo hace muy bien, pero cuando falla estamos fuera (ese SMS/correo que no llega, justo cuando más lo estamos necesitando o ese canal alternativo que en ese momento no está disponible). Sin ponernos en el caso de que alguien sea capaz de interceptar los mensajes de ese canal secundario, como nos recordaban recientemente en SMShing para robar tu 2nd Factor Authentication en tus cuentas Google o Apple #SMShing #Google #Apple. Y sin olvidar que ese canal alternativo (típicamente el teléfono móvil) se ha convertido en canal unitario.

A lo que vamos, en Why You Don’t Need 2 Factor Authentication nos lanzaban una serie de argumentos contra el sistema, que me gusta traer aquí:

  • Mito 1: lo que sabes, lo que tienes, bla, bla, bla

El autor dice que no todo es tan sencillo y que hay más categorías y más que centrarnos en esa clasificación deberíamos preocuparnos de los factorse utilizados y sus características.

  • Mito 2: la autentificación de dos factores hace mi cuenta más segura, sin consecuencias negativas

En realidad, perdemos tiempo en esa parte del proceso, la aplicación es más compleja, y no evita otros inconvenientes.

Al final, la autentificación de dos factores es un gestor de contraseñas para ‘perezosos’ (porque lo gestiona el proveedor del servicio). Me parece un punto de vista interesante, aunque conociendo la tendencia a la pereza de los usuarios igual es la única solución viable.

Manifiesto ágil para el desarrollo seguro

Agile Security Manifesto No es la primera vez que hablamos de desarrolo ágil y seguridad (Seguridad en proyectos ágiles y DevOps y seguridad. En esta ocasión nos referiremos a The Agile Security Manifesto de la empresa Cigital, que propone los siguientes principios:

  • Confiar en los desarrolladores y probadores más que en los especialistas en seguridad
  • Asegurar mientras desarrollamos mejor que cuando el trabajo está hecho
  • Implementar las características de manera segura mejor que añadir características de seguridad.
  • Mitigar los riesgos mejor que arreglar los fallos.

Interesante.

Desarrollar software cuando el software no es tu objetivo

ADN En The myths of bioinformatics software algunos comentarios sobre los programas que se utilizan en bioinformática pero que creo que se puede extender a casi cualquier rama del conocimiento: poco pensado para ser publicado y reutilizado, desarrollado muchas veces por personas sueltas o equipos muy pequeños y un poco a salto de mata, que luego es difícil de leer/modificar/mantener por otros.

También comenta con que las licencias permisivas no son una ayuda cuando se desarrolla con esa precariedad (y esos objetivos). También habla de la posibilidad de vender los programas y hasta qué punto podemos estar subvencionando a empresas privadas si les cedemos de manera gratuita los programas para uso comercial y algunas cosas más.

No estoy seguro de estar de acuerdo con todo, pero es interesante leer el punto de vista de alguien que desarolla software pero no es su misión principal.

Seguridad para usuarios no interesados en seguridad

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

Un informe sobre productos criptográficos

Escondido 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:

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.