Las contraseñas y los protocolos de autenticación son REALMENTE seguros? No, no siempre

La autenticación es el proceso de veri cación de identidad de un usuario que se conecta al sistema. La efectividad de este proceso está determinada por los protocolos de autenticación y los mecanismos que se utilizan. En este artículo revisaremos y evaluaremos algunos de los tipos de autenticación para ver cuáles de ellos son realmente seguros.

Autenticación de acceso Básico HTTP

La primera versión de Protocolo de Iniciación

de Sesión (SIP) usaba Autenticación de acceso Básico HTTP. Este sistema es bastante fácil de acceder usando ataques de intermediarios. Como tipo de autenticación, ha caído en desuso desde hace algún tiempo.

En la Autenticación HTTP, un atacante puede simplemente capturar un paquete que contiene

la contraseña y el código base 64 codi cado, que luego se utiliza para decodificar y realizar ataques.

Entonces no, no es seguro.

Autenticación Digest

La autenticación Digest, utilizada tanto por

SIP como por HTTP, introduce la capacidad

de guardar solo una versión cifrada de la contraseña en el servidor. Esto evita que el cliente envíe la contraseña en un formato fácilmente decodi cable, y le permite al servidor guardar un hash de la contraseña (que no se puede ser decodi cado fácilmente).

Vamos a examinar en detalle los mensajes intercambiados entre el cliente y el servidor:

El servidor solicita la autenticación:

WWW-Authenticate: Digest realm=’testrealm@ host.com’, qop=’auth,auth-int’,nonce=’dcd9 8b7102dd2f0e8b11d0f600bfb0c093’,opaque=’5c cc069c403ebaf9f0171e9517f40e41’

El cliente agrega la información de autenticación:

Authorization:

Digest username=’Mufasa’, realm=’testrealm@host.com’, nonnce=’dcd98b7102dd2f0e8b11d0f600 bfb0c093’,uri=’/dir/index.

html’, qop=auth, nc=00000001, cnonce=’0a4f113b’, response=’6629f e49393a05397450978507c 4ef1’, opaque=’5ccc069c403ebaf9f0171e9517ff40e41’

El valor de la “respuesta” es calculado en los siguientes tres pasos (si los valores están combinados, se delimitan con dos puntos):

1. Se calcula el hash MD5 del nombre de usuario combinado, el ámbito de autenticación y la contraseña.
2. Se calcula el hash MD5 del método combinado y el URI de digest (por ejemplo, «GET» y «/ dir/index.html»). El resultado se conoce como HA2.
3. Se calcula el hash MD5 del resultado combinado HA1, servidor nonce (nonce), contador de solicitudes (nc), cliente nonce (cnonce), código de calidad de protección (qop) y resultado HA2. El resultado es el valor de «respuesta» proporcionado por el cliente.

HA1

= MD5(‘Mufasa:testrealm@host.com:Circle Of Life’) = 939e7578ed9e3c518a452acee763bce9

HA2

= MD5(‘GET:/dir/index.html’) = 39aff3a2bab6126f332b942af96d3366

Response

= MD5( ‘939e7578ed9e3c518a452acee763bce9:\ dcd98b7102dd2f0e8b11d0f600bfb0c093:\ 00000001:0a4f113b:auth:\ 39aff3a2bab6126f332b942af96d3366’)

= 6629fae49393a05397450978507c4ef1

Las ventajas de utilizar este método son las siguientes:

• La contraseña no es usada directamente en el digest, sino HA1 = MD5 (username:realm:password). Esto permite algunas implementaciones para almacenar HA1 en lugar de la contraseña en texto sin formato.
• El cliente nonce le permite al cliente prevenir ataques de texto sin formato que de otra manera podrían amenazar los esquemas de autenticación de digest.

• El servidor nonce puede contener marcas de tiempo, lo que signi ca que el servidor puede inspeccionar los atributos nonce enviados por los clientes para evitar ataques de repetición.

• El servidor también puede mantener una lista de valores nonce recientemente emitidos o utilizados para evitar su reutilización.

Digest es una mejora, pero todavía presenta inconvenientes significativos. El principal es que sufre de ataques de intermediario. Para lograr que Digest sea seguro, la conexión entre el cliente y el servidor debe estar encriptada y la clave de encriptación del servidor precargada, o debe usarse una autoridad de certi cación para permitir que el cliente veri que la clave pública del servidor.

SCRAM

XMPP admite texto sin formato, intercambios de contraseña de digest y también SCRAM (Salted Challenge Response Authentication Mechanism). SCRAM presenta ventajas sobre Digest, ya que permite que el servidor almacene hashes de contraseñas en un formato irreversible. Esta característica protege contra ataques sin conexión contra la contraseña y la base de datos del usuario. El cliente también puede guardar una versión solo de hash de la contraseña, haciéndole más difícil a los atacantes (que pueden tener acceso a la PC donde se almacena la contraseña) entender la contraseña en texto sin formato.

Además, SCRAM protege contra ataques de intermediario cuando se utilizan certi cados. Esto se hace permitiendo que el servidor demuestre al cliente que, no solo el certificado está firmado por una CA (Autoridad de certi cación), sino que también conoce la contraseña. Esta característica se denomina enlace de canal, ya que el canal de cifrado inferior está «vinculado» al canal de aplicación superior. También agrega más seguridad sobre TLS, que carece de autenticación de texto sin formato y autenticación digest.

Fortalezas de SCRAM:

• Almacenamiento seguro de contraseñas: cuando se implementa de manera correcta, el servidor puede almacenar las contraseñas en un formato hash iterativo salado, lo que di culta los ataques sin conexión y disminuye el impacto de los ataques a la base de datos.
• Simplicidad: Implementar SCRAM es más fácil que DIGEST-MD5.
• Interoperabilidad internacional: el RFC requiere que UTF-8 se use para nombres de usuario y contraseñas, a diferencia de CRAM- MD5.
• Debido a que solo la versión salada y hash de una contraseña se usa en todo el proceso de inicio de sesión, y la sal en el servidor no cambia, las contraseñas almacenadas por el cliente pueden usar las versiones hash y no exponer la contraseña de texto sin formato a los atacantes. Dichas versiones hash están vinculadas a un servidor, lo que lo hace ideal para la reutilización de contraseñas

Conclusiones

HTTP, XMPP, y SIP usando autenticación Digest ofrecen protección básica y son únicamente susceptible a:

• Ataques sin conexión: es decir que el respaldo o la copia de la base de datos almacenando los nombres de usuario y contraseñas es obtenida por un atacante.
• Ataques de intermediario: se limita a una sesión, ya que el uso de digest protege frente a la reutilización de hash.

Los ataques sin conexión se mitigan mediante el uso de funciones hash fuertes como las de la familia SHA2.

Para lograr que la comunicación sea segura, no solo durante la autenticación, sino también para proteger los datos intercambiados, se debe utilizar un protocolo de señalización seguro (TLS). Desafortunadamente, muchos sistemas UC disponibles no integran esta característica por defecto.

XMPP ofrece un mecanismo de autenticación mejorado a través de SCRAM. Esto ofrece una protección signi cativamente mejorada contra ataques sin conexión, ataques de intermediario y falsi cación de certi cados TLS. SCRAM se basa en una capa de transporte segura.

Hay propuestas (RFC 7804) para admitir también SCRAM sobre HTTP. Mientras tanto, la misma mejora introducida por SCRAM puede implementarse por separado por los desarrolladores web que implementan la plataforma de CUaaS.

¿Deseas saber más? Solicita la revista Wildix, donde encontrarás las experiencias de nuestros colaboradores y de usuarios como tú. Haz clic aquí