09. autentificacion[1]

Autentificación y Seguridad enAplicacionesAplicacionesWeb

Autenticación en Web

� El tráfico en Internet puede ser espiado y alterado con mucha facilidad

� ¿Cómo intercambiar datos � ¿Cómo intercambiar datos confidenciales?

Packet Sniffing

Login y pass van en caberas

Cabeceras HTTP en texto plano

van en caberas HTTP. Contenidos en HTML (texto)

Seguridad, alternativas

Codificar el mensaje …

… o emplear un canal seguro

Tipos de autenticación

Autentificación HTTP Básica

� Desde el protocolo HTTP 1.0

� Muy simple

� Poco seguro

autentificación HTTP > básica

� Cuando el navegador solicita un recurso (jsp, por ejemplo), el servidor solicita usuario y contraseña, que viajan codificadas en base 64 bits.

� Se puede reforzar combinándola con protocolo HTTPs, de forma que las peticiones HTTP viajen encriptadas.


Navegador Servidor



� Login: Aladdin, pass: open sesame

� “Aladdin:open sesame”� QWxhZGRpbjpvcGVuIHNlc2FtZQ==


Base64Aladdin

Codificación Base64


� Los caracteres ASCII se secuencian y se tomas de 6 en 6 bits.

� Cada grupo de 6 bits es índice de la tabla de caracteres Base64

Autentificación HTTP digest (hash)

� Incorporada en la versión 1.1 de la especificación del protocolo HTTP.

� Algo más complicada internamente que la autentificación básica.

autentificación HTTP > digest

autentificación básica.

� La codificación va en base al timestampgenerado por el servidor en el momento de la petición -> Más difícil de decodificar -> Más seguro.

� No está totalmente difundida ni aceptada por todos los navegadores y servidores.

Autentificación HTTP digest

Navegador Servidor

Challenge: “nonce” en Base64

nonce(client-IP ":" time-stamp ":" private-key )


MD5: Algoritmo de hash, genera una cadena de 32 char a partir de cualquier longitud de mensaje

Hashing

� Message Digest (MD4, MD5, …)

� Un algoritmo produce como resultado una secuencia de bits de tamaño fijo al aplicarlo sobre unos datos


nov-08 Alberto M.F.A. 12

al aplicarlo sobre unos datos� digest = hash(datos, longitud)

� digest tiende a ser aleatorio y uniformemente distribuido

� Solo funciona en un sentido� No existe datos = hash-1(digest)

Hashing

� Si digest es suficientemente largo (>= 128 bits) se puede usar como identificador único de un documento

� Prácticamente ningún otro



� Prácticamente ningún otro documento con la misma función hash() producirá el mismo digest� Cualquier cambio en los datos, por mínimo que sea, producirá otro digestimpredeciblemente diferente

Autentificación HTTPs

� Es el más seguro de los disponibles hoy en día.

� Se basa en mecanismos de Clave

autentificación HTTP > HTTPS (SSL)

� Se basa en mecanismos de Clave Pública (PKI): SSL (aka TLS)

� Requiere certificado(s) generado(s) por una autoridad certificadora (CEA)

� Hay un proceso “complicado” de handshake que garantiza la conexión segura.

Seguridad para WEB (HTTPS)

� HTTPS = HTTP Secure

� HTTP sobre un protocolo de transporte seguro

HTTP � SSL � TCP



� HTTP � SSL � TCP

� SSL también es conocido como TLS según IETF

SSL (o TLS)

� El servidor tiene un certificado� opcionalmente el cliente tiene el suyo

� Permite intercambio seguro de datos (p.e. claves de sesión)


datos (p.e. claves de sesión)

� Usa algoritmos de clave simétrica y asimétrica

� Ofrece:� Autentificación � Confidencialidad� Integridad� No repudio

Del servidor siempre, del cliente si tiene certificado

Cifrado con clave simétrica

� Ambas partes (A y B) conocen la clave

� Existe una pareja de funciones, de forma que: ( )kmfm ,* =



forma que:

� Con:� m, mensaje original

� m*, mensaje cifrado

� k, clave

( )( )kmfm

kmfm

*,

,*1−=

=

Esquema



Claves asimétricas

� También conocidos como Sistemas de clave pública (PKI)

� Cada parte tiene una pareja de claves



claves

� Se cumple que

� Con:� k1 y k2, claves pública y privada

( )( )2

1

1

*,

,*

kmfm

kmfm−=

=

Claves asimétricas

� Lo que se cifra con una se puede descifrar con la otra y viceversa

� La clave pública se da a todos los interlocutores



interlocutores

� La clave privada se guarda bajo 7 llaves

� Cada interlocutor tiene:� Su clave privada

� Las claves públicas de los demás

� Solo N + 1 claves � escala mucho mejor

¿Qué se consigue con clave asimétrica?

� Confidencialidad� Solo lo ve aquel a quien va dirigido

� Firma digital� Si se combina con hash



� Si se combina con hash

� El que lo recibe puede estar seguro de que lo envió el poseedor de la clave privada

� No repudio

� Autentificación

Confidencialidad



Firma digital



Autentificación



Intercambio de claves simétricas



Autoridades certificadoras

�� ¿Cómo sé que la clave pública que ¿Cómo sé que la clave pública que tengo es de quien realmente dice tengo es de quien realmente dice ser?ser?� Puede ser alguien suplantando al original



� Puede ser alguien suplantando al original

� Las autoridades certificadoras (CAs) actúan como notarios de la red.� Dan fe de que el poseedor de la clave privada es quien dice ser

� Tienen sus protocolos de autentificación

� No generan las claves solo las firman

Certificados

� Las claves públicas validadas por CA

� Contienen� La clave pública

� Datos de identificación del propietario



� Datos de identificación del propietario

� Fecha de expiración

� Firma digital de la CA� Verificable con la clave pública de la CA

� ¡Se debe conocer la clave pública de la CA!

Jerarquías de CA

� Las CA raíz autorizan a otras CA

� Esas CA pueden autorizar a otras, etc

Al recibir un certificado se debe



� Al recibir un certificado se debe recorrer toda la cadena de certificaciones hasta llevar a una raíz en la que se confíe

� Claves públicas raíz no hay muchas� Verising, Tawte, Microsoft, Verizon, etc.

Claves públicas de CA’s

� Vienen en:� Los sistemas operativos

� Los navegadores, etc

� Necesidad de actualizarse, cada



� Necesidad de actualizarse, cada nueva versión actualiza las claves públicas

� Si se recibe certificado de CA desconocida hay que “Depositar confianza” expresamente

Alerta de seguridad



SSL y claves públicas



1. CA root dan sus claves públicas a los fabricantes de navegadores




2. Los fabricantes de navegadores ponen las CA’s en sus navegadores




3. Los sitios WEB obtienen certificados firmados con la clave privada de una CA


4. Los sitios WEB



4. Los sitios WEB mandan su certificado con SSL. El navegador los verifica contra sus claves de CA’s

autentificación por programa

Autentificación por Programa

� Todo lo tenemos que programar

� La aplicación coteja la contraseña contra su propio sistema de control de usuarios

Hay que basarla en protocolos seguros de � Hay que basarla en protocolos seguros de comunicación como HTTPs (SSL) para evitar que nadie “escuche” la contraseña interpretando los paquetes HTTP.

� Más tedioso de programar

� Ventajas: No dependemos de la autentificación del entorno � Más portable.

Eje

mpl

o po

r pr

ogra

ma

Especificación

� En web.xmlweb.xml

� Una colección de recursos (URLs) solo podrán ser accedidos por usuarios que actúen bajo

autentificación por contenedor

usuarios que actúen bajo determinado rol usando determinados métodos HTTP

� La autenticación para cada ámbito de seguridad (realm) se hará usando alguna de las técnicasestablecidas por la especificación de servlets

Web.xml

� Colección de recursos, roles y métodos


Si no hay método todos están protegidos

Web.xml

� Roles


� Técnicas

Usuario y roles

� BDD de usuarios y roles� El contenedor consulta los datos de una fuente directamente

� Tipos de fuentes y configuración dependen de la implementación del


� Tipos de fuentes y configuración dependen de la implementación del contenedor� Base de datos (tablas: usuarios, roles)

� Ficheros XML

� Ficheros de propiedades

� . . .

� Consultar documentación del contenedor

Tipos de autenticación soportados

� BASIC

� DIGEST

� FORM


� CLIENT-CERT

Autentificación por Formulario

� No es segura por sí sola, es necesario combinarla con HTTPs (SSL – Secure Socket Layer)

� Permite controlar la apariencia de la pantalla

autentificación por contenedor > formulario

� Permite controlar la apariencia de la pantalla de login

� La pantalla de login es HTML estándar, sigue un convenio de nombres� Action: j_security_check

� Login: j_username

� Pass: j_password

Filtros Servlet HTTP

� Incorporados en la versión 2.3 de la especificación de servlets.

� Interceptan la invocación del servlet ANTES de que sea invocado el propio servlet.

autentificación por servlet > filtros

de que sea invocado el propio servlet.

� Permiten examinar y modificar la request antes de que le llegue al servlet.

� Permite modificar el response y redirigir, en caso necesario, la petición a otro recurso distinto.

� Ideales para el control de acceso de usuarios autentificados

Filtros, ventaja

� Permiten hacer autenticación por programa de forma transversal a la aplicación � el código de la aplicación no se modifica


aplicación no se modifica

� Lo habitual es redireccionar a formulario � necesario HTTPs� Sigue siendo autenticación por formulario

� A parte de autenticación permiten añadir de forma genérica “aspectos” a la aplicación

Filtros Servlet HTTP

� Interfaz javax.servlet.Filter

� Tres métodos:� void init(FilterConfig config) throws

ServletException Invocado antes de que el filtro


ServletException Invocado antes de que el filtro entre en servicio. Permite configurar el filtro.

� void destroy() Invocado cuando el filtro dejar de estar en servicio.

� void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throwsIOException, ServletException: Método que implementará el filtrado.

Interfaz filter y ciclo de vida


Procesamiento típico en un filtro

― Examinar las cabeceras de request

― [Si procede]Preprocesar la petición

― Invocar al resto de la cadena de filtros

― [Si procede]Postprocesar la petición


� A la ida puede:� Responder él a la request y terminar proceso

� Abortar la ejecución � UnavailableException

� Redirigir a otra URL

� Añadir info a session, request o contexto

� A la vuelta puede:� Examinar la respuesta, modificarla

� Examinar las cabeceras añadidas

Ejemplo, redirección a loginautentificación por servlet > filtros

Ejemplo, redirección, web.xml

<url-pattern> o


<url-pattern> o<servlet-name>

Los filtros siempre se declaran antes que los servlets a los que se aplican.

El orden en el que se forma la cadena de filtros es el orden de la declaración de <filter-mapping> para cada recurso afectado

Struts interceptor

� Mismos conceptos que Servlet Filterspero incrustado en el Stack de interceptores de Struts2

� Ciclo de vida similar

autentificación por servlet > struts interceptor

� Ciclo de vida similar

� Recibe todo en ActionInvocation� Action, Stack, etc.

� InvocationContext: Session, request, etc.

Interceptores, esquema


API en ActionInvocation


Pasos para la creación de interceptores Struts


� Crear la clase interceptora� Hereda de AbstractInterceptor

� Implementa StrutStatics

� Para heredar constantes declaradas en el � Para heredar constantes declaradas en el interfaz

� Declarar el interceptor

� Añadirlo al Stack de interceptores

� Añadir global-result

En struts.xml

LoginInterceptor, ejemplo


struts.xml: declarar el interceptor y global-results

struts.xml: declarar la pila de interceptores

Resumen

09. autentificacion[1]

Documents