Nota del autor

Si la entrada que estás leyendo carece de imágenes, no se ve el vídeo que teóricamente lleva incrustado o el código fuente mostrado aparece sin formato, podéis conocer los motivos aquí. Poco a poco iré restableciendo la normalidad en el blog.
Este blog es un archivo de los artículos situados previamente en Lobosoft.es y ha dejado de ser actualizado. Las nuevas entradas pueden encontrarse en www.lobosoft.es. Un saludo,
Lobosoft.
Mostrando entradas con la etiqueta openid. Mostrar todas las entradas
Mostrando entradas con la etiqueta openid. Mostrar todas las entradas

viernes, 24 de octubre de 2008

Vulnerabilidades en OpenID

Desde que apareció OpenID me mostré bastante interesado por la idea: un servicio único (aunque distribuido) de identificación en la red, algo así como un conjunto de “servidores DNS sobre las personas” que permitiría obviar de vez en cuando, y cada vez más, la tediosa tarea de rellenar formularios de registro en las webs. Aunque la idea me pareció genial en este sentido, se me venían a la cabeza problemas como la gestión de la confianza de unos servidores en otros (que se resolvería utilizando certificados digitales entre ellos), y la posibilidad de que un servidor “malicioso” entrase en el juego, por ejemplo mediante un ataque de phishing.


Han sido varios los problemas que han surgido en torno a OpenID en este tiempo, ya sean relacionados directamente con la idea o con las tecnologías sobre las que se sustenta. Por ejemplo, la debilidad en el generador de números aleatorios de Debian provocada por una actualización del código en el que se “limpió” de una “molesta” herramienta de depuración, eliminando de paso la inicialización de la semilla de números aleatorios y que llevó a tener que actualizar OpenSSL para Debian y sistemas derivados del mismo, como Ubuntu, pero que ha dejado libres multitud de certificados digitales vulnerables que deberían ser generados de nuevo. Pues bien, varios proveedores de OpenID (de bastante magnitud además) fueron afectados por dicho problema.


Hace unos días se presentó una noticia sobre la vulnerabilidad del algoritmo del servidor de OpenID utilizado en Weblogs, S.L. y en multitud de servicios similares. Se trataba de un código en PHP que ya no está siendo mantenido, y que presentaba diversas vulnerabilidades que permitirían a un usuario malicioso realizar un ataque combinado de XSS y XSRF mediante el que podría usurpar la identidad del usuario que accediese al sitio web malicioso. El descubridor de las vulnerabilidades, José Carlos, abunda en la descripción del ataque e incluye en su blog un exploit demostrativo. Afortunadamente, Weblogs ha sido avisada de esto y se ha corregido el problema, pero es altamente probable que muchos servidores se encuentren afectados por éste.


Si a todo esto sumamos que OpenID no ha tenido la acogida que habría sido de esperar ante lo interesante de la idea, ¿en qué estado se encuentra ahora este sistema de identificación digital? ¿Vosotros usáis OpenID habitualmente? ¿Qué os parece, en uno u otro caso, dicho sistema? Os dejo algunos enlaces interesantes al respecto.


sábado, 26 de enero de 2008

OpenID en ASP.NET

Logo de OpenID


Elegir el método de autenticación y autorización de los usuarios de una aplicación y, más concretamente, de una aplicación web que permanece expuesta a la inclemencia de Internet, es siempre un factor determinante en la seguridad de los sistemas informáticos. En la plataforma .Net de Microsoft, los métodos de autenticación para una aplicación ASP.Net dependerán de los que proporciona el servidor web IIS, permitiendo por tanto tres tipos de autenticación: básica, implícita y Windows; podrá estar basada en formularios (usando cookies); o, por último, podremos hacer uso del servicio de Microsoft Passport.


Por otro lado, ASP.NET proporciona básicamente dos tipos de autorización: basada en la autorización de URL, que proporciona acceso a secciones el sitio web para una determinada identidad o mediante la comprobación de listas de control de acceso (ACLs) o permisos sobre recursos para determinar si el usuario autenticado puede tener acceso a los mismos (gestión de roles).


Toda esta gestión se configura mediante el archivo de configuración de la aplicación (usuamente, el web.config). Hasta aquí, simplemente hemos expuesto unas nociones sobre seguridad en una aplicación web ASP.Net.


Hace un par de meses conocí el proyecto OpenID, un estándar que brinda un sistema descentrado de identificación, permitiendo, para aquellos sitios web que le ofrezcan soporte, el acceso de los usuarios sin necesidad de crear una cuenta específica para el mismo. Simplemente necesitarán un proveedor de identidad (IdP). Dicho en pocas palabras y con un ejemplo de la vida real: Yahoo, que acaba de adoptar el estándar como proveedor de cuentas (OpenID 2.0), ha ganado casi 250 millones de usuarios potenciales. Es más, otro de los grandes de la informática, Google, comienza a flirtear con OpenID, permitiendo usarlo como sistema de identificación en los comentarios a las entradas de los blogs de Blogger. Y MediaWiki (el software que se encuentra tras la archiconocida Wikipedia), Wordpress o Drupal ya incorporan, o están en fase de hacerlo, ésta tecnología.


¿Y Microsoft, que pinta en todo esto? Bueno, de momento sigue haciendo la guerra por su cuenta con el lanzamiento de Windows CardSpace, un gestor de cuentas de identidad, incorporado “de serie” en el .Net Framework 3.5. Podemos encontrar en SandBox una página de ejemplo sobre el uso de esta tecnología.


Así las cosas, y visto que OpenID es un estándar dispuesto a quedarse, ¿cómo llevarlo a nuestras aplicaciones ASP.NET?



A grandes rasgos, el funcionamiento de OpenID es el siguiente: el usuario crea un identificador en un servidor que verifique OpenID, y el proveedor de identidad confirmará entonces la identificación del usuario a los sitios que soporten este sistema.
El usuario obtiene, tras este registro, una simple URL (o más concretamente un XRI) que puede usar para identificarse. Es más, si posee una página web puede incluir unas etiquetas “META” en la misma, y usar su propio dominio como código de identificación.

Con OpenID nos encontramos, por tanto, ante una arquitectura Single Sign-On que no especifica el mecanismo de autenticación, por lo que la seguridad de la conexión dependerá de la confianza del cliente en el proveedor de identidad. Según sea la implementación de éste se ofrecerá una autenticación más o menos fuerte, y una mayor seguridad en el sistema.



Así, si queremos que nuestra aplicación web sea compatible con el nuevo estándar, la implementación irá a cargo de las librerías (de código abierto, como el resto del proyecto) que proporciona el sitio web oficial de OpenID.
En concreto, las existentes hasta el momento para .Net se encuentran en C#, y son:

.net OpenID
NerdBank ASP.NET OpenID control
ExtremeSwank OpenID Consumer

Una implementación sencilla del acceso a un proveedor de identidad consiste, básicamente, en solicitar al usuario su identificador y requerir al proveedor de identidad los datos necesarios. En el proveedor, el usuario gestionará si quiere proporcionar a nuestra aplicación sus datos siempre, o sólo en esa ocasión. Los datos que nos proporcionará el usuario dependerán de su elección, siendo obligatorio proporcionar su e-mail y su nombre, y opcional el resto de información de su perfil. A continuación se puede ver el esquema de identificación que sigue OpenID.


Protocolo OpenID


Y, por último, muestro en unas pocas capturas el funcionamiento de una página de acceso a la que he incorporado identificación mediante OpenID.


En primer lugar, el usuario accede a nuestra aplicación web, y solicitamos su identificador.



Paso 1: Identificación


A continuación, se realiza la petición de autenticación ante el proveedor de identificación:



Autenticación en el proveedor de identidad.


Cuando el usuario se autentica, el Proveedor de Identidad le solicita que indique la información que desea transmitirnos. Obligatoriamente deberá indicar su nombre y e-mail, y opcionalmente otra información de su perfil. Además, podrá denegar el envío, o permitirlo una vez o siempre.


Solicitud de envío de información



Por último, la información es devuelta a la aplicación, que puede leerla en los parámetros de la URL.


El proveedor de identidad devuelve el control al sitio web.



Y, para todo ello, el código es tan simple como esto:


Código de la página y llamadas a bibliotecas de OpenID


Referencias: