10 episodios

Seguridad, sistemas y Python.

Podcast Z Jesús Cea & Pablo Lobariñas

    • Tecnología
    • 4,5 • 2 valoraciones

Seguridad, sistemas y Python.

    Podcast Z #10: Persona

    Podcast Z #10: Persona

    Autenticación web global y abierta. Descentralizada y privada https://podcast.jcea.es/podcastz/10
    Notas:



    00:40: Persona es la alternativa Mozilla a "Single Sign On" propietarios.

    01:40: Manejar la complejidad de mantener claves diferentes en varios sitios.

    02:50: ¿Qué es Persona?: Privacidad, descentralizado, no depender de un proveedor.

    07:10: El problema del huevo y la gallina. Ahora mismo Persona es muy centralizado, riesgo de hacking y
    dependencia de Mozilla.

    08:50: ¿Cómo funciona? Se certifica la propiedad del un correo electrónico.

    10:30: ¿Qué pinta el correo en todo esto?

    13:00: Cuando tu proveedor de correo no es un proveedor de identidad de Persona, entonces la certificación
    se centraliza en Mozilla.

    14:30: Persona es un protocolo descentralizado que ahora mismo depende de Mozilla. A medida que el protocolo
    tenga éxito, se irá haciendo más y más descentralizado.

    16:10: ¿Cómo gestiona tu identidad tu proveedor de identidad?

    19:00: ¿Cómo funciona a nivel técnico?. El workflow.

    23:50: Privacidad respecto a tu proveedor de identidad. Tu proveedor de identidad no sabe qué webs visitas.

    25:00: ¿Cómo valida tu identidad el verificador?

    28:30: Te autentifico sin que ni siquiera tengas una cuenta en mi servicio. Por ejemplo, un blog o un foro.
    No necesito darme de alta.

    32:30: Persona hace posible que no tengas que almacenar claves en el servidor. Podrías no tener, siquiera,
    una base de datos de usuarios.

    33:30: Pegas de Persona: Hay pocos proveedores de identidad, así que el sistema se acaba centralizando en Mozilla.

    34:30: Descripción técnica del "fallback" a Mozilla.

    36:00: Mientras Persona no triunfe, se depende de Mozilla.

    38:00: Mozilla permite autentificarte en Persona con autenticaciones OAuth: por ejemplo, Facebook, Google, Yahoo,
    Twitter, etc. Esto permite no tener una clave adicional, y te proporciona privacidad respecto a tu proveedor de Identidad.
    Y mantiene la identidad para el usuario.

    42:00: Correlación entre logins y accesos Persona. ¿No se puede identificar a los usuarios?.
    Se puede evitar cacheando claves públicas de los proveedores de identidad (y con refrescos proactivos), o usando a Mozilla
    de intermediario.

    45:00: ¿Podría otro proveedor ser un proveedor de identidad secundario?. No, aunque el protocolo
    permite delegaciones. Varios dominios pueden delegar su autenticación en otro servidor. Útil para empresas con varios dominios,
    pero bajo el mismo control administrativo.

    48:30: ¡Pero es que no quiero depender de Mozilla!. No se puede. Se siente. La única solución es que Persona
    se popularice, haya más proveedores de identidad y depender menos de Mozilla. A medida que el protocolo se populariza,
    el peso de Mozilla baja. Al contrario que los demás sistemas SSO (Single Sign On).

    51:00: Pero a Google o a Facebook no les interesa ser proveedores de identidad, porque su negocio es
    precisamente conocer los hábitos de navegación de sus usuarios, porque se financian vendiendo esa información a las
    agencias publicitarias.

    52:30: Opinión personal sobre el futuro de Persona.

    56:50: ¿Qué tiene que hacer una página web para permitir que los usuarios accedan con Persona?.
    Es MUY fácil, y no requiere instalar nada en el servidor.

    59:00: La idea de Mozilla es que una versión futura de Firefox incluya soporte Persona nativo.
    Más rápido y más seguro. Para los navegadores que no incluyan la funcionalidad, usarán un javascript externo, como ahora mismo.

    01:00:00: Un desarrollador web solo necesita incluir un javascript que proporciona Mozilla. Si no quiere
    complicarse la vida, incluso puede delegar la verificación en Mozilla. Una implementación sencilla no requiere instalar NADA
    en el servidor.

    01:03:30: Mozilla se ha preocupado mucho de que el usuario, el proveedor de identidad y el verificador
    trabajen lo menos posible. Que tengan que hacer lo mínimo posible. Que la barrera de entrada sea muy baja.

    01:05:10: Recapitulación de Pablo: facil

    • 1h 19 min
    Podcast Z #9: Contraseñas

    Podcast Z #9: Contraseñas

    Contraseñas... ¿Podemos vivir sin ellas? https://podcast.jcea.es/podcastz/9
    Notas:



    00:00: Las claves están por todas partes.

    01:20: Definición y políticas.

    02:15: Una clave memorizable, es una clave insegura. ¡¡Escríbelas!!. ¿O no?

    07:00: ¿Qué problema tiene utilizar claves?

    10:00: Estudios sobre la calidad de las claves.


    Real-World Passwords

    The science of password selection


    15:00: Mecanismos de generación segura de claves.

    18:20: Gestores de claves.

    19:20: Biometría.

    20:20: DNI Electrónico.

    21:20: Doble autentificación.

    25:30: Conclusiones.

    • 27 min
    Podcast Z #8: Proyecto X - Batiburrillo Final

    Podcast Z #8: Proyecto X - Batiburrillo Final

    Últimos flecos del proyecto https://podcast.jcea.es/podcastz/8
    Notas:



    01:00: No enseño código porque es código propietario y porque por audio es difícil
    enseñar código. Estoy dispuesto a atender peticiones por correo electrónico para escribir
    entradas en la página web.

    02:00: Usar "sys.excepthook" en vez de rodear todo tu código con un "try...except".

    03:00: Uso "sys.excepthook" para que si el programa falla de forma catastrófica, envíe un
    informe al servidor, con todos los detalles posibles.

    04:30: Ventajas de usar "sys.excepthook" en vez de rodear todo con "try...except".

    07:50: Usamos multithreading para ofrecer al disco duro varias peticiones simultaneas, de
    forma que pueda planificar el movimiento del cabezal de forma óptima. Paralelizar la lectura de disco.

    12:10: Lanzar varias peticiones concurrentes tiene consecuencias para el usuario. La
    actividad de disco propia del usuario compite con el programa.

    14:30: El programa incluye un microservidor web. La interfaz de usuario es el propio
    navegador. Esto nos independiza del GUI propio de cada sistema operativo. Además, permitiría acceso remoto
    de forma automática, si fuera necesario. Ojo con la seguridad.

    18:30: Grabación de "checkpoints" del programa.

    21:30: En Windows no se puede hacer como en Unix:
    grabar con otro nombre+flush+sync+rename. Hay que buscarse la vida para hacer algo que funcione en todas
    las plataformas soportadas.

    25:00: Como ahora tengo dos ficheros de checkpoint, debo comprobar su integridad. La integridad
    verifica muchas cosas, tanto que el fichero está completo como datos sobre la versión del programa, etc.

    30:00: El programa se autoregistra y se le proporciona un código de registro único. Eso
    permite muchas cosas interesantes, además de identificar al usuario.
    Por ejemplo, poder ejecutar código de forma selectiva en determinados
    usuarios.

    37:50: Los logs se mandan a disco ANTES de mandarlos al servidor. Cuando el programa se
    ejecuta, manda los logs pendientes presentes en disco, si los hay. ¿Por qué?. Escucha el podcast :-)

    43:30: El programa descarga componentes externos de forma segura y eficiente.

    48:30: Problema: si cambia un componente externo, hay que emitir una versión nueva del código
    principal.

    50:30: Problema: cuando empieza un mes nuevo, distribuyo 32 Megabytes a 5000 usuarios. Eso
    son muchos Gigabytes. Y todos a la vez.

    55:00: Red CDN (Content Distribution Network) del pobre: Coral Caché -
    http://www.coralcdn.org/.

    55:30: Mi web es http://www.jcea.es/.
    Para entrar en mi web a través de Coral Caché,
    usaríamos la URL http://www.jcea.es.nyud.net/.

    58:30: No hace falta ningún trámite. Tampoco te garantizan nada, claro.

    59:30: En mi código tengo un "fallback": Primero intenta descargar a través de Coral,
    y si no funciona bien, va directamente a mi servidor. Esto es factible porque tengo control del cliente
    y el usuario no tiene que esperar nada.

    01:02:40: Mejoras posibles en la aplicación. Básicamente, usar cifrado en todas partes...
    o casi. Como controlamos el cliente, no es necesario que el certificado SSL esté firmado por una
    entidad de certificación reconocida. Así que no hay excusa.

    Una mejora que no se describe en el podcast es que el código descargado lleva una firma digital,
    pero un atacante podría inyectarnos una versión más antigua con, por ejemplo, problemas de seguridad
    conocidos. Sería interesante que el descargador no permitiese ejecutar una versión anterior a la
    última que haya descargado. Es decir, que no se pudiese volver nunca para atrás.

    01:08:00: Si metemos TODO cifrado, no podemos usar Coral Caché. La solución: las firmas van
    por Coral y se verifica esa descarga a través de un hash que hemos recibido por una conexión cifrada en
    paralelo.

    01:10:30: Mi intención con esta serie de podcasts es dar ideas a los programadores,
    para sus propios proyectos.

    01:12:00: No puedo enseñar código real, pero si hay alguien interesado, puedo dar detalles en

    • 1h 13 min
    Podcast Z #7: Proyecto X - Filtros BLOOM

    Podcast Z #7: Proyecto X - Filtros BLOOM

    Estructura para comprobar pertenencia a un conjunto, de forma probabilística. https://podcast.jcea.es/podcastz/7
    Notas:


    01:00: Filtros Bloom. Tecnología interesante y desconocida.

    01:30: El número de huellas ha ido creciendo, y la estructura de datos que usamos, "set()", tiene un coste
    en memoria proporcional al número de elementos. Estábamos usando 1.5GB en 32 bits, y 3GB en 64 bits.

    04:30: Las huellas eran 40 millones de números (y creciendo) de 32 bits. Son 150MB en disco, pero 1.5/3 gigabytes al
    cargarlos en un "set()".

    05:40: Idea simple para reducir los 1.5/3GB a 512MB: como trabajamos con números de 32bits, podemos tener una
    matriz de 232 bits y ponerlos a cero o a uno según ese valor esté en la lista o no. Esto son 512MB.

    07:15: Como tenemos una matriz de 232 bits, pero solo un 1% estará a UNO, los 512MB resultantes
    se pueden comprimir muy bien, típicamente al 11% (unos 55MB), aptos para ser transmitidos por Internet.

    08:40: La matriz así generada no tiene falsos positivos ni falsos negativos, pero como los datos de entrada son
    una lista de 32 bits, que es una "reducción" de la fuente real original, esa lista ya induce falsos positivos. Es decir,
    diferentes valores en el origen que generan el mismo número de 32 bits.

    10:10: Para el cliente, reducir el consumo de memoria a 512MB sigue siendo insuficiente. Su objetivo es llegar
    a ocupar solo 64-128MB. Lo consigo reducir a 32MB, usando un filtro Bloom.

    11:00: Si en vez de introducir falsos positivos en la reducción de 128bits a 32 bits, podemos utilizar los 128bits
    originales y usar una estructura de datos con falsos positivos, una estructura "probabilística".

    13:50: Explicación de cómo funciona un filtro Bloom
    y su tasa de falsos positivos.

    14:55: "Te lo voy a explicar a ti, a ver si explicándotelo me aclaro" :-).

    17:10: Explicando el concepto de "colisiones" y por qué son inevitables. Falsos positivos.

    23:00: Controlamos la tasa de falsos positivos añadiendo más o menos bits y controlando el número de bits puestos
    a UNO por cada valor original (y el número de bits que deben ser UNO para tener un "hit").

    25:30: Ahora en cada búsqueda tenemos un 2% de falsos positivos en vez del 1% inicial, pero hacemos dos búsquedas,
    así que la tasa de falsos positivos es del 2% del 2%, o 4 de cada 10.000 (aproximadamente).

    30:30: Filtro Bloom. Hay un número óptimo de búsquedas.
    Las ecuaciones están en la Wikipedia.

    35:45: Un filtro Bloom no se puede comprimir, su entropía
    es máxima.

    37:00: ¿Cómo "desdoblamos" los valores?. Es decir, que a partir de un valor de entrada, podemos poner varios bits
    a UNO, de forma no correlada.

    40:30: En la bibliografía de la Wikipedia se estudian algoritmos y el impacto de rendimiento que supone que los bits
    puestos a UNO no sean completamente no correlados. Por ejemplo:


    Kirsch, Adam; Mitzenmacher, Michael (2006), "Less Hashing, Same Performance: Building a Better Bloom Filter", in Azar, Yossi;
    Erlebach, Thomas, Algorithms - ESA 2006, 14th Annual European Symposium, 4168, Springer-Verlag, Lecture Notes in
    Computer Science 4168, pp. 456-467, doi:10.1007/11841036


    43:20: Estamos abusando de las matemáticas del filtro Bloom,
    así que antes de distribuir el filtro hacemos una
    simulación con él en el servidor.

    45:30: Un filtro Bloom tiene falsos positivos,
    pero NO tiene falsos negativos.

    • 48 min
    Podcast Z #6: Proyecto X - DNS como base de datos distribuida mundial

    Podcast Z #6: Proyecto X - DNS como base de datos distribuida mundial

    Usar el DNS como un sistema de cacheo mundial. https://podcast.jcea.es/podcastz/6
    Notas:


    00:30: El proyecto es confidencial, pero quiero exponer algunas técnicas que pueden
    ser útiles para otros programadores.

    02:50: El programa requiere actualizarse constantemente de forma automática.

    04:30: El usuario solo instala manualmente un "descargador".

    05:50: Descripción del proceso de actualización.

    06:30: Firma digital, imprescindible cuando hay actualizaciones constantes a través de
    redes no confiables.

    08:00: En la primera versión del proyecto, el programa se descargaba en cada ejecución (20KBytes).

    09:00: Pero esto no escala cuando el número de usuarios crece, o el tamaño del fichero crece.

    13:30: Usar el DNS para comprobar las versiones, utilizándolo de caché. A nivel mundial
    y de forma simple.

    15:20: Cuando un ordenador pide a su ISP que haga una petición de DNS, dicho ISP cachea
    el resultado y está disponible para otros clientes. Y el tiempo de cacheo es configurable en el servidor
    origen.

    17:30: Problema: sin instalar librerías adicionales, Python tiene una capacidad de interacción
    con el DNS muy limitada. Hay que buscarse la vida.

    19:30: En vez de decir a través del DNS qué versión es la más moderna, lo que hacemos es
    permitir que el cliente confirme si su versión es la última o no. Comprobamos si el registro
    "HASH_MD5.md5.DOMINIO" existe o no.

    22:40: Ojo con los ISPs puñeteros que resuelven a sus propias IPs las resoluciones DNS inexistentes.
    Solución: Comprobamos que la IP resuelta sea la esperada.

    25:00: Firma digital por El Gamal.

    27:20: El actualizador no hace más descargar la versión actual (con todas las verificaciones)
    y luego le pasa el control. Actualizar el actualizador es "complicado" :).

    • 29 min
    Podcast Z #5: Nadie está a salvo

    Podcast Z #5: Nadie está a salvo

    Intrusión en RSA. https://podcast.jcea.es/podcastz/5
    Notas:


    00:33: RSA admite que ha habido una intrusión en sus sistemas.

    01:31: En el comunicado no se indica qué información ha sido obtenida.

    02:05: En qué consiste el sistema SecurID de RSA.

    03:31: El token.

    04:07: Los detalles del ataque.

    07:19: Una vez dentro es cuestión de buscar el camino al objetivo.

    09:07: Como Indiana Jones, una vez tienes el "ídolo de oro" hay que escapar adecuadamente.

    11:35: Pero, ¿qué se han llevado?. Especulaciones varias.

    18:41: El PIN, un elemento de seguridad opcional extra del sistema SecurID.

    22:12: Más especulaciones.

    23:35: Conclusiones.

    33:21: Para un futuro podcast: Cómo debiera funcionar un sistema desde el punto de vista de la seguridad.

    35:55: Un par de detalles finales.



    Enlaces relevantes:


    RSA explains how attackers breached its systems
    Anatomy of an Attack"
    RSA/EMC: Anatomy of a compromise
    The RSA Hack: How They Did It"
    RSA: SecurID Attack Was Phishing Via an Excel Spreadsheet
    RSA Says SecurID Hack Based On Phishing With Flash 0-Day
    RSA SecurID data compromised
    SecurID
    Spearphishing + zero-day: RSA hack not 'extremely sophisticated'
    RSA won't talk? Assume SecurID is broken
    The RSA/SecurID Compromise: What is my risk?"
    The RSA SecurID Problem
    RSA Breached: SecurID Affected

    • 38 min

Reseñas de clientes

4,5 de 5
2 valoraciones

2 valoraciones

Buenojoseluis ,

Entretenimiento tecnológico

Entretenido, informan y aprendes. Esperando al sexto número

Saludos

Top podcasts de Tecnología