Inicio / Blog / Autenticación basada en contraseñas

Autenticación basada en contraseñas

Publicado el 22/01/2015, por Jesús Díaz (INCIBE)
Autenticación basada en contraseñas

El uso de contraseñas sigue siendo el mecanismo más extendido para autenticación en la red. Esto es comprensible, ya que el único requisito es que cada cual recuerde su nombre de usuario y contraseña, frente a la inconveniencia de tener que llevar consigo un certificado digital, token USB, tarjeta inteligente, disponer de hardware o software especializado, etc.

No obstante, los interminables casos de robos o compromisos de contraseñas son, por lo menos, indicativos de que hay que tener mucho cuidado a la hora de implementar un mecanismo u otro. Especialmente, teniendo en cuenta que no se puede esperar que los usuarios sigan políticas adecuadas para la gestión de sus contraseñas. En nuestra Bitácora de Ciberseguridad se pueden consultar casos recientes de especial relevancia, como la publicación de usuarios y contraseñas de Dropbox en octubre de 2014, el robo de 1200 millones de credenciales por parte de hackers rusos en agosto de 2014, o el incidente de Cerberus en marzo de 2014.

Dentro de la propia autenticación basada en contraseñas hay varias posibilidades, cada una con distintas implicaciones en la seguridad del servicio y en la privacidad proporcionada a sus usuarios. En la entrada en inglés de la Wikipedia se hace una buena categorización inicial al respecto. En concreto, las alternativas se dividen en:

  • Transmisión simple de la contraseña: La contraseña se manda sin procesar y en un canal sin cifrado.
  • Transmisión a través de canales cifrados: La contraseña se transmite por un canal cifrado, como TLS.
  • Métodos desafío-respuesta basados en hashes: Donde el desafío presentado por el servidor no es simplemente pedir la contraseña, sino un valor dependiente de ella (por ejemplo, a través de una función hash).
  • Métodos de conocimiento cero: Aquellos en los que el valor enviado al servidor para autenticarse no revela ninguna información sobre la contraseña.

En cualquier caso, estas opciones no son mutuamente exclusivas. Por ejemplo, un método de desafío-respuesta basado en hashes se podría transmitir por un canal cifrado o sin cifrar.

En este post se describen algunos de los mecanismos más relevantes, bien por ser los más utilizados o bien por proporcionar propiedades interesantes (y que también cuentan con soporte software y/o de estándares internacionales). Entre las propiedades a tener en cuenta desde el punto de vista del usuario final, se tendrán en cuenta:

  1. Forward secrecy. Esta propiedad es importante para los mecanismos de autenticación basada en contraseñas a partir de las cuales se deriva una clave simétrica, ya que no se puede esperar que la contraseña siga siendo segura a largo plazo, lo cual puede afectar a la seguridad de las contraseñas generadas a partir de la misma.
  2. Protección ante ataques online. Un atacante que observe una autenticación satisfactoria, ¿puede utilizarla para autenticarse? En este aspecto, de forma conservadora se suele/puede asumir que el atacante tiene acceso a los mensajes enviados en claro (por ejemplo, como resultado de comprometer parcialmente el servidor).
  3. Protección ante compromisos de la base de datos. En concreto, mecanismos de este tipo que estén incluidos de forma nativa en el protocolo.
  4. ¿Tiene el servidor acceso a la contraseña en algún momento? Incluyendo no sólo durante la autenticación, sino también durante el registro.

Autenticación básica

En el mecanismo más sencillo, se supone que tanto cliente como servidor conocen inicialmente la contraseña (normalmente, el usuario la envía al servidor durante el registro inicial). Como se muestra en el siguiente diagrama, en este protocolo el cliente envía la contraseña en claro y el servidor simplemente responde si la autenticación ha sido correcta o no.

- Intercambio de mensajes en protocolos de autenticación básica -

Una variante sencilla de este esquema es en la que se envía un hash de la contraseña, o una versión cifrada de ella, en lugar de la contraseña en sí misma. Aunque preferible desde el punto de vista de la privacidad (ya que el servidor no obtiene acceso a la contraseña en claro), la seguridad final es prácticamente la misma, ya que siempre se transmite el mismo valor, que puede utilizarse directamente para suplantar al usuario.

Debido a su simplicidad, este esquema se ha empleado en multitud de sistemas y protocolos. Por ejemplo, es el mecanismo básico de autenticación en PAM para Unix. También se utiliza en muchas plataformas web (normalmente, encapsulando a través de TLS, aunque aún se encuentran sitios que lo utilizan en HTTP). Históricamente, una implementación bastante conocida es PAP, disponible en el protocolo PPP a nivel de enlace.

Protocolos de desafío-respuesta

En estos protocolos, tras establecer la conexión, el servidor envía al cliente un desafío que varía en cada autenticación, de tal forma que sólo un cliente legítimo (que sepa la contraseña) pueda contestar de forma satisfactoria. Esta opción supone una mejora para la seguridad, ya que la contraseña no se transmite durante la autenticación. En este caso, inicialmente también se supone que tanto cliente como servidor conocen la contraseña (compartida durante el registro). El siguiente diagrama muestra una secuencia de genérica de autenticación.

- Intercambio de mensajes en protocolos de autenticación desafío-respuesta -

Ejemplos de esta familia de mecanismos de autenticación son CRAM-MD5, DIGEST-MD5 o SCRAM-SHA-1 (este último, incorpora salts), disponibles por ejemplo en el framework SASL, utilizado para autenticación frente a servidores SMTP, IMAP, etc. Otro ejemplo de implementación de este mecanismo es CHAP, también disponible a través del protocolo PPP a nivel de enlace. En concreto, MS-CHAP, de Microsoft (siendo MS-CHAPv2 la última versión), sobre la que se conocen debilidades a nivel de implementación que reducen su seguridad.

Password-based Authenticated Key Exchange (PAKE)

En 1992, Bellovin y Merritt propusieron un protocolo (Encrypted Key Exchange, o EKE) para derivar una clave simétrica con un alto grado de seguridad a partir de una contraseña, esta última probablemente con baja entropía. Los esquemas surgidos con el mismo fin a partir de esta propuesta original se conocen como Password-based Authenticated Key Exchange, o PAKE.

En el esquema original, tanto servidor como usuario utilizaban la propia contraseña para derivar la clave final. Posteriormente, los mismos autores publicaron una variante en la que en lugar de la contraseña como tal se utiliza un hash (que también podría «saltearse») del mismo. Así, proporcionarían entre otras ventajas un mecanismo por defecto para proteger las contraseñas de los usuarios ante compromisos del servidor. Esta variante es conocida como Augmented-EKE, o A-EKE. No obstante, en su artículo definen la arquitectura del protocolo, sin llegar a dar construcciones específicas (es decir, criptosistemas concretos) para construir el protocolo. El estándar IEEE P1363.2-2008 contiene definiciones de esquemas basados en EKE.

La siguiente figura representa un diagrama de secuencia, simplificado, del protocolo A-EKE. Antes de una ejecución del protocolo, se supone que usuario y servidor ya conocen el valor hash(salt, password). Es destacable que este protocolo también requiere que el servidor demuestre que conoce el secreto inicial compartido, proporcionando autenticación mutua. Además, aunque por brevedad no se muestra en la figura siguiente, el protocolo también incluye un último mensaje adicional para evitar que un atacante pueda suplantar al usuario a partir del valor hash(salt, password).

- Intercambio de mensajes en protocolos PAKE -

El problema de EKE y A-EKE es que son mecanismos patentados, lo cual probablemente ha dificultado su despliegue, aunque también hay definiciones dentro de EAP que implementan EKE (RFC 6124).

Otro protocolo de la familia PAKE que sí se ha implementado en varios productos software es J-PAKE (o PAKE by Juggling). Por ejemplo, J-PAKE está implementado para Java en la librería criptográfica BouncyCastle, o en Openssl (aunque como mecanismo experimental aún).

Secure Remote Password (SRP)

Ya se revisó en un post anterior el mecanismo conocido como Secure Remote Password (SRP), por lo que desde aquí se remite a dicho análisis para conocer los detalles específicos del mismo. No obstante, a modo de resumen, es destacable que utiliza el concepto de verificadores. En concreto, el servidor nunca (ni siquiera durante el registro) tiene acceso a la contraseña. Es decir, mientras que en otros esquemas es necesario utilizar salts de manera explícita al almacenar las contraseñas hasheadas, en SRP esto se hace de forma nativa. Además, durante la autenticación en sí misma no se transmite ninguna información que pueda facilitar a un atacante obtener la contraseña, o utilizar el tráfico capturado para realizar nuevas autenticaciones. Como también se comentaba en el post mencionado, SRP tiene un importante apoyo en cuanto a implementaciones software.

Mecanismos de seguridad adicionales: uso de salts

Como se explica en «Password Security: A Case History», el uso de salts añade importantes ventajas, especialmente ante compromisos del servidor. En concreto, los salts imposibilitan en la práctica realizar ataques de diccionario impidiendo (a un atacante) determinar si dos hashes en los que se ha utilizado un salt distinto se han derivado a partir de la misma contraseña. Por lo tanto, aunque eventualmente un atacante conseguiría recuperar algunas contraseñas en claro a partir de una base de datos con contraseñas salteadas, el tiempo que necesitaría sería notablemente mayor que en el caso contrario (incluso podría hacer que el ataque no fuera práctico).

En el caso de A-EKE ya se ha especificado su compatibilidad con salts, ya que los propios creadores del protocolo hacen un análisis al respecto en el artículo original. Del mismo modo, SRP los incorpora también de forma nativa. En cuanto al resto de mecanismos, también es posible adaptarlos de forma que, en lugar de los hashes directamente, utilizasen hashes de los mismos, con salts.

Resumen

A continuación, resumimos las propiedades de los protocolos que se han introducido anteriormente. En el caso de PAKE, al ser una familia de protocolos, se utilizan como referencia los dos protocolos que se han visto (A-EKE y J-PAKE) aunque, dependiendo de la variante específica, podría haber cambios en las propiedades proporcionadas.

Protocolo Forward Secrecy Protección ante ataques online Protección ante compromisos de BBDD Acceso a contraseña por parte del servidor
Básico No aplica NO NO* SI
Desafío-Respuesta No aplica NO NO*
PAKE
SRP NO

*Sí, si se almacenan como hashes con salt, aunque no viene especificado en la definición del protocolo/mecanismo de forma nativa.