Contraseñas de un solo uso
Este documento discute el empleo de contraseñas de un solo uso como método seguro de autentificación en aplicaciones sobre redes.
Escenario
Un problema clásico de las aplicaciones que trabajan en red es el de la autentificación.
Es un escenario frecuente tener que enviar los datos que nos identifican por un medio que no es seguro Nuestro cliente se ve expuesto a dos medios susceptibles de interceptar su nombre de usuario y contraseña: la LAN e Internet.
En estos casos hay diferentes soluciones que han demostrado ser eficaces (SSL, IpSec), pero que por un motivo u otro no siempre están disponibles para el desarrollador (no siempre es posible disponer de un servidor http con SSL).
En este documento presenta varias alternativas para llevar a cabo el proceso de autentificación de forma segura.
Encriptación de contraseñas
En primer lugar hay que tener en consideración la seguridad del servidor. Siempre se debe evitar el tÃpico fichero con contraseñas en la forma: usuario contraseña. Las contraseñas siempre deben permanecer encriptadas en la máquina que realiza la autentificación.
Es recomendable el empleo de funciones hash (MD5, SHA, RIPEMD, ...) para almacenar las contraseñas. Estas funciones son irreversibles (teniendo el número generado por la función hash no existe el proceso inverso para obtener los datos que generaron ese número), por lo que es permisible que pudieran ser leidas por un intruso.
Almacenar la suma de comprobación de la contraseña empleando una función hash implica que si perdemos la contraseña, nos será imposible recuperarla ya que solo disponemos de del valor generado.
Parece que la solución está clara: como el valor resultante de la fórmula hash no es reversible, se puede enviar ese número para realizar la autentificación, evitando asà el envÃo de contraseñas visibles.
Nada más lejos de la realidad.
El hecho de enviar las contraseñas encriptadas no soluciona en absoluto nuestro problema ya que, un intruso situado en el medio inseguro, puede interceptar la suma de comprobación para luego simplemente enviarla directamente al servidor.
Como no podemos evitar que los datos enviados se intercepten, nos encontramos ante una difÃcil situación.
Contraseñas de un solo uso (OTP)
Si los datos de identificación se pueden interceptar, podrÃamos disponer de contraseñas que solo fueran válidas para un uso, de forma que los datos interceptados estuvieran caducados cuando el intruso quisiera emplearlos.
Esta forma de actualización parece poco viable, ya que implica un cambio de contraseña por cada acceso, y además esa contraseña deberÃa enviarse por un medio seguro.
No obstante, se puede implementar un sistema de contraseñas de un solo uso empleando el mismo medio inseguro para enviar enviar las 'nuevas contraseñas'. En realidad es el fundamento en que se basa, por ejemplo, SSL (aunque no soy un experto a ese respecto, que alguien me corrija si me equivoco).
Para emplear el sistema OTP (del ingés one time password) necesitamos definir:
contraseña: es la contraseña que realmente conoce el cliente
llave temporal: una contraseña temporal asociada a un instante en el tiempo y a los datos disponibles del cliente
sesión: intervalo de tiempo en el cual tiene validez una llave temporal
Para la implantación del sistema necesitamos soporte para encriptación tanto en el cliente como en el servidor. Supongamos para la explicación el uso de MD5.
usemos como ejemplo un algoritmo de contraseñas de un uso:
El cliente pide una nueva sesión
El servidor le devuelve un una llave temporal t que solo valdrá para esa sesión
El cliente encripta la contraseña proporcionada por el usuario con MD5 obteniendo MD5_c. Es necesario ya que el servidor tiene almacenadas las contraseñas en esa forma. Entonces se procesa MD5_c empleando t. Ese procesamiento puede ir desde una concatenación hasta la aplicación del algoritmos de cifrado. De ese proceso se obtiene un MD5 que llamamos MD5_C, y es el valor que enviaremos al servidor.
Ahora el servidor debe realizar el proceso que ya ha hecho el cliente para ver si obtiene el mismo MD5 recibido MD5_C. Para ello procesa MD5_s (la contraseña almacenada previamente encriptada con MD5) con t y aplica el MD5 para obtener MD5_S que finalmente es comparado con MD5_C.
Analicemos los púntos débiles del algoritmo: envÃo de datos.
Cuando el cliente pide una nueva sesión, el servidor genera t empleando la hora del sistema o un número aleatorio, asociando la IP del cliente a ese valor. El servidor no debe guardar t, sino el valor temporal o aleatorio. Posteriormente recalculará t en el paso 4 con la IP del cliente que envÃa los datos del paso 3. De esta forma evitamos que una máquina pida sesión y otra distinta conteste. Por supuesto esto no es infalible, aunque si proporciona un nivel aceptable de seguridad para muchos casos.
El cliente, en el paso 3, envÃa un MD5 por el medio inseguro. Ese dato podrÃa ser interceptado, pero solo tiene validez para esa sesión, por lo que resultarÃa completamente inútil para un intruso.
Como se puede observar, realmente se emplea una contraseña cada vez, pero de forma automática y transparente para el usuario y el administrador.
Implementación: PHP con MD5
Supongamos una aplicación web sobre http que requiere de una autentificación segura via formulario y no se dispone de SSL.
La implementación requiere de:
Servidor: PHP (versión 4, adaptable a anteriores)
Cliente: JavaScript (necesario para encriptación)
El sistema requiere de dos partes diferenciadas: cliente y servidor.
La parte cliente consta de un formulario en el que se introducen los datos de autentificación. El documento lleva código JavaScript con una llave temporal, y se encarga de encriptar y procesar la contraseña mediante MD5 antes de enviar los datos mediante POST al servidor.
La parte servidor se encarga de, empleando variables de sesión, crear una sesión cuando se genera el formulario generando la llave temporal, y posteriormente verificar el MD5 enviado.
Implementación de ejemplo:
<?php
/*
* Fichero: index.php
* Descripción: Punto de entrada. login/password
*
* Copyright (C) 2002 Juan J. Martinez <jjm at usebox.net>
* This code must be distributed under GPL details.
* GPL text is available here:
Para ver este enlace Registrate o Inicia Sesion*/
/*
*
* Esta rutina se llama para comprobar si MD5_C es igual a MD5_S
*
*/
function autoriza() {
session_start();
$t=md5($_SESSION["t_parcial"] .getenv("REMOTE_ADDR"));
/* ahora comprobariamos en nuestra base de datos el usuario y contraseña,
aquà simplificamos: user admin/ password admin (hardcoded) */
if($_POST["i1"]=="admin" && md5("21232f297a57a5
a743894a0e4a80
1fc3" . $t)==$_POST["i2"]) {
/* estamos autorizados */
unset($_SESSION["t_parcial"]);
echo "AUTORIZADO ";
} else {
/* no estamos autorizados */
session_unset();
session_destro
y();
echo "Error de acceso ";
}
}
/*
*
* Genera el formulario con t para iniciar la sesión
*
*/
function muestraForm() {
session_start();
$_SESSION["t_parcial"]=md5(date("l dS of F Y h:i:s A"));
?>
<html>
<head>
<title>Welcome</title>
<!-- proporciona hex_md5 -->
<script src="md5.js"></script>
<script language="JavaScript">
// ESTA PAGINA REQUIERE JAVASCRIPT ACTIVADO //<!--
function encrypt() {
var md5_pre=hex_md5(document.login
.i2.value)
/* t = t_parcial + IP cliente */
var md5=hex_md5(md5_pre+"<? echo md5($_SESSION["t_parcial"] .getenv("REMOTE_ADDR")); ?>")
/* md5 es MD5_C */
document.login
.i2.value=md5
}
--></script>
</head>
<body>
<!-- genera el formulario -->
<div align="center">
<h2>Autentifiación</h2>
<table bgcolor="black" cellpadding="20" cellspacing="1" width="284" height="179">
<tr>
<td bgcolor="#ffffff">
<form name="login" action="index.php?accion=auth" method="POST" onsubmit="encrypt()">
<div align="right">
<p>User: <input type="text" size="15" name="i1">
Password: <input type="password" size="15" name="i2">
<p><input type="submit" value="Login">
</div>
</form>
</td>
</tr>
</table>
</div>
</body>
</html>
<?
}
/*
*
* Main()
*
*/
if($_GET["accion"]=="auth")
autoriza();
else
muestraForm();
?>
En el cliente se emplea una implementación de MD5 en JavaScript bajo licencia BSD disponible aquÃ.
Puedes bajar el código completo de la implementación (incluye md5.js) aquÃ.
Conclusiones
El empleo de contraseñas de un solo uso puede aumentar de forma considerable la seguridad de las autentificacio
nes en redes inseguras cuando no se dispone de recursos especiales para ese propósito (SSL, por ejemplo), de una forma sencilla y efectiva.
Posteriormente he descubierto que Yahoo! Mail parace utilizar este sistema (o silmilar) para autentificar a los usuarios cuando no se emplea SSL.
Si el lector encuentra un fallo o quiere comentar algún aspecto, puede ponerse en contacto mediante la dirección de correo que aparece al final del documento.
Última modificación: 23 Noviembre 2002.
Copyright © 2002 Juan J. MartÃnez <jjm at usebox.net>
Se permite la copia textual y distribución de este documento en su totalidad, por cualquier medio, siempre y cuando se mantenga esta nota de copyright.
Autor