En una bitácora como esta, que no sólo no es de actualidad sino que suele traer temas con bastantes meses, no se si tiene mucho sentido traer estas cosas pero me gusta guardarlas para tenerlas en algún sitio recopiladas.
Por eso traigo Announcing the first SHA1 collision que habla de una colisión en un sistema de firma (hash). La idea de estos sistemas es sencilla: no debería ocurrir que dos ‘mensajes’ diferentes produzcan el mismo resumen. En este caso anunciaban una forma de generar una colisión para el algoritmo SHA1. Para el común de los mortales esto significa, esencialmente, que ya podemos ir pensando en dejar de usarlo (si es que lo hacíamos).
También es un recordatorio de que los ‘estándares’ que alguien nos recomendó en algún momento van quedando obsoletos y que no podemos dejarnos llevar por la costumbre y la comodidad.
A collision occurs when two distinct pieces of data—a document, a binary, or a website’s certificate—hash to the same digest as shown above. In practice, collisions should never occur for secure hash functions. However if the hash algorithm has some flaws, as SHA-1 does, a well-funded attacker can craft a collision.
En esa entrada nos recomendaban utilizar SHA-256 y SHA-3.
Ya hemos hablado en alguna ocasión de las pruebas que voy haciendo con un bot conversacional (aviso: nada de inteligencia artificial ni procesado del lenguaje: sólo un conjunto de instrucciones predefinidas por mi mismo).
Se puede ver un ejemplo en Segundo bot: avanzamos.
Creo más en el concepto de Un chatbot como asistente personal que en otras ideas que podemos ver por ahí.
Para estos desarrollos me gusta mucho el proyecto Errbot que nos proporciona una infraestructura para desarrollar bots conversacionales porque se desarrolla en Python, tiene un mecanismo de plugins para añadir instrucciones, una comunidad bastante amistosa y además mecanismos para interactuar a través de diversos canales.
Pero (siempre hay un pero) los desarrolladores no han contemplado la posibilidad de que un bot pueda escuchar en distintos canales a la vez. Yo empecé con un bot que escuchaba XMPP, pero los clientes no son muy cómodos y terminé pasándolo a Telegram: hay clientes para el teléfono móvil, para el escritorio, …
A veces preferiría enviar instrucciones al bot a través de un sistema basado en texto (tal vez la línea de instrucciones) y decidí probar con el IRC.
Una posible solución sería tener dos bots replicados e indpendientes y que cada uno responda según se le vaya pidiendo. Sin embargo, dándole vueltas pensé en la posibilidad de establecer un mecanismo de coordinación: añadimos una función forward (fw para escribir menos) y si estoy en el canal del bot que no sabe ejecutar mi instrucción, le pido que la redirija a otro que pueda ser capaz.
Por ejemplo, para saber el estado del otro bot, que es una instrucción estándar de Errbot (de momento estoy trabajando con dos, uno reconoce instrucciones que empiezan con ‘!’, y el otro con ‘,’) escribiríamos:
!fw ,status
Una vez planteada la funcionalidad, la decisión era como establecer la comunicación entre los bots. Una posibilidad sería comunicarlos directamente intercambiando mensajes entre ellos, pero entonces puede ocurrir que uno esté desconectado o inactivo y eso sería un problema.
¿Por qué no utilizar un mecanismo similar a los de mando y control (command and control) a través de un canal acordado donde los bots pueden escribir y leer?
Podemos definir una sintaxis (un lenguaje de comunicación) y hacemos que la instrucción fw escriba en el canal. Establecemos también un mecanismo de lectura del canal y cuando el bot encuentre un mensaje para él lo interpreta, lo ejecuta, y publica en el canal el resultado. Si el bot encuentra un mensaje de respuesta para él, envía dicha repuesta por su mecanismo de comunicación al usuario que pidió su ejecución.
Como prueba de concepto podemos echar un vistazo a err-forward (enlace a la versión actual porque es un proyecto vivo y podría evolucionar en el futuro) y también ver un vídeo de dos bots transmitiéndose instrucciones.
Para su desarrollo se han utilizado:
el mecanismo de creación de plugins de Errbot
el mecanismo de programación de actividades (Scheduling).
un canal común donde escribir y leer las instrucciones.
Todos conocemos sistemas de mando y control basados en IRC, correo electrónico, Twitter, …
En nuestro caso había que elegir uno para nuestros bots. No soy un gran fan de Slack pero quería darle una oportunidad de uso y pensé que una buena forma sería creando allí el canal de intercambio de mensajes.
Slack tiene un API y módulos en Python para interactuar con los canales (slackclient), así que parecía una buena opción para intentarlo.
De momento hemos definido tres tipos de mensajes:
Msg para mensajes textuales (saludos y despedidas de los bots y otros).
Cmd para instrucciones
Rep para respuestas
La creación de un bot en estas circunstancias se basa, entonces, en las siguientes funciones:
Inicialización: el bot empieza a funcionar, se conecta al canal y escribe un mensaje de ‘saludo’.
Escritura: el bot puede escribir un mensaje de cualquiera de los tres tipos anteriores en el canal.
Lectura: el bot lee el canal y es capaz de identificar los mensajes que puede interpretar, realizando las acciones oportunas y escribiendo en el mismo canal las respuestas, si procede.
No entraremos en detalles aquí pero para que un bot pueda leer y escribir en un canal de Slack es necesario tener un token que permita inteactuar con, por ejemplo, la Slack Web API.
Siguiendo desarrollos anteriores, almacenamos el token en un fichero denominado ~/.rssSlack con el formato:
[Slack]
api-key:......
La leemos utilizando el módulo configparser, creamos el cliente y publicamos el primer mensaje. El canal donde se comunicarán los bots es un parámetro de configuración del módulo, al que se accede a través de
self._check_config('channel')
Además el bot almacena el usuario del sistema oporativo y el nombre de la máquina, que se usará para enviar las respuestas cuando proceda.
El mensaje de saludo incluye la dirección IP:
self['sc']=SlackClient(slack_token)self['chan']=str(self._check_config('channel'))self['userName']=pwd.getpwuid(os.getuid())[0]self['userHost']=os.uname()[1]self.publishSlack(typ='Msg',args='Hello! from %s'%self.getMyIP())
Aquí se ha utilizado el método publishSlack que sirve para escribir en el canal (lo comentaremos luego).
Después se inicializa el poller que lee periódicamente el canal para ver si hay algo que el bot pueda hacer:
self.start_poller(60,self.readSlack)
Aquí se utiliza el método readSlack que sirve para leer en el canal (lo comentaremos luego) y, en esta configuración se ejecuta una lectura cada 60 segundos.
El método de publicación (publishSlack) es muy sencillo, simplemente prepara el mensaje y lo escribe en el canal. De momento, un mensaje tiene el formato:
Incluye el nombre de usuario y de la máquina del usuario, un campo frm que viene de la comunicación del bot, un tipo (typ) tal y como se explicó arriba, y los campos cmd y args que también provienen de la forma de funcionar de Errbot (instrucción y argumentos).
El mensaje se codifica para que no se interprete como html, se transforma en json para que sea más fácil leerlo luego y se publica en el canal:
El método de lectura (readSlack) es algo más complicado: tiene que leer en el canal la lista de mensajes, decidir si alguno de ellos es para el bot en cuestión, interpretarlo, …
Luego hay que recorrer la lista de mensajes y actuar según proceda:
formsginhistory['messages']:msgJ=self.extractArgs(msg)if('typ'inmsgJ):ifmsgJ['typ']=='Cmd':# It's a command
self.manageCommand(chan,msgJ,msg)elifmsgJ['typ']=='Rep':# It's a reply
self.manageReply(chan,msgJ,msg)
Como puede verse, se utilizan algunas funciones auxiliares.
El método extractArgs extrae los campos del json que lee del canal y, si no es un mensaje (los mensajes simplemente se ignoran), hace la conversión de los argumentos (están codificados para que no se interpreten como html porque algunas instrucciones utilizan este lenguaje):
ifmsgJ['args']and(msgJ['typ']!='Msg'):# Unquoting the args
self.log.debug("Reply args before: %s "%msgJ['args'])tmpJ=urllib.parse.unquote(msgJ['args'])msgJ['args']=tmpJ
El método manageCommand determina si el mensaje es para el bot y, en su caso, trata de realizar lo que corresponda:
Esto es, obtiene una lista de instrucciones, comprueba que la instrucción comienza con el caracter adecuado, y luego verifica si es una instrucción conocida para el bot. Posteriormente, la ejecuta.
Para ello, identifica el método asociado:
method=listCommands[cmd]
Y la ejecuta:
replies=method("",msgJ['args'])
Con un tratamiento ligeramente diferente si se trata de un generador (puede haber varias respuestas) o no.
En ambos casos guarda como texto la respuesta para devolverla convenientemente.
Después de interpretar la instrucción, ejecutarla y escribir la respuesta, el bot borra el mensaje del canal (la referencia a mensajes concretos se realiza basada en un identificador basado en el momento de publicación del mensaje):
self.deleteSlack(chan,msg['ts'])
Finalmente, el mensaje podría ser una respuesta. Para ello se utiliza el méotodo manageReply.
Este método tiene que identificar si la respuesta es para el bot:
if((msgJ['userName']==self['userName'])and(msgJ['userHost']==self['userHost'])):# It's for me
self.log.info("Yes. It's for me")replies=msgJ['args']
Y enviarla al usuario que lanzó la instrucción:
self.send(msgTo,replies)
Para después borrarla:
self.deleteSlack(chan,msg['ts'])
Todavía no hemos hablado del método para redirigir mensajes, que se llama forwardCmd y que funciona como sigue:
Si la instrucción tiene parámetros, los separa con
Hemos utilizado Slack pero podría utilizarse cualquier canal, con las adaptaciones oportunas. Probablemente haya mecanismos mejores.
Sería interesante disponer de diferentes canales de comunicación, mejorando el plugin para que se pudiera elegir uno, por ejemplo, en la configuración. No se si sería ‘abusar’ montar otra infraestructura de plugins para esto. En todo caso, me encantaría ver si alguien sigue estas ideas y hace otros ‘redirectores’.
La redirección se hace escribiendo la instrucción para el bot completa, utilizando el caracter especial de inicio de instrucción (‘!’, ‘,’ en nuestro caso). Esto podría evitarse, y que el bot simplemente intentase interpretar cualquier instrucción.
Si hay varios bots que son capaces de ejecutar la misma instrucción podemos terminar ejecutándola más de una vez, no se ha previsto un bloqueo para evitarlo. Esto podría causar problemas al intentar borrar el mensaje por segunda vez.
Se ha conseguido el objetivo de tener varios bots (dos) que son capaces de ejecutar distintas instrucciones y comunicarse entre ellos.
Hemos aprendido algunas de las interioridades de Errbot que permiten interpretar las instrucciones y ejecutarlas, aplicar plantillas, etc.
Llevo probando este mecanismo durante unas semanas con un par de bots (como decía arriba, uno está escuchando en Telegram y el otro en un canal de IRC) y funciona de manera bastante robusta para las instrucciones que yo suelo utilizar: se pueden ver en mi GitHub (GitHub de fernand0), todos mis módulos empiezan con err-.
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.
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.
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.
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.
En una bitácora como esta, que no sólo no es de actualidad sino que suele traer temas con bastantes meses, no se si tiene mucho sentido traer estas cosas pero me gusta guardarlas para tenerlas en algún sitio recopiladas.
