Blog

Acabamos de finalizar el lanzamiento del repositorio Maven para los proyectos en Java que quieran trabajar con la tecnología de PAPI. Maven es una herramienta de software para la gestión de proyectos desarrollados en Java. Una de sus principales características es la posibilidad de definir dependencias de otras librerías Java externas, siendo capaz de instalarlas y utilizarlas en nuestros proyectos.

Para utilizar el repositorio Maven de PAPI, utilizaremos la siguiente configuración:

<repository>
<id>papimaven</id>
<name>papi maven repository</name>
<url>https://forja.rediris.es/svn/papi-ee/trunk/maven/</url>
</repository>

Como está bajo el protocolo https, tendréis que tener importado el certificado digital de su servidor web. Podéis hacerlo de la siguiente manera:

echo |openssl s_client -connect forja.rediris.es:443 2>&1 |sed -ne ‘/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p’ | keytool -import -trustcacerts -alias forja -keystore $JAVA_HOME/lib/security/cacerts -storepass changeit -noprompt

Por ahora hay 4 módulos disponibles:

• papi-crypt: librería criptográfica para trabajar con los mensajes y las cookies de PAPI.
• papi-core: librería base para trabajar con la tecnología de PAPI.
• papi-filter: filtro J2EE que hace las funciones de PoA en Java.
• papi-jicgpoa: icGPoA desarrollado en Java.
• shib-filter: filtro J2EE que conecta un proveedor de identidad de Shibboleth con una infraestructura basada en PAPI.

Nosotros ahora mismo lo estamos utilizando para nuevos desarrollos basados en PAPI que ya os iremos contando en otras entradas del blog…

Los servicios web que utilizan SOAP para el envío de mensajes han tenido la suerte de contar con la especificación Web Services Security (WS-SEC), la cual les permite incluir tokens de seguridad en la cabecera SOAP.

Mensaje SOAP con WS-SEC

Los token de seguridad más comunes en WS-SEC son:

• Nombre de usuario: token donde se incluye el nombre de usuario y la contraseña, para poder autenticar al usuario.
• Certificados digitales: token donde se incluye el certificado digital del usuario.
• Aserciones SAML: token donde se incluye una aserción SAML que incluye información sobre el usuario.

De esta forma, se pueden proteger servicios web clásicos sin ningún problema de interoperabilidad, ya que existen numerosas implementaciones de WS-SEC para casi cualquier tipo de lenguaje de programación.

Para el caso de un escenario donde tenemos servicios web tipo REST, nos encontramos con un gran problema ya que el estándar WS-SEC no puede ser aplicado, ya que al usar peticiones HTTP estándares no existía forma de incluir dichos token de seguridad sin modificar los parámetros de cada petición, y no existe ningún estándar que cubra la necesidad de enviar tokens de seguridad en dicho escenario. Aunque el token de nombre de usuario (o Username Token) de WS-SEC podría mapearse sin muchos problemas al uso de HTTP Auth, si es cierto que no existe ninguna solución si nuestra arquitectura utiliza tokens basados en certificados digitales o aserciones SAML.

Afortunadamente, la semana pasada se publicó un draft a través de la IETF para la autenticación HTTP basada en tokens. Este draft busca dar una solución a la autenticación a través de tokens de OAuth, pero ofrece un modelo genérico que puede ser aprovechado por otro tipo de tokens más clásicos como los comentados más arriba.

Así, basándonos en dicho draft, una forma de proteger nuestros servicios web tipo REST utilizando certificados digitales quedaría tal como describe el siguiente ejemplo:

GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Token token=»h480djs93hd8…yZT4=»,
class=»x509″,
method=»rsassa-pkcs1-v1.5-sha-256″,
nonce=»dj83hs9s»,
timestamp=»137134190″,
auth=»djosJKDKJSD8743243/jdk33klY=»

GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Token token=»h480djs93hd8…yZT4=»,
class=»samlv2.0″,
method=»none»

Los pasados días 3 al 5 de Noviembre de 2009 se celebró la novena edición de Internet Identity Workshop. Aunque la agenda estaba llena de temas muy interesantes, con numerosas sesiones que había en relación a OpenID, destaca la que se llamaba OpenID v.Next, que coordinaba Dick Hardt y David Recordon, donde se terminó de perfilar los principales aspectos de la próxima especificación de OpenID 3.

La principal característica de OpenID 3 es que no será compatible 100% con la actual especificación de OpenID 2. No habrá que asustarse, la base será la misma pero al igual que hay problemas de interoperabilidad entre OpenID 1 (¿todavía lo usa alguien?) y OpenID 2, habrá algunos ajustes en el protocolo con la nueva versión. Además de esta evolución, han publicado una lista con las novedades en las que se trabajará y cuántos votos obtuvo en la sesión:

• Integrar la extensión UX (User eXperience), 12 votos. Parece que el punto más importante para OpenID 3 será la usabilidad, como podemos ver en este prototipo.
• Evolucionar la etapa de descubrimiento (o discovering), 10 votos, para que llegue a admitir nuevos formatos para el identificador de OpenID, como el correo electrónico.
• La extensión de atributos pasa a integrarse dentro de la especificación base, 9 votos.
• La extensión OAuth hybrid pasa a integrarse dentro de la especificación base, 8 votos.
• Integración de clientes externos a la hora de elegir proveedor de OpenID y también integración con clientes que no son aplicaciones web, 8 votos.
• Mejorar la seguridad, incluso mayor soporte para LoAs (Level of Assurance), 8 votos.
• Mejorar la integración con móviles, 8 votos.
• Resolver la problemática de URLs muy largos, 6 votos, ya que hay algunos navegadores que las limitan a 256 caracteres.

La foto es propiedad de Silverisdead tomada mientras asistía a la sesión.

Las contraseñas (o passwords, como dirían nuestros amigos los anglosajones) son parte de nuestra vida desde mucho antes que Internet se colara en nuestras vidas. En 1967, John Shepherd-Barron inventó el concepto de PIN (Persona Identification Number o Número de identificación personal) cuando trabajaba en el primer cajero de un banco londinense. Su primera idea fue utilizar una contraseña de 6 dígitos, pero al hablarlo con su mujer ella prefería 4 dígitos, ya que le resultaba más cómodo de recordar.

Pero a raíz de la popularización de Internet, cada vez más utilizamos un par «nombre de usuario» y «contraseña» para leer nuestro correo, escribir un comentario en un blog o ver las fotos de nuestra familia.

Como el nombre de usuario es algo que nos identifica dentro de la comunicación social que ocurre en Internet no existe ninguna recomendación a la hora de definirlo desde el punto de vista de la privacidad, exceptuando aquellas fundamentales como no utilizar nuestro DNI.

Con respecto a la contraseña, existen muchas recomendaciones que debemos leer y aplicar siempre cuando tengamos que establecer una nueva contraseña, como las dadas por el equipo de seguridad de Microsoft o por Inteco. Como resumen, nosotros en PRiSE recomendamos las siguientes directrices:

• Tamaño de la contraseña: podemos clasificar las contraseñas, en función del número de caracteres que tienen, en débiles si tienen menos de 8 caracteres, fuertes si tienen entre 8 y 13, y muy fuertes si tienen 14 o más caracteres.
• Caracteres a utilizar: las contraseñas que sólo tienen letras son muy fáciles de adivinar por un software especializado. Se recomienda que la contraseña tenga más de un número y, además, al menos un caracter especial de alguno de la lista !@#$%^&*-+<>?{}[]_.
• Cambiar la contraseña periódicamente: cuanto más tiempo utilices la misma contraseña, más probabilidad tienes que sea adivinada o «capturada». Lo mejor es que la cambies de vez en cuando.

Una manera bastante óptima de generar una contraseña segura es utilizar una frase que nos resulte familiar, como el de alguna canción favorita, y utilizar la primera letra de cada palabra. Sobre dicha cadena de primeras letras, reemplazamos algunas vocales o consonantes por números o caracteres especiales que visualmente no nos resulte diferente a la palabra que obtuvimos al coger cada primera letra de cada palabra. Por ejemplo, si nos basamos en la canción «La casa por el tejado» de Fito y Fitipaldis:

La casa por el tejado —> Lcpet —> L[p3t

Aunque lo más cómodo desde el punto de vista del usuario es tener una sola contraseña para todas las cuentas, ya que nos facilita recordarla y no tener que apuntarla en ningún post-it (nunca hagáis esto, ¿ok?), es mejor tener varias contraseñas, en función del uso que vayamos a darle. Obviamente lo ideal es tener una contraseña muy fuerte diferente para cada uno de los portales, pero si no compaginamos usabilidad con seguridad, el modelo termina siendo un fracaso.

En PRiSE creemos que sería conveniente que tuvieras los siguientes «tipos» de contraseñas:

• Contraseña personal de baja seguridad: esta contraseña será fuerte (de 8 a 13 caracteres) y la utilizaremos en aquellas páginas web que requieran registro y en la que no almacenaremos información privada sensible nuestra, como ocurre al registrarnos en un foro o en un blog. Estos sitios suelen ser más sensibles a los ataques de gusanos o troyanos y si, en el peor de los casos, dejan al descubierto nuestra contraseña, no nos afectará en otros sitios más sensibles como un portal de compra on-line.
• Contraseña personal de alta seguridad: esta contraseña es de tipo muy fuerte (14 caracteres o más) y la utilizaremos en páginas web donde haya información privada sensible, como suele ocurrir en Facebook o Tuenti, o para leer nuestro correo electrónico como gmail o hotmail.
• Contraseña para el trabajo: esta contraseña, que será de alta o baja seguridad en función del uso que tenga en la infraestructura de nuestro trabajo, debe ser diferente a una de las anteriores. Esto debería ser así ya que, aunque no lo creamos, puede que algún día se la prestemos a alguien de confianza en el trabajo para que pueda realizar alguna actividad nuestra que en ese momento no podamos. Si esto pasa algún día, mejor que no sea la que utilizamos también para leer nuestro correo personal.

Desgraciadamente, estas recomendaciones que damos en esta entrada no son aplicadas tantas veces como quisiéramos. A principios de Octubre nos enteramos de que se habían filtrado 10.000 contraseñas de cuentas de Hotmail por una persona anónima. Sobre dicha lista de contraseñas, se ha realizado un estudio estadístico, y podemos resaltar las siguientes conclusiones:

• Un 37% de las contraseñas eran de tipo débil (7 caracteres o menos), 56% eran de tipo fuerte (entre 8 y 13 caracteres) y sólo un 6% eran de tipo muy fuerte (14 o más caracteres).

Tipos de contraseña

• Un 45% de las contraseñas contenían sólo letras, 19% contenían sólo números, 30% mezclaban letras y números y sólo un 6% utilizaban también caracteres especiales.

Caracteres en las contraseñas

Estas estadísticas demuestran que todavía queda mucho en la educación del usuario a la hora de que elijan contraseña. Aunque hay que decir a su favor que los bancos siguen haciendo un «favor» al mantener el PIN de 4 dígitos, ya que, ¿qué hay más seguro que un banco?

* La foto del artículo es propiedad de Amagill y está licenciado por Creative Commons Attribution