Autenticación

 https://es.wikipedia.org/wiki/Autenticaci%C3%B3n

Autenticación
Ir a la navegaciónIr a la búsqueda

Este artículo o sección necesita referencias que aparezcan en

una publicación acreditada.
Puedes avisar al redactor principal pegando lo siguiente en su página de
discusión: {{sust:Aviso referencias|Autenticación}} ~~~~
Este aviso fue puesto el 5 de junio de 2018.

La autenticación o autentificación1es el acto o proceso de confirmar que algo (o alguien)

es quien dice ser. A la parte que se identifica se le llama probador. A la parte que verifica
la identidad se la llama verificador. Es habitual que el probador sea un usuario que quiere
acceder a ciertos recursos y el verificador sea un sistema que protege el acceso a dichos
recursos y tiene que verificar que el que accede sea un usuario que tiene permisos para
acceder a esos recursos. Para poder tener autenticación es necesaria, como condición
previa, la existencia de identidades biunívocamente identificadas de tal forma que se
permita su identificación.

Índice
[ocultar]

 1Definiciones
 2Tipos de autenticación
 3Características de autenticación
 4Mecanismo de autenticación
 5Control de acceso
 6Autenticación por multifactor
 7Autenticación
 8Autenticación de usuarios en Unix
o 8.1Autenticación clásica
 8.1.1Problemas del modelo clásico
o 8.2Shadow Password
o 8.3Envejecimiento de contraseñas
o 8.4Otros métodos
 9PAM
o 9.1Sintaxis del archivo de configuración
 10Véase también
 11Enlaces externos
 12Referencias

Definiciones[editar]
Autenticación, autentificación (palabra preferida por la RAE2) o mejor
dicho acreditación, en términos de seguridad de redes de datos, se puede considerar uno
de los tres pasos fundamentales (AAA). Cada uno de ellos es, de forma ordenada:

1. Autenticación. En la seguridad de ordenador, la autenticación es el

proceso de intento de verificar la identidad digital del remitente de una
comunicación como una petición para conectarse. El remitente siendo
 autenticado puede ser una persona que usa un ordenador, un ordenador
por sí mismo o un programa del ordenador. En un web de confianza,
"autenticación" es un modo de asegurar que los usuarios son quien ellos
dicen que ellos son - que el usuario que intenta realizar funciones en un
sistema es de hecho el usuario que tiene la autorización para hacer así.
2. Autorización. Proceso por el cual la red de datos autoriza al usuario
identificado a acceder a determinados recursos de la misma.
3. Auditoría. Mediante la cual la red o sistemas asociados registran todos y
cada uno de los accesos a los recursos que realiza el usuario autorizados
o no.
El problema de la autorización a menudo, es idéntico a la de autenticación; muchos
protocolos de seguridad extensamente adoptados estándar, regulaciones obligatorias,
y hasta estatutos están basados en esta asunción. Sin embargo, el uso más exacto
describe la autenticación como el proceso de verificar la identidad de una persona,
mientras la autorización es el proceso de verificación que una persona conocida tiene
la autoridad para realizar una cierta operación. La autenticación, por lo tanto, debe
preceder la autorización. Para distinguir la autenticación de la autorización de término
estrechamente relacionada, existen unas notaciones de taquigrafía que son: A1 para
la autenticación y A2 para la autorización que de vez en cuando son usadas,también
existen los términos AuthN y AuthZ que son usados en algunas comunidades.

Tipos de autenticación[editar]
Los métodos de autenticación están en función de lo que utilizan para la verificación y
estos se dividen en tres categorías:

 Sistemas basados en algo conocido. Ejemplo, un password (Unix)

o passphrase (PGP).
 Sistemas basados en algo poseído. Ejemplo, una tarjeta de identidad,
una tarjeta inteligente(smartcard), dispositivo usb tipo epass token, Tarjeta de
coordenadas, smartcard o dongle criptográfico.
 Sistemas basados en una característica física delante usuario o un acto
involuntario del mismo: Ejemplo, verificación de voz, de escritura, de huellas,
de patrones oculares.

Características de autenticación[editar]
Cualquier sistema de identificación ha de poseer unas determinadas
características para ser viable:

 Ha de ser fiable con una probabilidad muy elevada (podemos hablar de tasas
de fallo de en los sistemas menos seguros)....
 Económicamente factible para la organización (si su precio es superior al valor
de lo que se intenta proteger, tenemos un sistema incorrecto).
 Soportar con éxito cierto tipo de ataques.
 Ser aceptable para los usuarios, que serán al fin y al cabo quienes lo utilicen.
 Respuesta inmediata, directa, inteligente, sencilla, ante cada situación.

Mecanismo de autenticación[editar]
Artículo principal: Protocolo de identificación

Para autenticar es necesario establecer un protocolo de comunicación entre

las partes de forma que la parte verificadora (normalmente) prueba verificar
que la parte que se identifica (normalmente un usuario) efectivamente es
 quien dice que es. En general el proceso de autenticación consta de los
siguientes pasos:

1. El probador solicita acceso a un sistema.

2. El verificador solicita al usuario que se autentique.
3. El probador aporta las credenciales que le identifican y permiten verificar la
autenticidad de la identificación.
4. El verificador valida según sus reglas si las credenciales aportadas son
suficientes para dar acceso al usuario o no.

Control de acceso[editar]
Un ejemplo familiar es el control de acceso. Un sistema informático
supuesto para ser utilizado solamente por aquellos autorizados, debe
procurar detectar y excluir el desautorizado. El acceso a él por lo tanto es
controlado generalmente insistiendo en un procedimiento de la
autentificación para establecer con un cierto grado establecido de
confianza la identidad del usuario, por lo tanto concediendo esos
privilegios como puede ser autorizado a esa identidad. Los ejemplos
comunes del control de acceso que implican la autenticación incluyen:

 Retirar de dinero de un cajero automático.

 Control de un computador remoto sin Internet.
 Uso de un sistema de banca por Internet.
Para intentar probar la identidad de un sujeto u objeto posible aplicar
una o más pruebas que, si se aprueban, se han declarado
previamente para ser suficientes proceder. El problema es
determinarse qué pruebas son suficientes, y muchos tales son
inadecuadas. Han sido muchos casos de tales pruebas que son
engañadas con éxito; tienen por su falta demostrada, ineludible, ser
inadecuadas. Mucha gente continúa mirando las pruebas -- y la
decisión para mirar éxito en pasar -como aceptable, y para culpar su
falta en “descuido” o “incompetencia” de parte de alguien. El problema
es que la prueba fue supuesta para trabajar en la práctica -- no bajo
condiciones ideales de ningún descuido o incompetencia-y no. Es la
prueba que ha fallado en tales casos. Considerar la caja muy común
de un email de la confirmación a el cual deba ser contestado para
activar una cuenta en línea de una cierta clase. Puesto que el email
se puede arreglar fácilmente para ir a o para venir de direcciones
falsas y untraceable, éste es justo sobre la menos autenticación
robusta posible. El éxito en pasar esta prueba significa poco, sin
consideración alguna hacia sloppiness o incompetencia.

Autenticación por multifactor[editar]

Los factores de la autenticación para los seres humanos se clasifican,
generalmente, en cuatro casos:

 Algo que el usuario es (ejemplo, la huella digital o el patrón retiniano), la

secuencia de ADN (hay definiciones clasificadas de cuál es suficiente), el
patrón de la voz (otra vez varias definiciones), el reconocimiento de la firma,
las señales bio-eléctricas únicas producidas por el cuerpo vivo, u otro
identificador biométrico).
 Algo que el usuario tiene (ejemplo, tarjeta de la identificación, símbolo de la
seguridad, símbolo del software o teléfono celular)
 Algo que el usuario sabe (ejemplo, una contraseña, una frase o un número de
identificación personal (el PIN) del paso).
 Algo que el usuario hace (ejemplo, reconocimiento de voz, firma, o el paso).
y

 Autenticación mediante dos factores "algo que tengo" la llave + "algo que sé"
un número de PIN (token criptográfico)
 Autenticación triple factor "algo que tengo" el dispositivo criptográfico + "algo
que sé" una clave de autenticación tipo PIN (al token criptográfico) + "quién
soy" la huella dactilar que me permite autenticarme al dispositivo de forma
unívoca.

Una combinación de métodos se utiliza a veces, ejemplo, una

tarjeta de banco y un PIN, en este caso se utiliza el término
“autenticación de dos factores”. Históricamente, las huellas
digitales se han utilizado como el método más autoritario de
autenticación, pero procesos legales recientes en los E.E.U.U. y a
otra parte han levantado dudas fundamentales sobre fiabilidad de
la huella digital. Otros métodos biométricos son prometedores (las
exploraciones retinianas y de la huella digital son un ejemplo),
pero han demostrado ser fácilmente engañados en la práctica. En
un contexto de los datos de la computadora, se han
desarrollado protocolos de desafío-respuesta que permiten el
acceso si el que se quiere autenticar responde correctamente a
un desafío propuesto por el verificador. Hay protocolos desafío-
respuesta basados en algoritmos criptográficos
llamándose protocolos criptográficos de desafío-respuesta. La
seguridad de los protocolos criptográficos de desafío-respuesta se
basa en la seguridad de los algoritmos criptográficos que usa.

Autenticación[editar]
El Authentication fue definido por Arnnei Speiser en 2003 mientras
que la Web basó el servicio que proporciona en la autenticación
de usuarios finales que tienen acceso (Login) a un servicio de
Internet. La Autenticación es similar a la verificación de la tarjeta
de crédito para los Web site del eCommerce. La verificación es
hecha por un servicio dedicado que reciba la entrada y vuelva la
indicación del éxito o de fallo. Por ejemplo, un usuario final desea
entrar en su Web site. Él consigue entrar en una página Web de la
conexión que requiere para acceso, su user-id y una contraseña o
a los sitios asegurados y su contraseña a la vez. La información
se transmite al servicio del eAuthentication como pregunta. Si el
servicio vuelve éxito, permiten al usuario final entrar en el servicio
de esa página Web con sus privilegios como usuario.

Autenticación de usuarios en Unix[editar]

Autenticación clásica[editar]
En un sistema Unix habitual cada usuario posee un nombre de
entrada al sistema o login y una clave o password; ambos datos
se almacenan generalmente en el fichero /etc/passwd. Este
archivo contiene una línea por usuario donde se indica la
información necesaria para que los usuarios puedan conectar al
sistema y trabajar en él, separando los diferentes campos
mediante ':'.
Al contrario de lo que mucha gente cree, Unix no es capaz de
distinguir a sus usuarios por su nombre de entrada al sistema.
Para el sistema operativo lo que realmente distingue a una
persona de otra (o al menos a un usuario de otro) es el UID del
usuario en cuestión; el login es algo que se utiliza principalmente
para comodidad de las personas (obviamente es más fácil
acordarse de un nombre de entrada como toni que de un UID
como 2643, sobre todo si se tienen cuentas en varias máquinas,
cada una con un UID diferente).
Para cifrar las claves de acceso de sus usuarios, el sistema
operativo Unix emplea un criptosistema irreversible que utiliza la
función estándar de C crypt, basada en el algoritmo DES. Para
una descripción exhaustiva del funcionamiento de crypt. Esta
función toma como clave los ocho primeros caracteres de la
contraseña elegida por el usuario (si la longitud de esta es menor,
se completa con ceros) para cifrar un bloque de texto en claro de
64 bits puestos a cero; para evitar que dos passwords iguales
resulten en un mismo texto cifrado, se realiza una permutación
durante el proceso de cifrado elegida de forma automática y
aleatoria para cada usuario, basada en un campo formado por un
número de 12 bits (con lo que conseguimos 4096 permutaciones
diferentes) llamado salt. El cifrado resultante se vuelve a cifrar
utilizando la contraseña del usuario de nuevo como clave, y
permutando con el mismo salt, repitiéndose el proceso 25 veces.
El bloque cifrado final, de 64 bits, se concatena con dos bits cero,
obteniendo 66 bits que se hacen representables en 11 caracteres
de 6 bits cada uno y que, junto con el salt, pasan a constituir el
campo password del fichero de contraseñas, usualmente
/etc/passwd. Así, los dos primeros caracteres de este campo
estarán constituidos por el salt y los 11 restantes por la
contraseña cifrada.
Problemas del modelo clásico[editar]
Los ataques de texto cifrado escogido constituyen la principal
amenaza al sistema de autenticación de Unix; a diferencia de lo
que mucha gente cree, no es posible descifrar una contraseña,
pero es muy fácil cifrar una palabra junto a un determinado salt, y
comparar el resultado con la cadena almacenada en el fichero de
claves. De esta forma, un atacante leerá el fichero /etc/passwd
(este fichero ha de tener permiso de lectura para todos los
usuarios si queremos que el sistema funcione correctamente), y
mediante un programa adivinador (o crackeador) cifrará todas las
palabras de un fichero denominado diccionario (un
fichero ASCII con un gran número de palabras de cualquier
idioma o campo de la sociedad: historia clásica, deporte,
cantantes...), comparando el resultado obtenido en este proceso
con la clave cifrada del fichero de contraseñas; si ambos
coinciden, ya ha obtenido una clave para acceder al sistema de
forma no autorizada.
Shadow Password[editar]
Otro método cada día más utilizado para proteger las contraseñas
de los usuarios el denominado Shadow Password u
oscurecimiento de contraseñas. La idea básica de este
mecanismo es impedir que los usuarios sin privilegios puedan leer
el fichero donde se almacenan las claves cifradas.
Envejecimiento de contraseñas[editar]
En casi todas las implementaciones de Shadow Password
actuales se suele incluir la implementación para otro mecanismo
de protección de las claves denominado envejecimiento de
contraseñas (Password Aging). La idea básica de este
mecanismo es proteger los passwords de los usuarios dándoles
un determinado periodo de vida: una contraseña solo va a ser
válida durante un cierto tiempo, pasado el cual expirará y el
usuario deberá cambiarla.
Realmente, el envejecimiento previene, más que problemas con
las claves, problemas con la transmisión de estas por la red:
cuando conectamos mediante mecanismos como telnet, ftp o
rlogin a un sistema Unix, cualquier equipo entre el nuestro y el
servidor puede leer los paquetes que enviamos por la red,
incluyendo aquellos que contienen nuestro nombre de usuario y
nuestra contraseña.
Otros métodos[editar]
Algo por lo que se ha criticado el esquema de autenticación de
usuarios de Unix es la longitud, para propósitos de alta seguridad,
demasiado corta de sus claves; lo que hace años era poco más
que un planteamiento teórico, actualmente es algo factible: sin ni
siquiera entrar en temas de hardware dedicado, seguramente
demasiado caro para la mayoría de atacantes, con un
supercomputador es posible romper claves de Unix en menos de
dos días.
Un método que aumenta la seguridad de nuestras claves frente a
ataques de intrusos es el cifrado mediante la función conocida
como bigcrypt() o crypt16(), que permite longitudes para las
claves y los salts más largas que crypt y sin embargo, aunque se
aumenta la seguridad de las claves, el problema que se presenta
aquí es la incompatibilidad con las claves del resto de Unices que
sigan utilizando crypt; este es un problema común con otras
aproximaciones que también se basan en modificar el algoritmo
de cifrado, cuando no en utilizar uno nuevo.

PAM[editar]
PAM (Pluggable Authentication Module) no es un modelo de
autenticación en sí, sino que se trata de un mecanismo que
proporciona una interfaz entre las aplicaciones de usuario y
diferentes métodos de autenticación, tratando de esta forma de
solucionar uno de los problemas clásicos de la autenticación de
usuarios: el hecho de que una vez que se ha definido e
implantado cierto mecanismo en un entorno, es difícil cambiarlo.
Mediante PAM podemos comunicar a nuestra aplicaciones con los
métodos de autenticación que deseemos de una forma
transparente, lo que permite integrar las utilidades de un sistema
Unix clásico (login, ftp, telnet...) con esquemas diferentes del
habitual password: claves de un solo uso, biométricos, tarjetas
inteligentes...
La gran mayoría de las aplicaciones de linux usan estos métodos
(PAM) para autenticarse frente al sistema, ya que una aplicación
preparada para PAM (PAM-aware) puede cambiar el mecanismo
de autenticación que usa sin necesidade de recompilar los
 fuentes. Incluso se puede llegar a cambiar el sistema de
autenticación local sin siquiera tocar las aplicaciones existentes.
PAM viene `de serie' en diferentes sistemas Unix, tanto libres
como comerciales, y el nivel de abstracción que proporciona
permite cosas tan interesantes como kerberizar nuestra
autenticación (al menos la parte servidora) sin más que cambiar la
configuración de PAM, que se encuentra bien en el fichero
/etc/pam.conf o bien en diferentes archivos dentro del directorio
/etc/pam.d/
PAM trabaja con cuatro tipos separados de tareas de
administración: authentication, account, session, y password. La
asociación del esquema de administración preferido con el
comportamiento de la aplicación se hace mediante archivos de
configuración. Las funciones de administración las hacen módulos
que se especifican en el archivo de configuración. Más adelante
se explicara brevemente la sintaxis del archivo de configuración
ya que se va fuera del alcance de este artículo.
Cuando una aplicación preparada para PAM inicia, se activa su
comunicación con la API de PAM. Entre otras cosas esto fuerza la
lectura del archivo de configuración: /etc/pam.conf.
Alternativamente puede ser que se inicie la lectura de los archivos
de configuración bajo /etc/pam.d/ (cuando existe un archivo de
configuración correcto bajo este directorio, se ignora el archivo
/etc/pam.conf)
Sintaxis del archivo de configuración[editar]
El archivo (/etc/pam.conf) está formado por una lista de reglas
(típicamente una por línea). Cada regla es un conjunto de campos
separados por espacios (los tres primeros son case-sensitives):
service type control module-path module-arguments
La sintaxis de los archivos bajo /etc/pam.d/ es igual salvo que no
existe el campo "service". En este caso "service" es el nombre del
archivo en el directorio /etc/pam.d/ (el nombre del archivo debe
estar en minúsculas) Usualmente service es el nombre del
servicio o aplicación comúnmente usado, ejemplo de esto son
login, su y ssh.
type especifica a que grupo de administración está asociada la
regla. Las entradas válidas son:

 account: este módulo maneja la cuenta sin basarse en autenticación.

Típicamente se usa para restringir/permitir el acceso a un servicio basado en la
hora o quizás desde donde se loguea el usuario (ej.: root solo se puede
loguear desde consola

 auth: provee mecanismo de autenticación (el usuario es quien dice ser).

 password: este módulo es requerido para modificar la password del usuario.

 session: este módulo está asociado con hacer tareas previas y/o posteriores al
inicio del servicio mismo (pueden ser cosas como montar un directorio, activar
logueos, etc).
El tercer campo control especifica que hacer si
falla el control aplicado. Existen dos sintaxis para
 este campo, una sencilla de un campo y otra que
especifica más de un campo dentro de corchetes
rectos [] Para la básica, las opciones son:

 required: indica que esta regla debe ser exitosa, de lo contrario el usuario no
es autorizado a correr el servicio. Si falla se devuelve el control al programa,
pero antes se ejecutan todos los módulos.

 requisite: es como el required, pero devuelve el control al programa enseguida

de fallar.

 sufficient: Si este módulo se verifica, entonces (se devuelve) se le da el ok al

programa y no se sigue verificando los otros módulos.

 optional: la falla o no de este módulo es solo importante si es el único

existente.
El cuarto campo module-
path especifica el path al módulo
PAM asociado con la regla. Los
módulos se encuentran en
/lib/security.
El quinto campo module-
arguments es un conjunto de
cero o más argumentos pasados
al módulo durante su invocación.
Los argumentos varían según el
módulo.
La configuración de los archivos
de configuración bajo /etc/pam.d/
resulta ser más flexible (se evita
tener una archivo único enorme).
Bajo este directorio se puede
encontrar el archivo de
confiuración personal de un
servicio particular como ser ssh.
La única diferencia entre la
sintaxis del archivo /etc/pam.conf
es que no existe el campo
service

 C:\Users\RINO\Downloads\LIBROS DE AUTENTICACION\fsi---iaa.pdf
 https://sites.google.com/site/albertolinares2smr/1-conceptos-basicos-de-seguridad-
informatica
 http://www.oas.org/en/citel/infocitel/2006/junio/seguridad_e.asp

AUTENTICACIÓN DE USUARIOS
Definición

Autenticación es el proceso que debe seguir un usuario para tener acceso a los recursos de
un sistema o de una red de computadores. Este proceso implica identificación (decirle al
sistema quién es) y autenticación (demostrar que el usuario es quien dice ser). La
autenticación por sí sola no verifica derechos de acceso del usuario; estos se confirman en
el proceso de autorización.

En general, la seguridad de las redes de datos requiere para conceder acceso a los servicios de la
red, tres procesos: (1) autenticación, (2) autorización y (3) registro.

 Autenticación: el proceso por el cual el usuario se identifica en forma inequívoca; es decir, sin
duda o equivocación de que es quien dice ser.
 Autorización: el proceso por el cual la red de datos autoriza al usuario identificado a acceder
a determinados recursos de la misma.
 Registro: el proceso mediante el cual la red registra todos y cada uno de los accesos a los
recursos que realiza el usuario, autorizado o no.

Estos tres procesos se conocen por las siglas en inglés como AAA, o Authentication, Authorization, y
Accounting.

Tipos de autenticación

Se puede efectuar autenticación usando uno o varios de los siguientes métodos:

 Autenticación por conocimientos: basada en información que sólo conoce el usuario.

 Autenticación por pertenencia: basada en algo que posee el usuario.
 Autenticación por características: basada en alguna característica física del usuario.

De lo anterior se deduce que la autenticación involucra aspectos físicos y lógicos relacionados con el
acceso, la utilización y la modificación de los recursos de la red o sistema. Autenticación física La
autenticación física se basa en algún objeto físico que posee el usuario, o en alguna característica
física del usuario; en tal caso utiliza algún tipo de mecanismo biométrico. La información capturada en
el proceso de autenticación, pasa al proceso de autorización realizado por personas, dispositivos
electrónicos de seguridad o sistemas de seguridad informática. Autenticación lógica La autenticación
lógica puede utilizarse para identificar personas o sistemas y se basa en información que sólo conoce
el usuario. La autenticación y autorización las realiza software especializado.

Si se combinan dos o más métodos de autenticación, esta se denomina autenticación múltiple (multi-
factor authentication) y es una autenticación más segura. Por ejemplo, autenticación doble si el
usuario debe presentar dos tipos de identificación, una física (una tarjeta) y la otra algo que el usuario
ha memorizado como una clave de seguridad o un número de identificación personal (PIN—Personal
Identification Number). Este es el caso de una tarjeta bancaria que se utiliza con un cajero automático
(ATM—Automatic Teller Machine). Más aún, algunos sistemas utilizan autenticación triple (con tres
factores): un objeto físico, una contraseña y algún dato biométrico como la huella digital.

Claudia Patricia Santiago Cely

Escuela Colombiana de Ingeniería “Julio Garavito”

 http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/212
 https://www.securityartwork.es/2010/03/24/owasp-top-10-iii-perdida-de-
autenticacion-y-gestion-de-sesiones/
OWASP TOP 10 (III): Pérdida de
autenticación y Gestión de Sesiones
24 de marzo de 2010 by David Monteagudo

Tras los dos artículos previos sobre el TOP 10 de OWASP, en esta ocasión el
artículo del top 10 del catálogo de vulnerabilidades de OWASP del año 2010 se
basa en la vulnerabilidad conocida como pérdida de autenticación y gestión de
sesiones. Esta vulnerabilidad, desde mi punto de vista, demuestra lo poco que
suele preocupar la seguridad a los usuarios. Aunque en la primera clasificación
del año 2004 estaba situada como la tercera más encontrada, en la
clasificación el año 2007 destacaba por haber descendido hasta el séptimo
puesto. Sin embargo, tres años después, en esta nueva clasificación, se vuelve
a observar un repunte en la localización de este tipo de vulnerabilidades que la
vuelve a colocar en la tercera posición dejando como anécdota la anterior
mejora.
Las vulnerabilidades relacionadas con la pérdida de autenticación y gestión de
sesiones son críticas en la seguridad de las aplicaciones y en especial de las
aplicaciones WEB, ya que permiten a un atacante suplantar la información de
un determinado usuario, pudiendo llegar a obtener una cuenta de
administración que le permita sabotear los controles de autorización y registro
de la aplicación. Esta situación podría ocasionar un acceso no autorizado a
cualquier tipo de información que se encuentre almacenada en el servidor o los
servicios que han sido comprometidos.
Existen multitud de situaciones en las que nos podemos encontrar ante una
aplicación vulnerable a este tipo de ataque, pero la mayor parte de las veces se
encuentran en la gestión de las contraseñas, la expiración de sesiones o el
proceso de cierre de sesión. Además, debe prestarse especial atención a las
procesos que permiten la recuperación de los valores del usuario de forma
automática como pueden ser los servicios de pregunta secreta, de
actualización de cuenta o de “Recordar contraseña”.
De nuevo, igual que ocurría en la vulnerabilidad explicada en el primer post de
la serie de inyecciones, hay multitud de ejemplos que podrían demostrar el uso
de esta vulnerabilidad, por lo que vamos a introducir únicamente un grupo
reducido de ejemplos que permitan ilustrar la situación, y en caso de que sea
necesaria alguna aclaración sobre cualquiera de los aspectos no considerados
esperamos que nos lo hagan saber a través de los comentarios.
Veamos el siguiente ejemplo como demostración del tipo de situaciones en las
que podemos encontrar un ataque de este tipo: sea una aplicación que dispone
de un frontal web en el que un usuario autenticado puede consultar una serie
de artículos de una determinada categoría. Navegando por cada uno de los
artículos accede a uno que le interesa y que quiere compartir con sus amigos,
por lo que accede a la url que tiene en su navegador del tipo:
http://owasp.s2grupo.es/catalog/product.jsp;jsessionid=c2VjdXJpdHlhcnR3b3Jr?article
=815
A continuación cierra su navegador y postea en una red social este enlace para
que todos puedan acceder a este curioso artículo. Como el servidor en el que
se encuentra el artículo no cierra la sesión del usuario salvo que sea por
petición de éste, cualquiera de sus “amigos” que acceda a dicho enlace
aparecerá registrado en la aplicación como el usuario autenticado con el
consecuente acceso a sus datos.
Del mismo modo, es posible encontrar un ejemplo de autenticación realizada a
través de medios no confiables. Pensemos que esta misma aplicación utiliza un
servicio de autenticación seguro a través de https. De esta forma, la
comunicación viaja cifrada y no es posible interceptar el tráfico para capturar la
contraseña del usuario. Como sucede en muchas páginas, el proceso de
autenticación proporciona la posibilidad de “recordar” al usuario al marcar
un check, de forma que se almacena en local una cookie de la página con el
nombre de usuario y contraseña introducidos en el formulario de autenticación.
https://owasp.s2grupo.es/catalog/login.jsp?username=owasp&pass=owasp123

Aunque durante el proceso de autenticación manual el servicio utiliza una

configuración segura a través de https, el proceso de autenticación automático
utiliza una configuración a través de http.
http://owasp.s2grupo.es/catalog/authlogin.jsp?username=owasp&pass=OWASP&cooki
e=true

En este momento, cualquier atacante de la aplicación que se encuentre

controlando el tráfico que intenta acceder la aplicación de catálogo dispondrá
del nombre de usuario y su contraseña por no haber utilizado un sistema de
comunicación seguro.
Existen diferentes formas de proteger la aplicación desarrollada de este tipo de
vulnerabilidades, pero requieren decisiones a nivel de diseño. En primer lugar,
la gestión de contraseñas nunca puede almacenarse en texto plano, aspecto
que aunque a ustedes les parezca obvio, es más común de lo que piensan.
Esto provocaría que un atacante que tuviese acceso a la tabla o al fichero en el
que se almacena la información de los usuarios tendría automáticamente
acceso a cualquier recurso de la aplicación que desease, independientemente
de las medidas de control que pudiésemos plantear. Además, deben utilizarse
los servicios que utilicen información sensible a través de canales seguros,
como puede ser una conexión sobre SSL, de forma que se evite la posibilidad
de que un atacante se interponga en la comunicación de esta información entre
nuestro cliente y el servidor de la aplicación de datos.
Por último, una serie de indicaciones generales sobre la forma de gestionar las
sesiones:

 Añadir la comunicación cifrada en en el proceso de acceso a la aplicación.

 Eliminar, en la medida de lo posible, la utilización de mecanismos de
autenticación del tipo “Recordar Contraseña” puesto que, generalmente, esta
contraseña se almacena para poder ser utilizada y la sustracción de ésta valor
podría ocasionar la suplantación de usuarios. Por supuesto, en este punto
entramos en el equilibrio entre seguridad y funcionalidad.
 Ofrecer un enlace en todas las páginas de la aplicación para que el usuario
pueda cerrar la sesión.
  Gestionar de forma adecuada la caducidad de las sesiones ante un período de
inactividad.
 Gestionar de forma adecuada el tratamiento de la información cuando se
introduzca un identificador de sesión caducado o no válido.

Y hasta aquí todo lo referente a las vulnerabilidades de pérdida de

autenticación y gestión de Sesiones, de momento. Como saben, si quieren
extenderse en la materia, más allá de los innumerables recursos de la red,
pueden acudir a la web de OWASP, donde encontrarán mucha información de
utilidad. Como siempre, si tienen interés en que demos más detalles sobre
alguna de las vulnerabilidades mostradas, o no les ha quedado clara la
explicación, no tienen más que indicarlo en los comentarios y estaremos
encantados de ampliar la información.