El mundo de las contraseñas es muy interesante. Pero suponiendo que todo va bien (o no), pero que ya tenemos montada una infraestructura alrededor de ellas la gente tenemos la manía de olvidarlas.

En Untangling the Forget-Me Knot: Secure Account Recovery Made Simple un recordatorio de las cuestiones básicas alrededor del tema de recuperación de las contraseñas.

Empieza con un recordatorio: cuando permites cambiar la contraseña, empiezan los problemas:

This bears emphasis: When you give your users the capability to reset their password, you are creating a backdoor into their account.

Naturalmente, en cualquier instalación de tamaño mediano será difícil manejar el problema ‘a mano’ así que habrá que tener algún mecanismo de recuperación (que típicamente será un sistema para poner una nueva), porque no deberíamos enviar a los usuarios la que tenían (no deberíamos ser capaces):

If you’re taking security seriously and properly utilizing a password hashing function, you shouldn’t even be able to do this.

Tampoco es buena idea enviarles una nueva: se transmitirá por canales inseguros, puede que no llegue, puede que no lo hagas bien, hay que esperar a que llegue (experiencia desagradable de la que, de cualquier modo, puede que no nos libremos) y, si no lo cambian, probablemente permanezca en el canal de comunicación para siempre.

Tampoco aconseja utilizar preguntas de seguridad, se trata de una clave secundaria que normalmente es fácil de adivinar.

The answers to most security questions are like a second password, except they’re often disclosed publicly on social media

Entonces, ¿qué hacer?

Primero, hacerlo opcional: si el usuario es suficientemente competente, gestionará bien sus contraseñas y no necesitará cambiarlas por estos mecanismos:

So, first and foremost, empower your users to choose convenience or security. Ask them, “Do you want to be able to regain access to your account if you ever forget your password?” If your application is designed for high risk users, consider defaulting to “No”.

Lo que no significa que no pueda cambiarse, sólo que hará falta que lo haga alguien por nosotros.

Segundo, utilizar un mecanismo de recuperación basado en un token dividido (una parte sirve para identificar, la otra para validar. La que identifica se almacena en la base de datos sin más, la de validar se almacena transformada como un hash: al usuario se le envían ambas; si alguien consiguiera entrar en la aplicación el ‘token’ no le serviría para nada. Igual es exagerado porque si consiguen robar la base de datos de identificación seguro que tenemos más problemas; pero no es mucho trabajo y añade seguridad.

El artículo también sugiere cifrar los mensajes, que puede ser algo aplicable en contextos muy concretos (no creo que para usuarios en general).

Finalmente, los ‘tokens’ deberían caducar, para que no sirvan para siempre almacenados (igual que si fueran contraseñas) en el sistema de mensajería.

Interesante.

Cuando uno conoce los sistemas de control de versiones empieza a pensar en casos de uso y la tentación es utilizarlos para todo (¿por ejemplo tener un blog? Ja). No digo que sea el caso, pero me pareció interesante el anuncio Announcing GVFS (Git Virtual File System) que nació del paso de Microsoft a utilizar Git como sistema de control de versiones y las dificultades que suponía eso cuando el tamaño del código que manejan es suficientemente grande:

For example, the Windows codebase has over 3.5 million files and is over 270 GB in size. The Git client was never designed to work with repos with that many files or that much content. You can see that in action when you run “git checkout” and it takes up to 3 hours, or even a simple “git status” takes almost 10 minutes to run. That’s assuming you can get past the “git clone”, which takes 12+ hours.

El código de Windows tiene 3.5 millones de ficheros y ocupa más de 270 GB. Tenemos la tendencia a imaginar que hoy en día la informática puede gestionar casi cualquier cosa, pero la realidad es dura. Buscando la escalabilidad se inventaron el sistema de ficheros virtual basdado en Git (GVFS ,Git Virtual File System) que trata de ofrecer una vista transparente de toda esa información sin necesidad de tenerla descargada. De paso nos enteramos de algunas cifras que no siempre están claras para el sistema operativo de Microsoft.

Lo dejaron libre en GVFS y hay más comentarios interesantes en Scaling Git (and some back story).

Las noticias más recientes hablan incluso de Microsoft and GitHub team up to take Git virtual file system to macOS, Linux que sería una buena noticia para todos. Aunque no parece haber muchas noticias nuevas sobre el tema.

La autentificación de dos factores (2FA) consiste en hacer que la autentificación se base en dos factores diferentes y no conformarse con uno. Cuando se usa un sólo factor todos sabemos que el más habitual es la contraseña y también vamos viendo como los grandes ‘jugadores’ de internet están intentando que utilicemos un segundo (típicamente una aplicación, o un mensaje, o algo así que se emite en el momento en que intentamos autentificarnos) se trata de garantizar que nos sabemos la contraseña y, además, tenemos acceso al canal por el que se nos envía el segundo factor (por ejemplo el teléfono, la cuenta de correo, etc.). Puede haber otros mecanismos y aquí estaríamos hablando de lo que vemos últimamente en la red. https://www.esecurityplanet.com/network-security/74-percent-of-organizations-using-two-factor-authentication-face-user-complaints.html Nunca he sido un gran fan del doble factor porque añade un punto extra de fallo: el mensaje no llega, o no tenemos acceso cómodo al correo, o …. Pero lo cierto es que para los usuarios es una protección interesante. Ya no importa que la contraseña sea débil porque lo que hay que conseguir por parte del atacante aumenta, y hace las cosas más difíciles.

En 74 Percent of Organizations Using Two-Factor Authentication Face User Complaints hablan del tema y de las encuestas realizadas y el titular es un buen resumen: un 74% de las organizaciones que utilizan este sistema, tienen quejas de los usuarios. Tiene lógica: si con los grandes de internet, a veces, hay problemas, podemos imaginar lo que sucede en el sistema casero donde los medios son menores.

… found that 74 percent of respondents who use two-factor authentication (2FA) said they receive complaints about 2FA from their users – and 9 percent say they simply “hate it.”

Y es un dilema para los profesionales, que deben elegir constantemente entre la experiencia de usuario y la protección de la seguridad:

“IT professionals face an ongoing battle as they are frequently forced to choose between user experience and increased security.”

Por supuesto, los usuarios casi siempre estarán dispuestos a saltarse las medidas de seguridad para trabajar más cómodos:

Separately, a recent University of Phoenix survey of 2,235 U.S. adults found that 52 percent of respondents are willing to overlook cyber security risks for the sake of convenience.

Yo sigo pensando que necesitamos más expertos en experiencia de usuario que dediquen atención a la seguridad. Y gente de seguridad (pero también de informática, claro) que preste atención a los usuarios.

El correo no deseado es una plaga. Pero a este se añade el correo que trata de hacerse pasar por alguien. No es una amenaza demasiado abundante (al menos para gente normal) pero el segundo afecta mucho al segundo: si no hay una cierta autentificación, cualquiera termina pasando nuestros filtros anti-spam y haciéndonos perder el tiempo.

En Most email authentication implementations fail hablaban de diversos estudios sobre DMARC,

DMARC, which stands for “Domain-based Message Authentication, Reporting & Conformance”, is an email authentication, policy, and reporting protocol.

El resultado es (como suele pasar) bastante lamentable: aproximadamente tres cuartas partes de las empresas grandes que intentan utilizar el estándar no son capaces de utilizarlo con éxito para bloquear mensajes no autorizados.

“Our investigation showed that using email authentication to monitor and control unauthorized email is extremely difficult for the majority of global companies,” said ValiMail CEO Alexander García-Tobar. “You might expect larger businesses with more resources to do a better job of governing the email going out under their names, but we found that most of them still miss the mark.”

Y así seguimos.

Vivimos tiempos interesantes para cualquier persona interesada en la informática (siempre que esté dispuesta a mantenerse al día, nada es gratis). Si hablamos de ciberseguridad, creo que en nuestro contexto todavía está por despegar, pero hay presente y futuro, desde luego.

En So, you want to work in security? algunos consejos sobre el tema.

Primero, no hay un camino único:

I’ve learned that there is no single, standard, or best preparatory path. Maybe this will change as the field matures, but I doubt it.

Segundo, algo de lo que carecían muchos de los expertos en seguridad hasta hace no mucho: hay que programar.

Write code. The best security engineers I know are also actively writing code. This gives them firsthand experience with writing software, including unintentionally-yet-inevitably introducing security bugs.

Naturalmente, rompe cosas:

Break code. Spend time finding software bugs. Learn how to use a debugger, network scanner, web debugging proxy, and software fuzzer. Spend time in hacker playgrounds, which are available for all skill levels.

También habla de compartir conocimiento y otro consejo no técnico (y que muchos técnicos olvidan): aprender y practicar nuestras habilidades comunicativas.

Además, recordar que hay que trabajar y equivocarse a veces, tratar de ser optimista, pedir ayuda, …

Interesante.