Guía de Referencias de OWASP Sobre Autentificación - Comentada Por Eugenia Bahit

Recomendaciones de OWASP sobre seguridad
en el desarrollo de Aplicaciones Web
Guas de Referencias Comentadas
Gua de Referencias sobre
Autentificacin
Traducida y comentada por
Eugenia Bahit
The Original Hacker N14

Serie: Guas Comentadas
Recomendaciones de OWASP sobre seguridad en el desarrollo de Aplicaciones Web - Pgina 2/25

GUA DE REFERENCIAS SOBRE AUTENTIFICACIN COMENTADA POR EUGENIA BAHIT www.originalhacker.org
Gua de Referencias sobre Autentificacin

Comentada por Eugenia Bahit
Revisado el 2 de agosto de 2015
Contenido
Introduccin....................................................................................................................................................3
Reglas generales de autentificacin..............................................................................................................3
ID de usuario..............................................................................................................................................3
Direccin de correo electrnico como ID de usuario.........................................................................4
Validacin.........................................................................................................................................5
Normalizacin..................................................................................................................................7
Implementar controles adecuados de fortaleza de contrasea .............................................................7
Advertencia...........................................................................................................................................7
Longitud de la contrasea....................................................................................................................8
Complejidad de la contrasea.............................................................................................................9
Topologas de contrasea..................................................................................................................10
Informacin adicional........................................................................................................................10
Implementar un mecanismo seguro de recuperacin de contrasea .................................................11
Almacenar contraseas de forma segura..............................................................................................12
Transmitir contraseas slo sobre TLS u otro transporte fuerte.........................................................12
Solicitar volver a autentificarse para funciones sensibles....................................................................13
Utilizar la autentificacin por mltiples factores...................................................................................14
Autentificacin TLS.............................................................................................................................14
Autentificacin y mensajes de error.......................................................................................................16
Respuestas de autentificacin......................................................................................................16
Ejemplo de respuestas incorrectas...............................................................................................16
Ejemplo de respuestas correctas..................................................................................................16
Cdigos de error y URLs................................................................................................................17
Prevenir ataques por fuerza bruta.........................................................................................................17
Uso de protocolos de autentificacin que no requieren contrasea ........................................................19
OAuth........................................................................................................................................................19
OpenId......................................................................................................................................................20
SAML.........................................................................................................................................................20
FIDO..........................................................................................................................................................21
Directrices generales para el manejo de sesiones.....................................................................................23
Gestin de contraseas................................................................................................................................23
Recursos adicionales....................................................................................................................................23
Autores y Editores principales.....................................................................................................................24
FUENTE ORIGINAL: https://www.owasp.org/index.php/Gu%C3%ADa_de_Referencias_sobre_Autentificaci%C3%B3n
Bajo Licencia Creative Commons 3.0

Introduccin
La autentificacin es el proceso de verificar que un individuo, entidad o sitio Web es
quien dice ser. En el contexto de una aplicacin Web, la autentificacin, comnmente es
realizada mediante el envo de un nombre de usuario o ID y, uno o ms datos de
informacin privada que solo un determinado usuario debe conocer.
El manejo de sesiones es un proceso por el cual un servidor mantiene el estado de una

entidad interactuando con l. Esto es requerido por un servidor para recordar como
debe reaccionar a las peticiones posteriores a lo largo de una transaccin. Las sesiones
son mantenidas en el servidor por un identificador de sesin el cual puede ser pasado y
devuelto entre el cliente y el servidor al transmitir y recibir solicitudes. Las sesiones
deben ser nicas por usuario e informticamente, muy difciles de predecir.
Reglas generales de autentificacin

ID de usuario
Asegrese de que sus nombres/identificadores de usuarios no sean sensibles a
maysculas y minsculas. El usuario 'smith' y el usuario 'Smith' deberan ser el mismo
usuario.
En este punto en concreto, la no distincin entre maysculas y minsculas debera
considerarse un vulnerabilidad puesto que la equidad automatizada entre 'smith' y
'Smith' facilitara el reconocimiento de un nombre de usuario a un atacante.
Un ejemplo que puede ayudar a entender esto como una vulnerabilidad sera el
siguiente:
Dado un usuario aDMin cuya contrasea es 123456, cualquier atacante que intentase
la tan conocida (y para nada segura) combinacin de usuario y contrasea
admin/123456, podra acceder al sistema con menos intentos que si tuviese que
acertar la combinacin interna de maysculas y minsculas en el propio nombre de

usuario, puesto que matemticamente, se requiere de un mayor nmero de

combinaciones posibles.
Direccin de correo electrnico como ID de usuario

Muchos sitios utilizan la direccin de correo electrnico como identificador de usuario, lo
cual es un buen mecanismo para asegurar un identificador nico por cada usuario sin
agregarle a stos la carga de tener que recordar un nuevo nombre de usuario. Sin
embargo, muchas aplicaciones Web no tratan correctamente las direcciones de correo
electrnico, debido a conceptos equivocados sobre lo que constituye una direccin de
correo electrnico vlida.
En concreto, es completamente vlido tener una direccin correo electrnico que:
Es sensible a maysculas y minsculas en la parte local
Tiene caracteres no alfanumricos en la parte local (incluyendo + y @)
Tiene cero o ms etiquetas (aunque ciertamente cero no va a ocurrir)
La parte local es la parte de la direccin de correo electrnico que se encuentra a la

izquierda del caracter '@'. El dominio es la parte de la direccin de correo electrnico
que se encuentra a la derecha del caracter '@' y consiste en cero o ms etiquetas unidas
por el caracter de punto.
Al momento de estar escribir este artculo, el RFC 5321 es el estndar actual que define
el protocolo SMTP y lo que constituye una direccin de correo electrnico vlida.
Por favor, tenga en cuenta que las direcciones de correo electrnico deberan ser
consideradas datos pblicos. En aplicaciones de alta seguridad, podran asignarse los
nombres de usuario y ser secretos en lugar de ser datos pblicos definidos por el
usuario.
Este ltimo aspecto es de vital importancia y el programador no debe dejar de

tenerlo en cuenta ni mucho menos, descartarlo.

Aplicaciones Web destinadas al manejo de informacin sensible, tales como
cuestiones relacionadas al dinero o datos privados que puedan comprometer la
seguridad fsica de las personas o sus bienes, no deberan utilizar jams una direccin
de correo electrnico como identificador de usuario. En su defecto, debera ser el
sistema quien generase dicha informacin de forma automtica y la provea al usuario.
Otro factor a tener en cuenta, es proteger por diseo dicha informacin para evitar
una violacin de privacidad indirecta que ponga en riesgo la seguridad de la
aplicacin. Es el caso de los nombres de usuario que, por diseo, se utilizarn como
identificadores pblicos del usuario, frente a otros usuarios del sistema. Imagines un
foro como StackOverflow donde la direccin de correo electrnico no solo fuese el
identificador de usuario para el proceso de autentificacin, sino que por diseo, se lo
utilizase para que los usuarios se identificasen entre s. En estos casos, sera preferible
utilizar otro identificador menos comprometido para que los usuarios se
identificaran entre s.
Validacin
Muchas aplicaciones Web contienen expresiones regulares informticamente muy
costosas e inexactas para intentar validar las direcciones de correo electrnico.
Cambios recientes generaron que el nmero de falsos negativos se viera incrementado,
particularmente debido a:
El aumento de popularidad de las sub-direcciones de proveedores como Gmail
(comnmente usando + como token en la parte local para afectar la entrega)
Nuevos gTLDs con nombres largos (muchas expresiones regulares comprueban el
nmero y longitud de cada etiqueta en el dominio)
Siguiendo el RFC 5321, las mejores prcticas para la validacin de una direccin de
correo electrnico deberan ser:

Comprobar la presencia de al menos un smbolo de @ en la direccin

Asegurarse de que la parte local no es de ms de 64 bytes
Asegurarse de que el dominio no es de ms de 255 bytes
Asegurarse que sea una direccin de entrega verdica (NdT: se refiere a que el
correo pueda ser entregado)
Para asegurarse que una direccin de entrega sea verdica, la nica forma es enviar un
correo electrnico al usuario y que ste deba tomar alguna accin para confirmar que lo
ha recibido. Ms all de confirmar que la direccin de correo electrnico es vlida y
reciba los mensajes, esto tambin proporciona una confirmacin positiva de que el
usuario tiene acceso al buzn de correo y es probable que est autorizado a usarlo. Esto
no significa que otros usuarios no tengan acceso al mismo buzn de correo, cuando por
ejemplo el usuario utiliza un servicio que genera una direccin de correo electrnico
desechable.
Las validaciones de correo electrnico pueden llegar a ser muy costosas para la
aplicacin y para el servidor.
Tal y como asegura la gua de OWASP, es necesario asegurarse de que la direccin de
correo exista (sea verdica) y para ello, nunca deber enviarse el correo de
comprobacin SIN ANTES haber validado la entrada del usuario, ya que direcciones de
correo electrnico mal formadas, tales como 'foobar', podran generar extensas colas
de salida en el servidor, que provocasen un consumo innecesario de recursos.
Por otra parte, los correos electrnicos no confirmados, deberan persistir SOLO de
forma temporal en el sistema, para evitar que el colapso de una base de datos genere
la falta de disponibilidad de la aplicacin Web. Esto demanda la toma de medidas de
limpieza automatizada en el sistema.
Un ejemplo de persistencia temporal y acciones de confirmacin, puede obtenerse en
el artculo Emulacin de tokens de seguridad temporales para el registro de
usuarios el cual puede descargarse desde la siguiente URL:
http://library.originalhacker.org/biblioteca/articulo/ver/115

Normalizacin
Como la parte local de las direcciones de correo electrnico son, de hecho, sensibles a
maysculas y minsculas, es importante almacenar y comparar las direcciones de correo
electrnico correctamente. Para normalizar la entrada de una direccin de correo
electrnico, debera convertir la parte del dominio SOLO a minsculas.
Desafortunadamente, esto hace y har a la entrada, ms difcil de normalizar y de
coincidir correctamente con los intentos del usuario.
Es razonable aceptar solo una nica capitalizacin de diferentes alternativas para

direcciones de correo electrnico idnticas. Sin embargo, en este caso es crtico para:
Almacenar la parte del usuario tal y como fue provista y verificada por el usuario
en el proceso de verificacin
Realizar comparaciones lowercase(provista) == lowercase(almacenada)
Implementar controles adecuados de fortaleza de

contrasea
Una de las principales preocupaciones cuando se utilizan contraseas para la
autentificacin, es la fortaleza de las contraseas. Una poltica de contraseas "fuertes"
hace que sea difcil o incluso improbable adivinar la contrasea a travs de medios
manuales o automatizados. Las siguientes caractersticas definen una contrasea fuerte:
Advertencia
Las siguientes indicaciones estn disputadas. Por favor, vea la presentacin de OWASP
(en ingls), "Your Password Complexity Requirements are Worthless - OWASP AppSecUSA

2014" para ms informacin.
Longitud de la contrasea
Las contraseas ms largas proporcionan una mayor combinacin de caracteres y en
consecuencia hacen que sea ms difcil de adivinar para un atacante.
La longitud mnima de las contraseas debera ser forzada por la aplicacin.

Las contraseas menores a 10 caracteres son consideradas dbiles ([1]).
Mientras que la longitud mnima forzada puede causar problemas para la memorizacin
de la contrasea en algunos usuarios, las aplicaciones deberan alentarlos a establecer
frases de paso o passphrases (frases o combinaciones de palabras) que pueden ser

mucho ms largas que las contraseas tpicas y mucho ms fciles de recordar.
La longitud mxima de la contrasea no debera establecerse demasiado baja,

ya que evitar que los usuarios puedan crear frases de paso (passphrases). La
longitud mxima tpica es de 128 caracteres.
Frases de paso de menos de 20 caracteres usualmente son consideradas
dbiles si solo se emplean letras minsculas.
Es muy comprensible que esta seccin haya presentado disputas en el propio seno de
OWASP, ya que la longitud de una contrasea, es un hecho que no influye demasiado
en los intentos de 'adivinacin' manuales.
Las contraseas se obtienen mayormente con mejores resultados, mediante el estudio
y perfilado del sujeto.
De hecho, la mayora de las veces lleva menos tiempo la
obtencin manual de una contrasea que la automatizada a travs de fuerza bruta.

Por ejemplo, una tpica mam que tiene su escritorio empapelado de fotos de sus tres
hijos, es ms probable que utilice contraseas largas que cortas, ya que muy
probablemente utilice una contrasea formada por los nombres de sus tres hijos o sus

fechas de nacimiento ordenadas desde el primognito hacia el ms pequeo.
Complejidad de la contrasea
Las aplicaciones deberan imponer reglas de complejidad de contraseas para evitar las
contraseas fciles de adivinar. Los mecanismos de contraseas deberan permitir al
usuario, poder tipear casi cualquier caracter como parte de su contrasea, incluyendo el
caracter de espacio. La contraseas deberan, obviamente, ser sensibles a maysculas y
minsculas a fin de incrementar la complejidad de las mismas. Ocasionalmente,
encontramos sistemas donde las contraseas no son sensibles a maysculas y
minsculas, frecuentemente debido a problemas de sistemas heredados como los viejos
ordenadores centrales que no tenan contraseas sensibles a maysculas y minsculas.
El mecanismo de cambio de contrasea debera requerir un nivel mnimo de

complejidad que tenga sentido para la aplicacin y su poblacin de usuarios. Por
ejemplo:
La contrasea debe reunir al menos 3 de las siguientes 4 reglas de complejidad
al menos 1 mayscula (A-Z)
al menos 1 minscula (a-z)
al menos 1 dgito (0-9)
al menos 1 caracter especial (puntuacin) no olvidar de tratar tambin, a
los espacios en blanco como un caracter especial
al menos 10 caracteres
no ms de 128 caracteres
no ms de 2 caracteres idnticos consecutivos (ej., 111 no est permitido)
Desde un punto de vista lgico-matemtico, la complejidad de una contrasea la hace

tan difcil de acertar automticamente como desde el punto de vista psicolgico, para
adivinarla de forma manual. Por ello, independientemente de la opinin personal de

cada uno, poner mayor nfasis en la complejidad de la contrasea que en su longitud,

con certeza la har mucho menos probable de vulnerar.
Topologas de contrasea
Prohibir topologas de contraseas de uso comn
Forzar a varios usuarios a utilizar diferentes topologas de contrasea
Exigir un cambio mnimo de topologa entre viejas y nuevas contraseas
En lo particular, se debera tener especial cuidado con este aspecto ya que para
ponerlo en prctica, supone el almacenamiento histrico de las contraseas de un
usuario, algo que puede generar desconfianza en los usuarios ya que se encuentran
frente a un sistema informtico que sabe ms sobre ellos que ellos mismos.
Desde mi punto de vista, deberan solo contrastarse la ltima contrasea con la nueva,
para as evitar una excesiva intromisin en la privacidad del usuario. Tngase en
cuenta que el historial de contraseas elegidas por un usuario, en trminos
criminolgicos, puede ser utilizado para complementar el perfil de ste.
Informacin adicional
Asegrese de que todos los caracteres que el usuario escribe estn realmente
incluidos en la contrasea. Hemos visto sistemas que truncan la contrasea a una
longitud inferior de la que el usuario provee (ej., truncada a los 15 caracteres
cuando se han ingresado 20).
Esto es manejado usualmente al establecer la longitud de TODOS los
campos de contrasea exactamente como la longitud mxima de la
contrasea. Esto es particularmente importante si su longitud mxima de
contrasea es corta, como 20-30 caracteres.
Si la aplicacin requiere polticas de contrasea ms complejas, ser necesario ser muy

claro sobre cules son esas polticas.

La poltica requerida necesita ser indicada explcitamente en la pgina de cambio
de contrasea
asegrese de enumerar cada caracter especial que permite, para que sea
evidente para el usuario
Recomendacin:
Lo ideal, sera que la aplicacin indicara al usuario cmo escribir su nueva
contrasea y cunto de la directiva de complejidad de su nueva contrasea
cumple
De hecho, el botn de envo debera verse atenuado hasta que la nueva
contrasea rena los requisitos establecidos en la poltica de complejidad
de contrasea y la segunda copia de la nueva contrasea coincida con la
primera. Esto har que sea mucho ms fcil, para el usuario, entender la
poltica de complejidad y cumplirla.
Independientemente de cmo se comporte la UI, cuando un usuario enva su solicitud

de cambio de contrasea:
Si la nueva contrasea no cumple con la poltica de complejidad de contrasea, el
mensaje de error debera describir TODAS las reglas de complejidad con las cules
la nueva contrasea no cumple y no sola la primera regla con la que no cumpla.
Implementar un mecanismo seguro de recuperacin

de contrasea
Es comn que una aplicacin tenga un mecanismo que provea al usuario un medio para
acceder a su cuenta en caso de que olvide su contrasea. Por favor, para ms detalles
sobre esta caracterstica, vea Forgot Password Cheat Sheet (en ingls).

Almacenar contraseas de forma segura

Es fundamental para una aplicacin, almacenar contraseas usando la tcnica
criptogrfica correcta. Para conocer ms sobre este mecanismo, vea Password Storage
Cheat Sheet (en ingls).
Transmitir contraseas slo sobre TLS u otro

transporte fuerte
Ver: Transport Layer Protection Cheat Sheet (en ingls)
Al hablar de TLS nos estamos refiriendo al sucesor de SSL
La pgina de inicio de sesin y todas las pginas autentificadas subsiguientes, deberan

ser accedidas exclusivamente sobre TLS u otro transporte fuerte. La pgina de inicio de
sesin principal, conocida como "landing page", debe ser servida sobre TLS u otro
transporte fuerte.
Si no se utiliza TLS u otro transporte fuerte para la landing page de inicio de sesin, se
permite a un atacante modificar el action del formulario de inicio de sesin, generando
que las credenciales del usuario sean enviadas a una ubicacin arbitraria.
Si no se utiliza TLS u otro transporte fuerte para las pginas autentificadas que se
habilitan luego del inicio de sesin, un atacante puede ver la ID de sesin sin cifrar y
comprometer la sesin autentificada del usuario.

Muchos programadores, sobre todo los acostumbrados a desarrollar en ordenadores

con sistemas operativos de uso personal, suelen tenerle un poco de 'miedo' a la
instalacin de certificados de seguridad y los mecanismos de transporte de
informacin segura como TLS (antiguamente conocido como SSL).
Sin embargo, implementar dichos mecanismos no es complejo en lo absoluto. En
https://www.digitalocean.com/community/tutorials/how-to-set-up-apache-with-a-freesigned-ssl-certificate-on-a-vps puede obtenerse un tutorial de cmo hacer esto.
Solicitar volver a autentificarse para funciones

sensibles
Con el fin de mitigar ataques CSRF y de secuestro de sesin (hijacking), es importante
solicitar las credenciales actuales de una cuenta en los siguientes casos:
Antes de modificar informacin sensible (como la contrasea del usuario, la
direccin de correo electrnico del usuario)
Antes de transacciones sensibles (como enviar una compra a una nueva
direccin).
Sin esta contramedida, un atacante puede ser capaz de ejecutar transacciones sensibles
a travs de un ataques CSRF o XSS sin necesidad de conocer las credenciales actuales del
usuario. Adicionalmente, un atacante puede obtener, temporalmente, acceso fsico al
navegador del usuario o robar su ID de sesin para tomar el control de la sesin del
usuario.
A veces lo menos pensado por su simpleza es lo que mayor dao podra causar.
Muchos programadores evitan este tipo de medidas argumentando que solo
'Fulanito' tendr acceso al sistema. Pero 'Fulanito' podr tener acceso como
administrador. Y 'Fulanito' podr acceder desde su ordenador y descuidarlo un solo
minuto. Y en ese minuto, cualquier persona -y no necesariamente mal intencionada,

basta con que sea una persona 'metida' y poco cuidadosa- podra tomar posicin de su
ordenador y 'tocar lo que no debe'. Si es una funcionalidad sensible, no importa quin
har uso de ella. Siempre habr que tomar medidas preventivas.
Utilizar la autentificacin por mltiples factores

La autentificacin por mltiples factores (MFA por las siglas en ingles de "Multi-factor
authentication") es el uso de ms de un factor de autentificacin para iniciar sesin o
procesar una transaccin, mediante:
Algo que se conoce (detalles de la cuenta o contraseas)
Algo que se tiene (tokens o telfonos mviles)
Algo que se es (factores biomtricos)
Los esquemas de autentificacin como las contraseas de un solo uso (OTP por las siglas
en ingls de "One Time Passwords") implementadas utilizando un token fsico (hardware)
tambin pueden ser un factor clave en la lucha contra ataques tales como los ataques
CSRF y malware del lado del cliente. Un considerable nmero de los token de hardware
para MFA disponibles en el mercado, permiten una buena integracin con las
aplicaciones Web. Ver: [2] (en ingls).
Los token de seguridad por hardware no suelen ser tan conocidos en Amrica Latina y
pases subdesarrollados como lo son en pases del primer mundo.
En esta zona del mundo, los dispositivos de seguridad por hardware suelen ser
econmicamente muy costosos y no demasiado simples de conseguir, por lo que su
implementacin debera ser cuidadosamente estudiada antes de tomar desiciones.
Autentificacin TLS
La autentificacin TLS, tambin conocida como autentificacin TLS mutua, consiste en

que ambos, navegador y servidor, enven sus respectivos certificados TLS durante el
proceso de negociacin TLS (handshaking). As como se puede validar la autenticidad de
un servidor mediante el certificado y, preguntar a una Autoridad de Certificacin
conocida (CA, por las siglas en ingls de "Certificate Authority") si la certificacin es
vlida, el servidor puede autentificar al usuario recibiendo un certificado desde el cliente
y validndolo contra una CA o su propia CA. Para hacer esto, el servidor debe proveer al
usuario de un certificado generado especficamente para l, asignando valores que
puedan ser usados para determinar que el usuario debe validar el certificado. El usuario
instala los certificados en el navegador y los usa para el sitio Web.
Es una buena idea hacer esto cuando:

Es aceptable (o incluso preferido) que el usuario slo tenga acceso a la pgina web
desde una sola computadora/navegador.
El usuario no se asusta fcilmente por el proceso de instalacin de certificados TLS
en su navegador o habr alguien, probablemente de soporte de TI, que har esto
para el usuario.
El sitio web requiere un paso adicional de seguridad.
El sitio Web es de la intranet de una compaa, empresa u organizacin.
Por lo general, no es una buena idea utilizar este mtodo para la mayor parte de los
sitios Web de acceso pblico que tendrn un usuario promedio. Por ejemplo, no ser
una buena idea implementar esto en un sitio Web como Facebook. Si bien esta tcnica
puede evitar que el usuario tenga que escribir una contrasea (protegindola as contra
el robo desde un keylogger promedio), an se considera una buena idea emplear el uso
de una contrasea combinada con la autentificacin TLS.
Para ms informacin, ver: Client-authenticated TLS handshake
Definitivamente, este mecanismo de autentificacin, es el ms reticente para los

usuarios y desde mi punto de vista, solo debera ser implementado en una Intranet
(donde exista personas de soporte IT que se encargue de la instalacin de los
certificados).
Autentificacin y mensajes de error

En el caso de las funcionalidades de autentificacin, los mensajes de error
implementados de forma incorrecta pueden ser utilizados con el propsito de obtener y
almacenar identificadores de usuario y contraseas. Una aplicacin, debera responder
(tanto en los encabezados HTTP como en el contenido HTML) de forma genrica.
Respuestas de autentificacin
Una aplicacin debera responder mensajes de error genricos independientemente de
si era incorrecto el identificador de usuario o la contrasea. Tampoco debera dar
informacin sobre el estado de una cuenta existente.
Ejemplo de respuestas incorrectas

"Inicio de sesin para el usuario foo: contrasea incorrecta"
"Fall el inicio de sesin: usuario no vlido"
"Fall el inicio de sesin: cuenta deshabilitada"
"Fall el inicio de sesin: usuario inactivo"
Ejemplo de respuestas correctas

"Fall el inicio de sesin: Usuario o contrasea incorrectos"
La respuesta correcta no debera indicar si el identificador de usuario o la contrasea es

el parmetro incorrecto y por lo tanto, inferir un identificador de usuario vlido.
Cdigos de error y URLs

La aplicacin puede retornar un cdigo de error HTTP diferente dependiendo del
resultado del intento de autentificacin. Puede responder con un 200 para un resultado
positivo y con un 403 para un resultado negativo. Aunque una pgina de error genrico
sea mostrada al usuario, el cdigo de respuesta HTTP puede ser diferente, permitiendo
filtrar la informacin sobre si la cuenta es vlida o no.
Prevenir ataques por fuerza bruta

Si un atacante es capaz de adivinar una contrasea sin ser deshabilitada debido a
intentos de autentificacin fallidos, el atacante tiene la oportunidad de continuar con un
ataque de fuerza bruta hasta que la cuenta se vea comprometida. La automatizacin de
los ataques de fuerza bruta para adivinar contraseas en aplicaciones Web son un
desafo muy usual.
Los mecanismos de bloqueo de contrasea deberan ser empleados para bloquear una
cuenta si se realiza ms de un nmero predeterminado de intentos fallidos de
autentificacin.
Los mecanismos de bloqueo de contrasea tienen una debilidad lgica. Un atacante que
emprende un gran nmero de intentos de autentificacin sobre nombres de cuentas
conocidas puede producir como resultado, el bloqueo de bloques enteros de cuentas de
usuario. Teniendo en cuenta que la intencin de un sistema de bloqueo de contrasea es
proteger de ataques por fuerza bruta, una estrategia sensata es bloquear las cuentas por
un perodo de tiempo (ej., 20 minutos). Esto ralentiza considerablemente a los atacantes
mientras que permite automticamente, reabrir las cuentas para los usuarios legtimos.
Adems, la autenticacin de mltiples factores es un muy poderoso elemento de

disuasin cuando se trata de prevenir los ataques de fuerza bruta ya que las credenciales
son un blanco mvil. Cuando la autenticacin de mltiples factores se implementa y
activa, el bloqueo de cuentas ya no es necesario.
A veces cuesta un poco entender la debilidad y objetivo del bloqueo de contraseas,

por eso lo explicar de un modo simple.
Para qu bloquear una cuenta? Si tras varios intentos de autentificacin fallidos, la
contrasea no es bloqueada, tras cada intento el atacante gana una posibilidad ms de
adivinar la clave y tener xito. Se bloquea la contrasea para que el atacante deje de
intentar adivinar la clave y fracase.
Pero qu sucede si se bloquea la cuenta de forma permanente? Este puede
convertirse en el objetivo real de un atacante. Por ejemplo, supongamos que se
establece un mximo de 3 intentos fallidos. Entonces el atacante, a propsito, falla 3
veces la autentificacin de cada uno de los usuarios. Por consiguiente, bloquear todas
las cuentas del sistema y en un escenario ideal (para el atacante), el sistema quedara
en desuso ya que todos los accesos estaran bloqueados.
Para qu se bloquea entonces de forma temporal? Para que los legtimos usuarios
puedan acceder y el sistema no quede completamente bloqueado.
Pero la pregunta debera ser si es realmente til el bloqueo de cuentas? Por lo
general, cuando una cuenta es bloqueada, en la mayora de los casos se debe a que el
legtimo usuario es quien fracasa en los intentos de autentificacin. En lo personal,
creo que el bloqueo de contrasea -aunque temporal- puede llegar a ser ms
peligroso de lo que se cree.
Una solucin creativa
Tal vez, lo realmente 'molesto', es el intento de acceso ilegtimo y continuo. Los
ataques por fuerza bruta si son repetidos, continuos y simultneos, pueden tambin
coincidir en un DDoS (nuevamente, en un escenario ideal para los atacantes). Pero
esto solo sucede en ataques automatizados. Por lo tanto, se evitara empleando algn

mtodo de validacin 'humana'. Por ejemplo, tras 3 intentos de autentificacin fallida,

puedo bloquear la contrasea del usuario de forma temporal (20' por ejemplo) y a la
vez, enviarle un correo al usuario, de 'desbloqueo de contrasea'. Siguiendo un enlace
enviado a su correo electrnico, el usuario podra desbloquear su cuenta y seguir
intentndolo (o intentar recuperar su clave).
Uso de protocolos de autentificacin que

no requieren contrasea
Mientras que la autentificacin a travs de una combinacin usuario/contrasea y el uso
de la autentificacin de factores mltiples es generalmente considerada segura, hay
casos de uso en los que no se considera la mejor opcin o incluso seguro. Un ejemplo de
esto son las aplicaciones de terceros que desean conectarse a la aplicacin Web, ya sean
desde un dispositivo mvil, algn otro sitio web, aplicaciones de escritorio u otras
situaciones. Cuando esto sucede, NO es considerado seguro permitir a la aplicacin de
terceros almacenar la combinacin de usuario/contrasea, ya que se ampla la superficie
de ataque a sus manos, donde queda fuera de su control. Por esto y por otros casos de
uso, hay varios protocolos de autentificacin que pueden protegerlo de exponer los
datos de sus usuarios a los atacantes.
OAuth
Open Authorization (OAuth) es un protocolo que permite a una aplicacin autentificar a
un usuario contra un servidor, sin requerir contraseas o algn servidor externo que
acte como proveedor de identidad. Utiliza un token generado por el servidor,
ofreciendo un flujo de autorizacin sostenido, para que un cliente tal como una
aplicacin mvil, pueda llamar al servidor que el usuario est utilizando el servicio.
La recomendacin es usar e implementar OAuth 1.0a o OAuth 2.0, ya que a la primera
versin (OAuth1.0) se la ha encontrado vulnerable a los ataques de fijacin de sesin

(session fixation).
OAuth 2.0 se basa en HTTPS para la seguridad y actualmente es usado e implementado
por las API de empresas como Facebook, Google, Twitter y Microsoft. OAuth1.0a es ms
difcil de usar porque requiere de bibliotecas criptogrficas para las firmas digitales. Sin
embargo, no se basa en HTTPS para la seguridad y, por lo tanto, puede ser ms
adecuado para las transacciones de mayor riesgo.
OpenId
OpenId es un protocolo basado en HTTP que utiliza proveedores de identidad para
validar que un usuario es quien dice ser. Es un protocolo muy simple que permite a un
proveedor de servicios de identidad un camino para el inicio de sesin nico (SSO, por
las siglas en ingls de "single sign-on"). Esto permite a los usuarios reutilizar una sola
identidad dada a un proveedor de identidad OpenId de confianza y ser el mismo usuario
en mltiples sitios web, sin la necesidad de proveer la contrasea a ningn sitio Web,
exceptuando al proveedor de identidad OpenId.
Debido a su simplicidad y a que proporciona proteccin de contraseas, OpenId ha sido
bien aceptado. Algunos de los proveedores de identidad OpenId bien conocidos son
Stack Exchange, Google, Facebook y Yahoo!
Para entornos no empresariales, OpenId es considerado seguro y frecuentemente, la
mejor opcin, siempre y cuando el proveedor de identidad sea de confianza.
SAML
El lenguaje de marcado para confirmaciones de seguridad (SAML, siglas en ingls de
"Security Assertion Markup Language") a menudo se considera la competencia de
OpenId. La versin ms recomendada es la 2.0, ya que posee caractersticas muy
completas y proporciona gran seguridad. Como con OpenId, SAML utiliza proveedores de
identidad, pero a diferencia de ste, est basado en XML y proporciona mayor

flexibilidad. SAML est basado en redirecciones del navegador las cuales envan los datos
en formato XML. A diferencia de SAML, OpenId no solo es iniciado por un proveedor de
servicios, sino que tambin puede ser iniciado desde el proveedor de identidad. Esto
permite al usuario navegar entre diferentes portales mientras que se mantienen
autentificado sin tener que hacer nada, haciendo que el proceso sea transparente.
Mientras que OpenId ha tomado la mayor parte del mercado de consumo, SAML es a
menudo la opcin para aplicaciones empresariales. La razn de esto, frecuentemente, es
que hay pocos proveedores OpenId que son considerados de clase empresarial (lo que
significa que la forma en la que validan la identidad del usuario no tiene los altos
estndares requeridos para la identidad de la empresa). Es ms comn ver SAML siendo
usado dentro de la intranet de un sitio Web, a veces incluso, utilizando un servidor desde
la internet como el proveedor de identidad.
En los ltimos aos, las aplicaciones como SAP ERP y SharePoint (SharePoint utilizando
Active Directory Federation Services 2.0) deciden usar la autentificacin SAML 2.0, a
menudo como un mtodo preferido para las implementaciones de inicios de sesin
nicos siempre que se requiera la federacin empresarial para servicios Web y
aplicaciones.
Ver tambin: SAML Security Cheat Sheet
FIDO
La Fast Identity Online (FIDO) Alliance ha creado dos protocolos para facilitar la
autentificacin online: los protocolos Universal Authentication Framework (UAF) y
Universal Second Factor (U2F). Mientras que el protocolo UAF se enfoca en la

autentificacin sin contrasea, U2F permite la adicin de un segundo factor de
autenticacin basado en contraseas existentes. Ambos protocolos estn basados en

una llave pblica de modelo criptogrfico desafo-respuesta.
UAF toma ventaja de las tecnologas de seguridad existentes presentes en los

dispositivos de autenticacin, incluyendo sensores de huellas digitales, cmaras
(biomtrica facil), micrfonos (biomtrica de voz), Entornos de ejecucin de confianza
(TEE, siglas en ingls de Trusted Execution Environment), Elementos seguros (SE, siglas en
ingls de Secure Elements) y otros. El protocolo est diseado para conectar las
capacidades de este dispositivo en un marco de autenticacin comn. UAF trabaja con
ambas aplicaciones nativas y Web.
U2F aumenta la autenticacin basada en contraseas mediante un token de hardware

(tpicamente un USB) que almacena llaves de autenticacin criptogrficas y las utiliza
para firmar. El usuario puede utilizar el mismo token como un segundo factor para
mltiples aplicaciones. U2F trabaja con aplicaciones Web. Provee proteccin contra
phishing utilizando la URL del sitio Web para buscar la llave de autentificacin
almacenada.
De todos los protocolos, oAuth es el ms viable.

SAML parece estar muy pensado desde las complejas, pragmticas y poco razonables
miradas de quines ven en las tecnologas privativas soluciones viables. Ms all de
toda opinin, es de hacer notar que nada que sea privativo puede ser
fehacientemente comprobado como seguro, ya que solo se basa en la confianza
que el programador tenga en la compaa que lo desarrolla pero no en la razn lgica.
Desde mi punto de vista no parece ser una gran alternativa aunque s funciona, lo hace
desde el pragmatismo.
OpenId no est nada mal, pero se basa mucho en la confianza. Es decir, se tiene que
confiar en el proveedor de identidad y la confianza no es racional, sino tambin
pragmtica.
FIDO, es una gran alternativa, aunque claramente costosa y solo se justifica en
mbitos demasiado puntuales (no son protocolos para emplear en el promedio de los

sistemas).
Directrices generales para el manejo de

sesiones
El manejo de sesiones est directamente relacionado a la autentificacin. Las Directrices
generales para el manejo de sesiones previamente disponibles en esta Hoja de
referencias de Autentificacin de OWASP han sido integradas en Session Management
Cheat Sheet (NdT: hoja en proceso de traduccin).
Gestin de contraseas
Los gestores de contraseas son programas, complementos para el navegador o
servicios Web que automatizan el manejo de un gran nmero de diferentes credenciales,
incluyendo la memorizacin y rellenado automtico, generando contraseas aleatorias
en diferentes sitios, etc. La aplicacin Web puede ayudar a los administradores de
contraseas:
usando formularios HTML estndar para los campos de ingreso de nombres de
usuario y contraseas,
no deshabilitando el "copy & paste" en los campos de los formularios HTML,
permitiendo contraseas muy largas,
no usando esquemas de inicio de sesin en mltiples etapas (nombre de usuario
en la primera pantalla, luego la contrasea),
no usando esquemas de autentificacin con largos scripts (JavaScript).
Recursos adicionales
Un PDF del Cheatsheet en ingls puede obtenerse aqu:

https://magic.piktochart.com/output/7003174-authentication-cheat-sheet
Autores y Editores principales

Eoin Keary
Jim Manico
Timo Goosen
Pawel Krawczyk
Sven Neuhaus
Manuel Aude Morales
Traducido al Espaol para OWASP, por:

Eugenia Bahit

Acerca de Eugenia Bahit

GLAMP Hacker & eXtreme Programmer
especializada en seguridad informtica e
Ingeniera Inversa de cdigo para el
desarrollo de Software.
Docente e instructora de programacin en
Python y PHP.
Miembro de Free Software Foundation,
The Linux Foundation y OWASP.
Creadora del deployer para servidores Web,
JackTheStripper y el kernel para
aplicaciones MVC modulares, Europio
Engine.
Autora de la Teora sintctico-gramatical
de Objetos y otros textos de investigacin.
Fundadora de las revistas Hackers &
Developers Magazine y The Original
Hacker.
Sitios Web
Cursos de Programacin a distancia:
www.cursosdeprogramacionadistancia.com
Web personal:
www.eugeniabahit.com
The Original Hacker:
www.originalhacker.org
Twitter:
www.twitter.com/eugeniabahit

Guía de Referencias de OWASP Sobre Autentificación - Comentada Por Eugenia Bahit

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Guía de Referencias de OWASP Sobre Autentificación - Comentada Por Eugenia Bahit

Caricato da

Copyright:

Formati disponibili

Recomendaciones de OWASP sobre seguridad

en el desarrollo de Aplicaciones Web

Guas de Referencias Comentadas

Gua de Referencias sobre

The Original Hacker N14

Recomendaciones de OWASP sobre seguridad en el desarrollo de Aplicaciones Web - Pgina 2/25

Gua de Referencias sobre Autentificacin

Revisado el 2 de agosto de 2015

FUENTE ORIGINAL: https://www.owasp.org/index.php/Gu%C3%ADa_de_Referencias_sobre_Autentificaci%C3%B3n

Bajo Licencia Creative Commons 3.0

Recomendaciones de OWASP sobre seguridad en el desarrollo de Aplicaciones Web - Pgina 3/25

El manejo de sesiones es un proceso por el cual un servidor mantiene el estado de una

Reglas generales de autentificacin

FUENTE ORIGINAL: https://www.owasp.org/index.php/Gu%C3%ADa_de_Referencias_sobre_Autentificaci%C3%B3n

Bajo Licencia Creative Commons 3.0

Recomendaciones de OWASP sobre seguridad en el desarrollo de Aplicaciones Web - Pgina 4/25

usuario, puesto que matemticamente, se requiere de un mayor nmero de

Direccin de correo electrnico como ID de usuario

La parte local es la parte de la direccin de correo electrnico que se encuentra a la

Este ltimo aspecto es de vital importancia y el programador no debe dejar de

FUENTE ORIGINAL: https://www.owasp.org/index.php/Gu%C3%ADa_de_Referencias_sobre_Autentificaci%C3%B3n

Bajo Licencia Creative Commons 3.0

Recomendaciones de OWASP sobre seguridad en el desarrollo de Aplicaciones Web - Pgina 5/25

tenerlo en cuenta ni mucho menos, descartarlo.

FUENTE ORIGINAL: https://www.owasp.org/index.php/Gu%C3%ADa_de_Referencias_sobre_Autentificaci%C3%B3n

Bajo Licencia Creative Commons 3.0

Recomendaciones de OWASP sobre seguridad en el desarrollo de Aplicaciones Web - Pgina 6/25

Comprobar la presencia de al menos un smbolo de @ en la direccin

FUENTE ORIGINAL: https://www.owasp.org/index.php/Gu%C3%ADa_de_Referencias_sobre_Autentificaci%C3%B3n

Bajo Licencia Creative Commons 3.0

Recomendaciones de OWASP sobre seguridad en el desarrollo de Aplicaciones Web - Pgina 7/25

Es razonable aceptar solo una nica capitalizacin de diferentes alternativas para

Implementar controles adecuados de fortaleza de

FUENTE ORIGINAL: https://www.owasp.org/index.php/Gu%C3%ADa_de_Referencias_sobre_Autentificaci%C3%B3n

Bajo Licencia Creative Commons 3.0

Recomendaciones de OWASP sobre seguridad en el desarrollo de Aplicaciones Web - Pgina 8/25

2014" para ms informacin.

La longitud mnima de las contraseas debera ser forzada por la aplicacin.

frases de paso o passphrases (frases o combinaciones de palabras) que pueden ser

La longitud mxima de la contrasea no debera establecerse demasiado baja,

De hecho, la mayora de las veces lleva menos tiempo la

obtencin manual de una contrasea que la automatizada a travs de fuerza bruta.

FUENTE ORIGINAL: https://www.owasp.org/index.php/Gu%C3%ADa_de_Referencias_sobre_Autentificaci%C3%B3n

Bajo Licencia Creative Commons 3.0

Recomendaciones de OWASP sobre seguridad en el desarrollo de Aplicaciones Web - Pgina 9/25

fechas de nacimiento ordenadas desde el primognito hacia el ms pequeo.

El mecanismo de cambio de contrasea debera requerir un nivel mnimo de

Desde un punto de vista lgico-matemtico, la complejidad de una contrasea la hace

FUENTE ORIGINAL: https://www.owasp.org/index.php/Gu%C3%ADa_de_Referencias_sobre_Autentificaci%C3%B3n

Bajo Licencia Creative Commons 3.0

Recomendaciones de OWASP sobre seguridad en el desarrollo de Aplicaciones Web - Pgina 10/25

cada uno, poner mayor nfasis en la complejidad de la contrasea que en su longitud,

Si la aplicacin requiere polticas de contrasea ms complejas, ser necesario ser muy

FUENTE ORIGINAL: https://www.owasp.org/index.php/Gu%C3%ADa_de_Referencias_sobre_Autentificaci%C3%B3n

Bajo Licencia Creative Commons 3.0

Recomendaciones de OWASP sobre seguridad en el desarrollo de Aplicaciones Web - Pgina 11/25

claro sobre cules son esas polticas.

Independientemente de cmo se comporte la UI, cuando un usuario enva su solicitud

Implementar un mecanismo seguro de recuperacin

Bajo Licencia Creative Commons 3.0

Recomendaciones de OWASP sobre seguridad en el desarrollo de Aplicaciones Web - Pgina 12/25

Almacenar contraseas de forma segura

Transmitir contraseas slo sobre TLS u otro

Al hablar de TLS nos estamos refiriendo al sucesor de SSL