Sistemas de recuperación de contraseñas

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

Sistemas masivos de ficheros y control de versiones

GitHub logo 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 y los usuarios

¿Quién eres? Enséñanos la patita 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.

Un estudio sobre correo autentificado en EEUU

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

Consejos para desarrollar una carrera en ciberseguridad

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

Una introducción a las baterías

Pila y más En Powering micro-controllers by Battery un buen resumen de los tipos de pilas y baterías y cuál puede ser el uso más conveniente para cada tipo y las recomendaciones.

La ‘respuesta corta’ se fija primero en los tipos de batería existentes: tamaño frente a capacidad y precio. Aunque también habría que considerar en qué tecnología se basan (fundamentalmente la química, que afecta al voltaje, pero también a la curva de descarga):

There are many differences between each kind of battery available on the marked, but the features we normally use to take a decision is: size versus capacity versus price. Logically if we simply didn’t care about size or price, bigger batteries like a standard Akaline D would offer some great capacity and stability, also the new 1.5V Lithium cells are great but very expensive!

Well, as we normally care about price and size, we also need to start considering other factors like the battery’s chemistry, which will affect the not only the cell voltage but the discharging curve as well – those will be covered in more details at the “Long Answer”.

Para tener a mano, en caso de duda.

Algunas ideas para trabajar en ciberseguridad

Protección En So you want to work in security (but are too lazy to read Parisa’s excellent essay) algunas ideas interesantes si pensamos que trabajar en ciberseguridad podría ser una opción para nosotros.

  1. Ciberseguridad tiene que ver con la discordancia entre el comportamiento real del sistema y lo que esperaban que fuera el comportamiento sus diseñadores.
  2. Se trata de una protociencia. Mucha información, que todavía no tenemos bien organizada y en la que algo puede fallar donde menos se espera.
  3. La gente podrá confiar en nosotros, pero no hay forma de medir la efectividad de lo que hagamos.
  4. Puede que creas que eres más listo que los desarrolladores de software, pero no es así.

Principios de seguridad de Saltzer y Schroeder

Grabado en piedra Es bien conocida la frase de Groucho Marx: ‘Estos son mis principios. Si no le gustan… tengo otros’. Sin embargo, los principios tiene su interés y utilidad como conceptos o valores que nos guían en el comportamiento: cuando nos enfrentamos a una nueva situación o nos movemos en terreno incierto, los principios nos pueden ayudar a tomar decisiones.

En ese sentido traemos hoy aquí The Security Principles of Saltzer and Schroeder que presentaron sus principios sobre protección de la información en sistemas informáticos. Serían:

  • Economía en el mecanismo (tan simple y pequeño como sea posible).
  • Fallo en modo seguro por defecto (si algo va mal, el sistema queda en un estado seguro).
  • Mediación completa (para cada acceso a un objeto del sistema se debe comprobar la autorización).
  • Mínimo privilegio (Cada agente debe tener los permisos necesarios para realizar su tarea, pero no más).
  • Mínimo mecanismo común (no compartir estado entre diferentes agentes. Si alguien puede corromperlo, podrá influir en el comportamiento de los que dependan de él).
  • Separación de privilegios (separar las acciones de manera que cada una tenga permiso para realizar la parte que sea necesaria para su actividad; evitar hacer una única pieza que tiene permiso para realizar las distintas tareas).
  • Diseño abierto (el diseño no debería ser secreto o, al menos, su seguridad no debería depender de la ignorancia de los atacantes sobre sus internalidades).
  • Psicológicamente aceptable (si las reglas no son razonables, será difícil que sean aceptadas y seguidas con cierto rigor).

El autor juega con los principios y la saga de ‘Star Wars’ así que puede valer la pena echarle un vistazo, más allá de los principios.

Fuzzing para detección de fallos en Google

Líado Creo que hace un montón de tiempo que no hablábamos de Fuzzing: esencialmente (aunque últimamente se ha ido sofisticando) enviar basura diversa a las interfaces de entrada de los programas para detectar problemas de seguridad.

En Announcing OSS-Fuzz: Continuous Fuzzing for Open Source Software una iniciativa de Google para poner el sistema de fuzzing como servicio a disposición de desarrolladores de software libre. Ya ha servido para encontrar fallos en algunos proyectos:

OSS-Fuzz has already found 150 bugs in several widely used open source projects (and churns ~4 trillion test cases a week). With your help, we can make fuzzing a standard part of open source development, and work with the broader community of developers and security testers to ensure that bugs in critical open source applications, libraries, and APIs are discovered and fixed.

El proyecto está disponible en oss-fuzz con algo más de información.

Recordemos que Microsoft fue uno de los primeros promotores del fuzzing dentro de su ciclo de vida del desarrollo seguro (por cierto, más recientemente también ha puesto a disposición del público Microsoft opens fuzz testing service to the wider public y también que Coverity Scan es otro proyecto que ofrece sus servicios a los desarrolladores de software libre, desde otra perspectiva.

Consejos sobre seguridad para trabajadores en movilidad

Telefonía móvil Cuando todavía no tenemos clara la seguridad en los dispositivos fijos, nos está pasando por encima todos los aparatos móviles que lleva la gente, que se conectan a nuestras redes, a nuestros servidores y donde haga falta. En 10 ways to secure a mobile workforce, utilizando una de las formas más horribles de presentar la información en internet (pase de diapositivas), algunos consejos.

Yo me quedo con un par de ideas, la primera, que no podemos ser excesivamente rígidos o exigentes. Eso se volverá contra nuestras políticas de seguridad de manera inevitable. Las restricciones y las políticas deberían ser realistas:

If you implement policies that are too rigid or out of place with the current maturity of your company’s security program, chances are that your employees are going to subvert or ignore them altogether. If your employees find that the policies are strict, but workable, they will be more open to approaching you with issues or concerns on how they can meet policy and still get their work done.

La segunda, una con la que no solo estoy de acuerdo, sino que creo que todos tratamos de aplicar: cuando haya incidentes, aprovecharlos para recordar las partes relevantes de nuestras políticas de seguridad:

For example, when a well publicized security issue, like the resurfacing of the 2012 LinkedIn hack, it is a perfect opportunity to provide a refresher to personnel on the risk of password reuse and the benefits of strong passwords.

No debemos olvidar a la gente aunque estemos siempre tratando de mejorar la seguridad de nuestras organizaciones.