El objetivo de esta entrada es mostrar una manera de hacer un poco más seguro el acceso a una aplicación web (login) si ésta no dispone de SSL (HTTPS).
Para los que son duchos en la seguridad, puede que esto les pueda parecer simple, e incluso obvio, pero en muchas empresas de desarrollo de páginas web, ni se plantean lo peligroso que puede llegar a ser el envío de credenciales en claro a través de Internet.
Un problema que nos encontramos los que nos dedicamos al desarrollo de software, y en concreto de páginas web, suele ser que el cliente no quiere (o no puede) pagar un certificado de servidor para su portal. Lo que tampoco queremos es que nuestras contraseñas vayan por la red en claro, siendo vulnerables a cualquiera que ande “esnifando” por la red. Supongo que existen varias soluciones a este problema, yo os voy a contar una que no es solución y otra que es un poco mejor (en temas de seguridad nunca me atrevería a decir que es infalible, porque creo que nada lo es). Para los ejemplos voy a usar como usuario a bob y como contraseña bob123.
Lo que NO es una solución
Si estáis tratando de solventar este problema, probablemente os encontraréis con sitios que os dicen que la solución pasa por cifrar la contraseña con Javascript (aprovecho para recordar que el verbo encriptar no existe, y cada vez que alguien la usa se muere un gatito) justo antes de que el formulario se mande.
Normalmente suelen decir que hagas un hash de la contraseña y así esta no viajará en claro por la red. Esto no es una solución porque si yo soy un “hacker” maligno y consigo ver la comunicación, no podré leer la contraseña bob123, pero si que veré 2acba7f51acfd4fd5102ad090fc612ee, que es el resultado de aplicar una función hash (md5) a bob123.
La cosa es que a mí, como atacante, me da lo mismo ver lo primero que lo segundo, ya que sé que si mando la petición de login a la página “web” poniendo como usuario bob y como contraseña 2acba7f51acfd4fd5102ad090fc612ee voy a poder acceder a la aplicación (entiéndase que esto se realizará usando alguna herramienta de manipulación de peticiones HTTP como burp o tamperdata etc…). Además, es muy común que las contraseñas en las bases de datos se guarden cifradas con este mismo método (y el que las guarde en claro, tiene un problema muy grave), con lo que, en realidad, puede que lo que esté viajando por la red sea la contraseña en si misma.
Una posible solución
La solución que creo más segura es la de “simular” la conexión SSL mediante un par de claves pública/privada por petición. De esta manera el servidor mandará la clave pública, que le servirá al navegador para cifrar la información, y guarda la clave privada, que sólo sirve para descifrar esa información. Para realizar esto haremos uso del Javascript de forma similar a la anterior. La diferencia es que esta vez cuando el cliente (navegador web) haga la petición a la pantalla de login, el servidor generará un par de claves nuevas.
Creo que es de buena praxis cifrar, además de la contraseña, el nombre de usuario ya que contra menos pistas demos a los atacantes mejor. Así pues, cada vez que le mandemos la información de acceso al servidor, ésta será diferente, y aunque vieran que el usuario es 0a42b6b9dcd569f990d y la contraseña es cde40f4ff73c5a24eb904, esto sólo será válido una vez ya que a cada petición el servidor nos manda una clave pública distinta. Hay que tener mucho cuidado con esto, dado que si el servidor usa como semilla de generación de claves algo obvio, como el tiempo, se podría mediante repetidas peticiones de la página de login, obtener el algoritmo que esta usando para generarlas y podría llegar a obtener la clave privada para una petición y descifrar así la información
Por Guillermo Mir en http://www.securityartwork.es/2012/03/13/metodo-de-login-seguro-sin-ssl/
Marcadores