Seguridad en el inicio de sesión

Tagged:

Toda comunicación tiene tres fases: inicio de sesión, intercambio de mensajes y finalización de sesión. Veamos algunas razones por las que ha de cuidarse la seguridad en el inicio de sesión:

  • Autenticación del usuario segura: cuando un usuario inicia sesión en un servidor, envía, entre otras cosas, su contraseña. Si la contraseña fuera interceptada por un intermediario, podría usarla posteriormente para acceder a la cuenta del usuario (sin su permiso, claro, y sin que se entere).
  • Autenticación del servidor: Un usuario puede intentar iniciar sesión en un servidor. Un intermediario podria hacerse pasar por el servidor, sin que el usuario se entere. El usuario proveería datos valiosos (entre otros la contraseña) al intermediario malicioso sin darse cuenta en un primer momento. Si el intermediario adicionalmente se conecta al servidor real haciéndose pasar por el usuario legítimo de la cuenta, podria capturar toda la comunicación sin que nadie se diera cuenta.

Veamos como es el inicio de sesión en Jabber.

  1. El cliente lo primero que hace es preguntar los sistemas de autenticación soportados por el servidor. También proporciona el nombre de usuario.
    <iq id='15'
    	type='get'>
      <query xmlns='jabber:iq:auth'>
        <username>badlop</username>
      </query>
    </iq>
  2. El servidor responde entre otras cosas que acepta el envio de la contraseña en texto plano y también resumen de contraseña (hash).
    <iq type='result'
    	id='15'>
      <query xmlns='jabber:iq:auth'>
        <username>badlop</username>
        <password/>
        <digest/>
        <resource/>
      </query>
    </iq>
    
  3. El cliente ahora debe proporcionar la contraseña. Tiene dos posibilidades.
    • Si se decide enviar la contraseña en texto plano, entonces se envía tal cual. Cualquier intermediario puede leerla sin problema (quien este conectado en la red local del cliente o del servidor, el ISP...):
      <iq id='16'
      	type='set'>
        <query xmlns='jabber:iq:auth'>
          <username>badlop</username>
          <password>trAlaRi9923</password>
          <resource>casa/cocina</resource>
        </query>
      </iq>
      
    • Si se decide enviar el resumen de la contraseña, entonces no se envía la contraseña tal cual, sino el resultado de aplicarle algunas funciones matemáticas. No obstante, un intermediario podría copiar ese resumen y usarlo posteriormente para iniciar sesión haciéndose pasar por el usuario legítimo.
      <iq id='1'
      	type='set'>
        <query xmlns='jabber:iq:auth'>
          <username>badlop</username>
          <digest>8712162796c9aa001afffc150a91584bc45f9527</digest>
          <resource>casa/cocina</resource>
        </query>
      </iq>
      
  4. El servidor comprueba si la autenticación ha sido correcta y responde al cliente
    • Que todo va bien:
      <iq type='result'
      	id='1'/>
      

      El cliente a partir de ese momento ya puede continuar con la inicialización de la sesión (solicitar la lista de contactos, etc).

    • O que ha habido un error (la contraseña no es válida, el método de autenticación no está soportado, la cuenta no existe...) y el usuario no está autorizado:
      <iq id='1'
      	type='error'>
        <query xmlns='jabber:iq:auth'>
          <username>badlop</username>
          <password>trAlaRi9923pepepe</password>
          <resource>casa/cocina</resource>
        </query>
        <error code='401'>Unauthorized</error>
      </iq>
      

Como hemos visto, los sistemas de autentificación de Jabber no es que sean muy robustos. La solución inmediata es cifrar la comunicación SSL entre el cliente y el servidor, de forma que todo el intercambio de mensajes se cifre.

En XMPP el cliente debe autenticar la comunicación antes de poder autenticarse en el servidor (enviar nombre de usuario y contraseña). La autenticación de la comunicación utiliza el protocolo SASL. De esta forma se consigue una seguridad acorde con los nuevos tiempos cuando la contraseña se transmita por la red.

Para autenticar al servidor Jabber se puede iniciar una sesión con SSL. El servidor proporcionará su certificado SSL. Si parece correcto, entonces podemos asegurar que el servidor es quien dice ser.

Comentarios

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.

Autenticación con digest

Si se decide enviar el resumen de la contraseña, entonces no se envía la contraseña tal cual, sino el resultado de aplicarle algunas funciones matemáticas. No obstante, un intermediario podría copiar ese resumen y usarlo posteriormente para iniciar sesión haciéndose pasar por el usuario legítimo.

Si no me equivoco, para generar el resumen no sólo se usa la password sino también el ID de sesión como sal, el resultado es que un resumen solo sirve para una sesión y por lo tanto aunque se obtenga no sirve para iniciar nuevas sesiones (a menos que el ID de sesión fuera el mismo, que es muy improbable ya que es aleatorio).

Sí además de esto nos conectamos mediante SSL o TLS, mejor.