1. No category

Autenticaci´on y control de acceso
Seguridad en Redes de Ordenadores
Enrique Soriano
LS, GSYC
17 de febrero de 2015
(cc) 2015 Grupo de Sistemas y Comunicaciones.
Algunos derechos reservados. Este trabajo se entrega bajo la licencia Creative Commons Reconocimiento NoComercial - SinObraDerivada (by-nc-nd). Para obtener la licencia completa, v´
ease
http://creativecommons.org/licenses Tambi´
en puede solicitarse a Creative Commons, 559 Nathan Abbott Way,
Stanford, California 94305, USA.
T´erminos
• Identificaci´
on: Alguien dice ser un sujeto concreto.
• Autenticaci´
on: Alguien demuestra su identidad.
• Autorizaci´
on: Otorgamiento de privilegios a un sujeto para
realizar una operaci´
on de acceso sobre uno o varios objetos.
• Control de acceso: Permitir o denegar una operaci´
on de
acceso sobre un recurso en base a la autorizaci´on del sujeto.
Autenticaci´on
• Un programa se autentica ante el sistema a nombre de un
usuario y pasa a ejecutar a su nombre.
• ¿C´
omo te autenticas?
•
•
•
•
•
Algo que conoces.
Algo que tienes.
Algo que eres.
Algo que haces.
Donde est´as.
Contrase˜nas
• La forma m´
as com´
un y sencilla de autenticaci´on: el usuario
proporciona un secreto que s´
olo ´el y el sistema conocen.
• Riesgos:
•
•
•
•
Que vean nuestra contrase˜
na.
Que la adivinen.
Spoofing (suplantaci´
on).
Que se hagan con el almac´en de contrase˜
nas.
Contrase˜nas
Que vean nuestra contrase˜
na:
• No se deben compartir.
• No se deben apuntar en claro.
• No se debe usar la misma contrase˜
na para distintos servicios.
• Aplicaciones keyring : Password Safe (Windows), Keychain
(OSX), etc.
Contrase˜nas
Que adivinen nuestra contrase˜
na:
• Ataque de fuerza bruta.
• B´
usqueda inteligente.
• Ataque de diccionario online.
Ataque de fuerza bruta
Keyspace:
• Siendo S la longitud de la contrase˜
na y N el n´
umero de
s´ımbolos que se pueden usar en las contrase˜
nas.
Keyspace =
s
P
Ni
i=0
• Ejemplo: Contrase˜
nas de s´
olo min´
usculas y de 0 a 8 caracteres:
• Ejemplo: Con may´
usculas, min´
usculas, n´
umeros y s´ımbolos de
puntuaci´on, de 0 a 14 caracteres:
Ataque inteligente
Imagen (C) xato.net
Contrase˜nas
No usar passwords comunes:
Contrase˜nas
Contrase˜
nas de calidad:
• Nnemot´
ecnicos: TabletMipefaesstwa3 de “Mi pel´ıcula
favorita es star wars 3”
• Rimas: SEGURIDAD-0-calamidad@casa
• Repetici´
on: hey.h0.HEY.H0.6
Contrase˜nas
Distintas contrase˜
nas para distintos servicios:
• Se puede tener un m´
etodo para generar las contrase˜
nas para
distintos servicios.
• Por ejemplo, poner al principio el n´
umero de caracteres del
servicio o servidor:
• Amazon: A6m1--mej0r--SECRETO
• Msn: M3m1--mej0r--SECRETO
• Apple: A5m1--mej0r--SECRETO
Contrase˜nas
Medidas de protecci´on:
• No permitir contrase˜
nas vac´ıas en el sistema.
• Obligar a cambiar las contrase˜
nas por omisi´
on.
Ejemplo: routers adsl.
• Obligar a que tengan una longitud m´ınima (no menos de 8
caracteres).
• Obligar a que no sean palabras del diccionario: requerimos
puntos, n´
umeros, may´
usculas y min´
usculas, etc.
Contrase˜nas
Medidas de protecci´on:
• Pasamos crackers para validarlas.
Ejemplo: John the Ripper.
• Obligar a cambiar las contrase˜
nas peri´
odicamente.
• No permitir reusar contrase˜
nas antiguas.
• No es buena idea generar contrase˜
nas aleatorias para los
usuarios → las apuntan. Si son aleatorias, no deben ser
predecibles.
Contrase˜nas
Medidas de protecci´on:
• Limitar el n´
umero de intentos de autenticaci´
on.
• Aumentar el tiempo entre autenticaciones fallidas.
• Compromiso: seguridad vs. obstrucci´
on.
Contrase˜nas
M´as riesgos: que nos timen.
• Spoofing
• Keyloggers
• Ingenier´ıa social
• ...
Contrase˜nas
Spoofing:
• Un atacante reemplaza al sujeto ante el que nos
autenticamos, y nos roba la contrase˜
na.
• Seguramente no nos demos cuenta: el resultado de la
autenticaci´on parece un error al escribir la contrase˜
na, pero no
lo es.
• Ataque cl´
asico: reemplazar /bin/login
• En el WWW: te conectas a una p´
agina que no es la que crees
(p. ej. te enga˜
nan con phishing ).
Contrase˜nas
Medidas de protecci´on:
• Imprimir el n´
umero de intentos reales que se llevan.
• Trusted Path: estar seguros de que el usuario se comunica con
el sistema operativo y no con un programa falso.
• Doble autenticaci´
on: el programa de login se autentica ante el
usuario antes de que el usuario se identifique y autentique.
Contrase˜nas
Keyloggers:
• Software: un programa captura todo lo que tecleamos.
• Hardware: esp´ıa el cable del teclado o la transmisi´
on
inal´ambrica de ratones/teclados. Aprox. 50 Euros, 2Gb. Los
hay WiFi.
Contrase˜nas
Medidas de protecci´on:
• Para PIN: mostrar una tabla por pantalla con una sustituci´
on
de los n´
umeros por caracteres, distinta en cada autenticaci´on.
• Usar el rat´
on para introducir la contrase˜
na.
• ... pero tambi´
en nos pueden enga˜
nar con hardware (150
Euros, 2 Gb de screenshots).
Contrase˜nas
Moraleja:
• The Big Stick Principle.
Contrase˜nas
Si se hacen con el almac´en de contrase˜
nas:
• Las contrase˜
nas se suelen guardar cifradas.
• Por lo general, se guarda un hash de la contrase˜
na.
• Ataque de diccionario offline: mucho m´
as efectivo que online.
Contrase˜nas
Ataque de diccionario offline:
• Buscar la hash que se quiere romper en una tabla precalculada
de tuplas (contrase˜
na, hash) → cambias tiempo de
computaci´on por espacio.
• Rainbow-tables (p. ej. ophcrack).
• Uso de Google para encontrar la hash. ¿Qu´
e contrase˜
na tiene
esta hash SHA-1?
99800b85d3383e3a2fb45eb7d0066a4879a9dad0
¡B´
uscalo en Google!
Rainbow Tables
Compromiso espacio/c´
omputo:
Contrase˜nas
Medidas de protecci´on:
• Contrase˜
nas largas.
• Hashes con salt.
• key strengthening : salt secreta.
Caso: autenticaci´on cl´asica en Unix
Pasos de arranque:
1. Scripts de arranque (init).
2. /bin/getty
3. /bin/login
Caso: credenciales en Unix
Un proceso tiene credenciales 1 :
• PID: identificador de proceso.
• UID: identificador de usuario.
• GID: identificador de grupo.
• EUID: identificador de usuario efectivo, el que se usa para
comprobar privilegios.
• EGID: identificador de grupo efectivo, el que se usa para
comprobar privilegios.
• ...
1
Dependen del “sabor” de UNIX
Caso: autenticaci´on b´asica en Unix
/etc/passwd:
• Login.
• Contrase˜
na (“x” cuando tenemos shadow )
• UID.
• GID.
• Gecos info: datos sobre el usuario, separados por comas.
• Path del home.
• Programa de inicio.
Caso: autenticaci´on b´asica en Unix
/etc/shadow:
• Login.
• Hash: son tres campos separados por $.
• Algoritmo: p. ej. 1 es MD6, 6 es SHA-512.
• Salt
• Hash
NOTA: Si tiene un valor que no se corresponde con una posible salida de crypt,
el usuario no se podr´
a autenticar con contrase˜
na (pero s´ı de otras formas). Por
ejemplo, se pone ∗ o ! para evitar que el usuario entre con contrase˜
na. Si
est´
a vac´ıo, el usuario no tiene contrase˜
na (no es recomendable). En Linux
recientes, la contrase˜
na de root es !.
Caso: autenticaci´on b´asica en Unix
/etc/shadow (contin´
ua):
• Fecha Unix del u
´ltimo cambio de contrase˜
na.
• M´ınima edad: m´ınimo n´
umero de d´ıas para permitir un
cambio de contrase˜
na.
• M´
axima edad: d´ıas tras los que tiene que cambiar la
contrase˜
na.
• D´ıas, antes de la caducidad seg´
un el campo anterior, para
avisar al usuario.
• D´ıas de pr´
orroga desde que caduca, cuando pasan se anula la
contrase˜
na.
Caso: autenticaci´on b´asica en Unix
/etc/shadow (contin´
ua):
• Fecha Unix de caducidad para la cuenta. Si llega, se cancela la
cuenta. No es lo mismo que la edad de la contrase˜
na, esta es
m´as dura.
• Campo reservado para uso futuro.
Caso: control de credenciales en Unix
• /bin/id: Permite ver tu UID y GID.
• /bin/su: Permite ejecutar un shell con otro UID. Por
omisi´on, intenta ejecutar un shell con UID 0.
• /usr/bin/sudo: Permite ejecutar un comando con otro UID,
proporcionando tu propia contrase˜
na. El fichero
/etc/sudoers especifica qui´en puede convertirse en qui´en, y
para qu´e.
Caso: control de credenciales en Unix
Ejemplo de sudoers (I):
jose ALL = (root, bin : operator, system) ALL
• jose puede, en cualquier m´
aquina
• adquirir el UID de root y bin
• adquirir el GID de operator y system
• para ejecutar cualquier comando
Caso: control de credenciales en Unix
Ejemplo de sudoers (II):
ramon mono = NOPASSWD: /bin/kill, PASSWD: /bin/ls,
/usr/bin/lprm
• ramon puede, en la m´
aquina mono
• adquirir el UID de root
• para ejecutar kill sin proporcionar contrase˜
na
• para ejecutar ls y lprm proporcionando contrase˜
na
Caso: autenticaci´on en Windows
• Windows almacena las contrase˜
nas en SAM:
\windows\system32\config\sam
• El fichero est´
a bloqueado en todo momento.
• Puede contener dos tipos de contrase˜
nas cifradas:
• LM (Lan Manager). ¡Inseguro! Windows 7 no la usa por
omisi´
on (pero se puede configurar para que las use, ojo).
• NTLM (NT Lan Manager): No tan seguro como deber´ıa.
Caso: autenticaci´on en Windows
En un terminal (cmd.exe )como administrador:
Caso: autenticaci´on en Windows
Contrase˜
nas LM (Lan Manager):
• Convierte todos los caracteres de la contrase˜
na a may´
usculas.
• Rellena con 0s la contrase˜
na hasta llegar a los 14 caracteres.
• Parte la contrase˜
na en dos bloques de 7 bytes.
• Usa los dos bloques como claves para cifrar con DES para un
bloque de datos conocido: 0x4b47532140232425
• Concatena el resultado de los dos cifrados DES.
¡NO pod´ıan haber metido m´as la pata!
Caso: autenticaci´on en Windows
Contrase˜
nas LM (Lan Manager):
VS
Caso: autenticaci´on en Windows
Contrase˜
nas NTLM (NT Lan Manager):
• Usa una hash MD4 de 128 bits, que era segura en 1991:
• Ataque de colisi´
on en microsegundos.
• Ataque de pre-imagen te´
orico.
• Diferencia entre may´
usculas y min´
usculas.
• No usa salt.
Caso: autenticaci´on en Windows
Syskey:
• A˜
nade una capa extra de seguridad cifrando el almac´en de
claves de SAM.
• Opci´
on I (activada por omisi´
on):
• Usa una clave generada para cada sistema y que est´
a oculta en
el Registro.
• Viola el principio de Kerckhoffs: no sirve de nada.
• bkhive la encuentra, samdump2 descifra el archivo de SAM.
• Opci´
on II:Generar la clave a partir de una contrase˜
na adicional
que se introduce en el arranque.
• Opci´
on III: Almacenar la clave en un disco extra´ıble.
Caso: autenticaci´on en Windows
Ophcrack rompe contrase˜
nas d´ebiles de Windows NT (hashes
MD4) con rainbow tables:
Caso: control de credenciales en Windows
En Windows es com´
un usar una cuenta de administrador. User
Account Control (UAC) permite controlar los privilegios:
• Un administrador tiene un token de usuario y token de
administrador.
• Idea: evitar el uso del token de administrador para operaciones
que no lo requieren.
• Cuando se intenta usar el de administrador (elevaci´
on) se
presenta una ventana de di´alogo UAC para pedir permiso o
credenciales.
Caso: control de credenciales en Windows
Los di´alogos de elevaci´
on usan un c´
odigo de colores:
• Rojo (con escudo) si el firmante de la aplicaci´
on
est´a bloqueado, es una aplicaci´
on sin firma bajada de Internet.
• Azul (con escudo) si es una aplicaci´
on administrativa de
Windows (p.ej. Panel de Control).
• Azul (con interrogaci´
on) si la aplicaci´
on est´a firmada por
terceros con Authenticode y se puede verificar.
• Amarillo (con escudo) si la aplicaci´
on no est´a firmada o
est´a firmada pero no se puede verificar.
Caso: control de credenciales en Windows
Caso: control de credenciales en Windows
UAC niveles
• S´
olo el nivel m´as alto impide autoelevaci´
on silenciosa.
• Los niveles m´
as bajos no usan el escritorio seguro.
Caso: control de credenciales en Windows
Ventajas de UAC:
• No hay que usar dos cuentas (usuario y administrador).
• No hay que entender para qu´
e hay que usar la cuenta de
administrador y para qu´e la otra.
• No hay que gestionar dos perfiles distintos (carpetas,
escritorios, etc.).
• Aplica el principio de m´ınimo privilegio.
Inconvenientes: No ha sido bien recibido por ser molesto ¿El
problema es la interfaz?
Algo que eres
Nuestro cuerpo nos puede autenticar (biometr´ıa):
• Escaner de iris.
• Escaner de retina.
• Huellas dactilares.
• Palma de la mano.
• Reconocimiento de voz.
• Reconocimiento facial.
Algo que eres
• Aumenta el riesgo para la integridad f´ısica del usuario.
• Son m´
as propensos a fallar:
• Falso positivo: autenticaci´
on err´
onea.
• Falso negativo: aumenta la obstrucci´
on.
• ¿C´
omo se revoca una huella dactilar o una cara?
Algo que tienes
• Tu SmartPhone: Google Authenticator.
• SecureID
• Smart Cards
• RFID / NFC
• USB tokens
• Fortezza
• ...
Algo que tienes
Los dispositivos de autenticaci´
on:
• Pueden disminuir la obstrucci´
on, como NFC.
• Pueden aumentar la obstrucci´
on, como SecureID.
• Hay que fiarse del HW lector: igual que con las contrase˜
nas,
puede existir spoofing.
• Nuevo riesgo: puedes perder el objeto, o te lo pueden robar.
• Si lo piensas, corremos los mismos riesgos a diario con las
llaves de nuestra casa o las tarjetas de cr´edito.
DNIe
Por ejemplo, el DNI electr´
onico (DNIe):
• Se usa para cualquier tipo de tramitaci´
on telem´atica con el
estado.
• Tiene la misma validez que el DNI normal.
DNIe
El DNI electr´onico (DNIe) es una SmartCard tamper-resistant con
los siguientes ficheros dentro:
•
•
•
•
•
•
•
Datos de filiaci´
on del titular
Imagen digitalizada de la fotograf´ıa.
Imagen digitalizada de la firma manuscrita.
Plantilla de la impresi´
on dactilar de los dedos ´ındice de cada mano.
Certificado X.509 para autenticaci´
on, y la clave privada correspondiente.
Certificado X.509 para firma, y la clave privada correspondiente.
Certificado X.509 de la autoridad emisora.
La generaci´
on de claves, el cifrado/descifrado, la firma, etc. se realiza en el chip de la
tarjeta.
DNIe
• Se entrega junto con un PIN (sic) (es una contrase˜na con 8-16 caracteres): algo
que tienes + algo que sabes.
• Se puede cambiar la contrase˜na desde cualquier PC si sabemos la contrase˜na
viejo.
• Se puede reestablecer la contrase˜na (sin conocer el viejo) en un terminal especial
(Punto de Actualizaci´
on del DNIe). Es necesario proporcionar la huella dactilar
(la verificaci´
on se hace en el propio chip): algo que tienes + algo que eres.
Otras formas
• Algo que haces: por ejemplo, gestos ante una c´
amara, en un
touchpad, etc.
• D´
onde est´as: el simple hecho de encontrarte en una
localizaci´on f´ısica (p.ej., la sala de los servidores) te autentica.
Single Sign-On
• Una u
´nica autenticaci´
on para usar varios servicios distintos.
• ¿Tendremos Single Sign-On para todos los servicios?
Combinaci´on de m´etodos de autenticaci´on
SUN’s PAM (Pluggable Authentication Modules):
• Objetivos:
• Combinar distintos m´
etodos de autenticaci´
on proporcionados
por distintos m´
odulos independientes.
• Usar distintos m´
etodos de autenticaci´
on sin modificar el c´odigo
de las aplicaciones.
• Modificar la autenticaci´
on sin parar el sistema.
• PAM est´
a disponible para distintos sabores de Unix.
Linux-PAM
Seis primitivas englobadas en cuatro grupos:
• Auth: tareas para autenticar al usuario.
• Account: tareas de gesti´
on de los datos de una cuenta.
• Password: tareas para administrar los mecanismos de la
autenticaci´on.
• Session: tareas a realizar al crear y destruir sesiones.
Linux-PAM
Auth:
• pam authenticate: sirve para autenticar al sujeto.
• pam setcred: sirve para establecer y gestionar las
credenciales. Tiene que llamarse despu´es de
pam authenticate y antes de establecer la sesi´on.
Linux-PAM
Session:
• pam open session: realiza las tareas asociadas con el inicio
de sesi´on. Por ejemplo, actualizar logs de entrada, etc.
• pam close session: se encarga de las tareas asociadas con el
fin de sesi´on. Por ejemplo, actualizar logs de salida, etc.
Linux-PAM
Account:
• pam acct mgmt: verifica si la cuenta est´
a en buenas
condiciones. Por ejemplo si la contrase˜
na caduc´o, si la cuenta
est´a cancelada, etc.
Linux-PAM
Password:
• pam chauthtok: cambia el objeto de la autenticaci´
on (p.ej.,
la contrase˜
na), posiblemente comprobando que es
suficientemente bueno, etc.
Linux-PAM
• En /etc/pam.d/ se crean ficheros con las pol´ıticas para los
distintos servicios.
• Un fichero de pol´ıticas define una pila de reglas que determina
el ´exito de una operaci´
on:
type control module-path module-arguments
•
•
•
•
type: grupo (auth, account, password, session).
control: c´
omo afecta al resultado de la operaci´on.
module-path: m´
odulo.
module-arguments: argumentos.
Linux-PAM
Control:
• requisite: si la operaci´
on retorna error, se acaba la autenticaci´on
con fallo.
• required: si retorna error, el flujo continua aunque el resultado
final ya est´a decidido: ser´a un fallo.
• sufficient: si retorna ´exito, termina inmediatamente la con ´exito.
Si retornar error, se sigue llamando al resto (y si el resto funcionan,
la operaci´
on acaba con ´exito).
• optional se ejecuta, pero lo que retorne (´exito o fallo) no se tiene
en cuenta.
Linux-PAM: ejemplo
Aplica un retardo, da igual
lo que devuelva.
Si existe el fichero
/etc/nologin
sólo root puede
autenticarse en la máquina
Comprueba que el
contexto anterior se ha
limpiado
Se leen las variables de
entorno y las variables del
fichero
/etc/default/locale
Se aplican todas las reglas
del fichero de PAM
common-auth
(normalmente pedir
password, comprobar
hash)
Aplica las reglas de esos
tres ficheros de PAM
Imprime si el usuario tiene
correo.
Imprime el MOTD
(Message of the day)
Imprime la fecha del último
login.
Establece los límites del
usuario según
/etc/security/group.conf
Aplica filtros de
/etc/security/group.conf
para añadir al usuario a
grupos dependiendo de
factores como la hora, TTY,
etc.
Autenticaci´
on en sistemas distribuidos
Sistemas distribuidos: riesgos
Los riesgos a los que se expone el sistema:
• Espionaje de los mensajes que viajan por la red. No se puede
detectar desde los extremos.
• Eliminaci´
on, modificaci´
on, e inserci´
on de mensajes
transmitidos. Este ataque es activo, y se puede detectar.
• Repetici´
on de mensajes antiguos. Tambi´en es activo.
Challenge-Response
• Objetivo: que las contrase˜
nas no viajen por la red.
• El servidor env´ıa un reto.
• El cliente responde el reto.
• ¡Los retos no se deben repetir!
Challenge-Response
CRAM-MD5:
1. C ← S : nonce
2. C calcula r = HMACMD5(nonce, pass)
3. C → S : r,login
4. S comprueba si r = HMACMD5(nonce, pass)
Challenge-Response: ejemplo de relay attack
1. M ← S : nonce
2. C ← M : nonce
3. C calcula r = HMACMD5(nonce, pass)
4. C → M : r,login
5. M → S : r,login
6. S comprueba si r = HMACMD5(nonce, pass)
Protocolo ejemplo I
1. C crea m = “soy C”
2. C crea m0 = Ek (m, S)
3. C → S : m, m0
4. S verifica si m haciendo Dk (m0 )
Protocolo ejemplo I: replay attack
1. M recupera m0 = Ek (m, S) viejo
2. M → S : m, m0
3. S verifica si m haciendo Dk (m0 )
soluci´on: timestamps y nonces
Protocolo ejemplo II
1. C → S : “soy C”
2. C ← S : nonce
3. C crea m = Ek (nonce, C , S)
4. C → S : m
5. S verifica que Ek (nonce, C , S) == m
Protocolo ejemplo III
Versi´on con algoritmo asim´etrico:
1. C → S : “soy C”
2. C ← S : nonce
3. C crea m = EKCpri (nonce, C , S)
4. C → S : m
5. C → S : Certc
6. S verifica el Certc con la CA
7. S verifica que DKCpub (m) == (nonce, C , S)
Needham-Schroeder
• Se basa en un servidor de autenticaci´
on (A) que comparte
secretos con todos los clientes y servidores.
• Las claves se centralizan en A.
• Establece una clave para la sesi´
on: Kcs
Needham-Schroeder
1. C → A : C , S, Na
2. A crea m = EKc (Na , S, Kcs , EKs (Kcs , C ))
3. C ← A : m
4. C consigue Na y Kcs haciendo DKc (m)
5. C verifica Na
6. C → S : EKs (Kcs , C )
7. S consigue Kcs haciendo DKs (EKs (Kcs , C ))
8. C ← S : EKcs (Nb )
9. C → S : EKcs (Nb − 1)
10. S verifica DKcs (Nb − 1) == Nb − 1
Needham-Schroeder
Problema: si una clave de sesi´
on vieja Kcs queda comprometida, el
atacante puede reiniciar la sesi´
on antigua.
1. M recupera EKs (Kcs , C ) viejo.
2. M → S : EKs (Kcs , C )
3. S consigue Kcs haciendo DKs (EKs (Kcs , C ))
4. M ← S : EKcs (Nb )
5. M consigue Nb .
6. C → S : EKcs (Nb − 1)
7. S verifica DKcs (Nb − 1) == Nb − 1
Soluci´on: usar timestamps y tiempos de validez.
Kerberos
Est´a basado en Needham-Schroeder. Usa dos servicios centrales
(pueden ejecutar en el mismo nodo):
• KDC (Key Ditribution Center): autentica al cliente.
• TGS (Ticket Granting Service): proporciona tickets para
acceder a los servicios.
Kerberos
Fase 1
Fase 2
KDC
TGS
TICKET?
TGT?
TGT
TICKET
TICKET+AUTHENTICATOR
AUTHENTICATOR
C
S
Kerberos
Elementos:
• Ln : tiempo de vida.
• Tn : timestamp.
• Nn : nonce.
Fase 1: Conseguir un Ticket-granting ticket (TGT):
1. C → KDC : C , TGS, L1 , N1
2. KDC genera Ticketc,tgs = EKtgs (Kc,tgs , C , T1 , L1 )
3. C ← KDC : EKc (TGS, Kc,tgs , Ticketc,tgs , L1 , N1 )
Kerberos
Fase 2: Conseguir un ticket para el servicio:
1. C genera Authenticators,tgs = EKc,tgs (C , T3 )
2. C → TGS : C , S, L2 , N2 , Ticketc,tgs , Authenticators,tgs
3. TGS genera Ticketcs = EKs (Kcs , C , T2 , L2 )
4. C ← TGS : EKc,tgs (S, Kcs , Ticketcs , L2 , N2 )
5. C genera Authenticatorc = EKcs (C , T4 )
6. C → S : Authenticatorc , Ticketcs
7. S genera Authenticators = EKcs (T4 )
8. C ← S : Authenticators
Plan 9 auth
• Tambi´
en est´a basado en Needham-Schroeder.
• Organizado en dominios de autenticaci´
on.
• El servidor impone el dominio para realizar la autenticaci´
on.
• Permite a un usuario hablar en nombre de otro usuario: UIDr
es el UID del proceso en el cliente; UIDc es el UID del sistema
cliente; puede que UIDr 6= UIDc , en ese caso, UIDc habla en
nombre de UIDr .
Plan 9 auth
1. C → S : N1
2. C ← S : N2 , UIDs , Dom
3. C → A : N2 , UIDs , Dom, UIDc , UIDr
4. A genera Ticketsc = EKs (N2 , UIDr , UIDc , Kcs )
5. C ← A : Ticketsc , EKc (N2 , UIDr , UIDc , Kcs )
6. C incrementa CTR
7. C genera Authenticatorc = EKcs (N2 , CTR)
8. C → S : Ticketsc , Authenticatorc
9. S genera Authenticators = EKcs (N1 , CTR)
10. C ← S : Authenticators
Autenticaci´on en el WWW
Com´
unmente:
1. Se establece un canal TLS con el servidor.
2. El cliente se autentica con login y contrase˜
na.
3. Se instalan cookies en el cliente.
4. El cliente presenta una cookie en posteriores peticiones de
esta sesi´on.
Autenticaci´on en el WWW
Algunos atributos de las cookies relacionados con la seguridad:
• Domain: s´
olo se puede usar para ese dominio.
• Path: s´
olo se puede usar para esa ruta en la URL.
• Expires: fecha de caducidad.
• Secure: s´
olo para usar con HTTPS.
• HttpOnly: no accesibles para scripts.
Autenticaci´on en el WWW
Riesgos comunes:
• Mallory puede reemplazar las cookies si se hace pasar por el
servidor .
• Session hijacking : Mallory se hace con la cookie (nos roba la
sesi´on). P. ej. cuando se mezcla HTTPS con HTTP (¡muy
mala idea!) hay riesgo de enviar cookies delicadas en claro.
• Session fixation: Mallory nos induce a crear una sesi´
on con un
ID determinado (por tanto, puede continuar con la sesi´on). P.
ej. phising, pinchamos en el link.
Autenticaci´on en el WWW
Riesgos comunes:
• Cookie poisoning : Mallory forja sus propias cookies para
autenticarse como otro usuario.
• Cross-site scripting (XSS): Mallory introduce scripts
maliciosos en las p´aginas que visitas (de una tercera parte)
que ejecutan como si fuesen leg´ıtimos.
• Ojo: los scripts maliciosos se pueden injectar en caches
intermedias, en la cache del navegador, lo puede hacer el
propio navegador, etc.
Autenticaci´on en el WWW
Open ID:
• Prop´
osito: autenticaci´
on federada para el WWW.
• Idea: usas un servidor de Open ID para autenticarte ante una
aplicaci´on web de un tercero sin darle tu contrase˜
na.
• Proveedores de Open ID: Google, Facebook, Yahoo!,
Microsoft, AOL, MySpace.
• No confundir con OAuth.
• Riesgo: phising, se presenta una p´
agina exactamente igual que
la del proveedor de Open ID, pero que no es del proveedor.
Autorizaci´on en el WWW
c Justen Stepka
Imagen Control de acceso
Control de acceso
• Acceso: un sujeto activo que intenta interactuar con un objeto
pasivo realizando una operaci´
on de acceso.
• El sistema permite/deniega en base a:
• Lo que le est´
a permitido hacer al sujeto.
• Lo que est´
a permitido hacerle al objeto.
• Errores en el dise˜
no o la implementaci´
on pueden permitir
realizar operaciones no autorizadas.
Ejemplo: side-channel de Dropbox.
Operaciones de acceso
Ejemplos:
• A˜
nadir
• Leer
• Escribir
• Ejecutar
• Borrar
• Cambiar permisos
• Cambiar due˜
no
• Listar
• Buscar/atravesar
Pertenencia
El control de acceso puede ser
• Discrecional (Discretionary Access Control o DAC): el
usuario posee objetos y autoriza al resto para acceder a ellos.
• Obligatorio (Mandatory Access Control o MAC): los usuarios
no gestionan el acceso a los objetos.
Mandatory Access Control
• Entornos muy restrictivos (p.ej., militares).
• Sistemas de Seguridad Multinivel (MLS):
• Usuarios con rango.
• Objetos con nivel de seguridad.
• Compartimentos.
• Centrados en la confidencialidad (modelo Bell-LaPaluda):
• Puedes generar documentos de tu nivel o de m´
as alto nivel.
• Puedes observar documentos de tu nivel o de m´
as bajo nivel.
• Centrados en la integridad (modelo BIBA):
• Puedes modificar documentos de tu nivel o de m´
as bajo nivel.
Mandatory Access Control
Ejemplo: Mandatory Integrity Control (MIC) en Windows 7 aplica
MAC BIBA antes de aplicar el control de acceso discrecional:
Cuatro niveles:
• Bajo (no confiable). Los ejecutables pueden ser marcados como nivel bajo si son
peligrosos (p.ej. bajados de Intenet y no firmados). S´
olo pueden modificar
carpetas temporales, etc.
• Medio (usuario). Los usuarios normales y los objetos que no tienen etiqueta de
integridad tienen este nivel.
• Alto (administrativo). Los administradores tiene este nivel, la carpeta de
Archivos de Programa, etc.
• Sistema (control total). Los servicios del sistema tienen este nivel.
IBAC
IBAC: Control de acceso basado en la identidad.
• Access Control Matrix: filas: usuarios, columnas: objetos.
esoriano
paurea
nemo
sdemingo
list.c
r,w
r
r
-
a.doc
r
r
r,w
-
word.exe
w,x
r,w,x
IBAC
• Access Control List: una columna de la matriz.
list.c
esoriano
paurea
nemo
sdemingo
r,w
r
r
-
Caso: UNIX
Permisos POSIX:
• Permisos rwx para due˜
no, grupo, y resto.
• Los grupos se especifican en /etc/groups.
• chmod cambia los permisos.
• chown cambia el due˜
no de un fichero. S´
olo puede hacerlo root.
Caso: UNIX
Permisos POSIX:
• chgrp cambia el grupo de un fichero. Lo puede hacer el due˜
no
del fichero (tiene que pertenecer al grupo al que se cambia).
• sticky bit (+t) en directorios: restringe la eliminaci´
on de
entradas de directorio aunque el directorio tenga permisos de
escritura para todo el mundo: s´
olo puede borrar/renombrar el
due˜
no y root. P. ej. /tmp
Caso: ACLs en Mac OS X
Ejemplo de ACLs, Mac OS X:
• Conviven con los permisos UNIX. Nota: Linux (ext3) tambi´
en
tiene ACL extendidas, pero no son iguales (man acl).
• La ACL extendida es una lista ordenada de ACEs (Access
Control Entry).
• Se pueden listar las ACLs extendidas con ls -le
Caso: ACLs en Mac OS X
• La ACL extendida es una lista de ACE (Access Control Entry).
• Una ACE se compone de:
• ¿Qui´
en?: usuario o grupo.
• Permiso: Allow o Deny.
• Acci´
on de acceso sobre el objeto.
• Un usuario tiene acceso a un recurso si alguna ACE Allow o
los permisos UNIX se lo permiten, excepto si alguna ACE
Deny se lo impide → Los Deny mandan.
• Es m´
as f´acil controlar el acceso determinando los permisos de
los contenedores (directorios) y que los ficheros los hereden.
Caso: ACLs en Mac OS X
• Acciones de acceso:
delete, readattr, writeattr, writeextattr, readsecurity, writesecurity,
chown.
• Directorios:
list, search, add file, add subdirectory, delete child.
• Ficheros:
read, write, append, execute.
• Herencia (para directorios):
file inherit, directory inherit, limit inherit, only inherit.
Ejemplo:
chmod +a ‘‘group:wheel deny delete,file inherit,directory inherit’’ dir1
Caso: ACLs en Windows 7
Dos tipos:
• DACL (Discretionary ACL): lista de ACEs que permiten o
deniegan un tipo de acceso para una cuenta o grupo.
• SACL (System ACL): usada para auditar, es una lista de ACEs
que indican el tipo de acci´
on que provocar´a una entrada en el
Security Event Log.
RBAC
RBAC: Control de acceso basado en roles.
• Rol: colecci´
on con nombre de permisos.
• Se asignan roles a los sujetos/grupos del sistema. Un usuario
puede tener m´as de un rol. Los roles pueden ser din´amicos.
• Un grupo organiza identidades, un rol organiza permisos.
• Puede haber una jerarqu´ıa de roles.
• Es u
´til para implementar la separaci´
on de deberes.
• Escalabilidad: los usuarios del mismo tipo suelen tener los
mismos privilegios.
• C´
omodo: los usuarios cambian m´as que los privilegios que
tienen las distintos clases de usuarios.
Capabilities
Control de acceso basado en capablities:
• El sujeto presenta un capability junto con su petici´
on para
realizar una operaci´
on de acceso.
• La capability puede ser un certificado firmado, un ticket, una
secuencia pseudo-aleatoria, etc.
• Facilita la delegaci´
on de privilegios y la escalabilidad.
• Dificulta la revocaci´
on de privilegios y la auditor´ıa (qui´en
puede hacer qu´e en un momento dado).
Autorizaci´on en el WWW: OAuth
OAuth :
• Prop´
osito: autorizaci´
on para usar APIs de terceros sin dar las
credenciales.
• El usuario permite a un tercero acceder a ciertas operaciones
del API de un servicio web, sin darle tu contrase˜
na.
• Usa timestamps, nonces y firmas digitales.
• Ejemplos: Twitter, YouTube.
Autorizaci´on en el WWW: OAuth
c Google
Imagen ABAC
Control de acceso basado en atributos:
• Un atributo del sujeto le autoriza a acceder a un recurso.
• Por ejemplo: edad, nacionalidad, etc.