Alternativas a las cookies

La publicación de las cookies de la semana anterior trajo consigo un debate entre varias amistades mías; asegurando un grupo que las cookies eran inseguras y poco efectivas y otros defendiéndolas. Por esta razón ceo que vendría bien analizar las alternativas a las mismas para que ustedes se creen un criterio y decidan el lado que van a apoyar ahora que saben un poco más.

Creo que prima empezar aclarando que algunas de las operaciones que se pueden realizar mediante cookies también se pueden hacer mediante otros mecanismos. Pero como es de suponer, estos tienen sus propios inconvenientes (de lo contrario habrían dejado obsoletas a las cookies). Por esta razón la privacidad sigue siendo hasta nuestros días un problema, utilicemos o no las cookie, las defina o no el servidor.

La primera y que seguro se les ha ocurrido a muchos (otros es probable que la hayan leído) es utilizando la dirección IP, que no es más que almacenar esta dirección del ordenador que solicita las páginas. El reconocimiento de IP está disponible desde los inicios de World Wide Web, debido a que es necesario al descargar páginas que el servidor reconozca la dirección IP del ordenador donde corre el navegador. Está opción puede ser guardada en el servidor, esté o no usando cookies. Pero como ustedes sabrán en algunas redes las direcciones IP son dinámicas (como Infomed), se le asignan al ordenador en el momento de conectarse (un mismo ordenador puede tener diferentes direcciones IP en diferentes sesiones). Esto provoca que sea menos fiable que las cookies en la identificación de un usuario. Sin embargo, esta técnica la podemos hacer más confiable si usamos otra característica del protocolo HTTP: en el momento que un usuario solicita una página porque ha seguido un link, la petición que se envía al servidor contiene la URL de la página donde el link estaba localizado. Si el servidor almacena esas URL, se puede rastrear el camino de páginas visitadas por el usuario de forma más precisa. Pero he aquí otro inconveniente: varios usuarios en un mismo ordenador pueden acceder a la misma página y después seguir links diferentes, lo que hace este “rastreo” menos fiable; y digo rastreo porque está técnica solo permite eso y no puede reemplazar a las cookies en sus otros usos.

Pero pese a esto puede que algunos todavía piensen que se puede usar la dirección IP, pues bien, les diré que es imposible en algunos sistemas que se utilizan precisamente para mantener el anonimato en Internet, tales como Tor (-The Onion Router- es una implementación libre de un sistema de encaminamiento llamado onion routing que permite a sus usuarios comunicarse en Internet de manera anónima). Con sistemas como este, el navegador utiliza varias direcciones IP a lo largo de una sesión.

Otra técnica más precisa es la URL (query string), que consiste en incrustar información en la URL. El mecanismo de sesión de PHP utiliza este método si las cookies no están habilitadas. Consiste en que el servidor web añade query strings a los enlaces de la página web que contiene, a la hora de servirla al navegador. Cuando el usuario sigue un enlace, el navegador devuelve al servidor la query string añadidos a los enlaces. Usándolas de esta forma, si nos damos cuenta son muy parecidas a las cookies, siendo ambas porciones de información definidos por el servidor y devueltas por el navegador posteriormente. Pero ahora veamos las diferencias y desventajas de la query string. Si un usuario accede a una página 2 veces, no hay seguridad que utilice la misma query string; tal es el ejemplo siguiente: se accede a una página a través de otra que se encuentre en el mismo servidor y a través de un buscador --> las query string serán normalmente diferentes, mientras las cookies serian iguales. Recordando lo hablado referente a la fijación de sesión (en el artículo cookies de la semana pasada) se puede decir que una query string simplifica dichos ataques, por lo que en esta parte de seguridad las cookies son más seguras (disculpen la redundancia pero la creo necesaria).

Veamos ahora la Autenticación HTTP, para esta autenticación el protocolo HTTP incluye mecanismos tales como el digest access authentication, que permite acceder a una página web sólo cuando el usuario ha facilitado un nombre de usuario y contraseña correctos. Después de este acceso el navegador guarda esta información y la utiliza para acceder a las páginas siguientes sin intervención de usuario, para nosotros es lo mismo que las cookies, pero en cada acceso a una página el navegador se encarga de enviar nuevamente estos datos, por lo que si alguien estuviese escuchando este tráfico podría leer esta información y almacenarla para su uso posterior, además de que normalmente tras un tiempo de inactividad estas sesiones expiran.

Ahora pasemos a una alternativa que pocos conocen, y tal es el caso de Objetos Macromedia Flash almacenados localmente. Si un navegador incluye el plugin de Macromedia Flash Player, se puede utilizar la función -Local Shared Objects- del mismo, de una forma muy similar a las cookies. El tamaño máximo por defecto de los objetos es 100 kb y casi todos los usuarios de Windows tienen Flash Player instalado, de forma que los Local Shared Objects pueden estar habilitados cuando las cookies no lo están. Aquí una alternativa que a mi parecer es de las mejores, aunque existen usuarios novatos en la actualidad que no tienen este plugin en el navegador.

Otra alternativa y la última que conozco es Persistencia en el cliente, que no es más que un mecanismo de persistencia que algunos navegadores web soportan, basado en script que permite que la página almacene información localmente para su uso posterior. Internet Explorer, por ejemplo, soporta información persistente en el historial del navegador, en los favoritos, en un almacenamiento XML, o directamente en una página web guardada en disco.