miércoles, 10 de julio de 2013

Contraseñas en tus aplicaciones web

Recientemente en Hackplayers publicaron un post en el que nos mostraban cómo un grupo llamado Crackstation había recopilado una lista de casi, casi 15GB y medio de contraseñas distitnas que se han ido filtrando a lo largo del tiempo. Ese fichero, que se puede descargar en un .zip de poco más de 4GB, está a disposición del público que lo desee en algún enlace a un .torrent, que se podrá encontrar en su página.

Yo, mi parte, me lo descargué, (ya contaré cómo, aunque no haya mucho secreto en ello), y, por desgracia, el ejecutar

type nombreFixh.lst

desde una consola cmd no acaba de dar buenos resultados. Como he dicho, ahí hay otra historia.

Ahora. Si se hace una pequeña navegación por el sitio, encontramos cosas bastantes curiosas. Entre otras, además de un listado de sitios que se sabe que guardan las contraseñas en texto claro. Mucho, mucho miedo tiene que dar ponerlas ahí. Otro listado, de los que sospecha que no es que pongan mucho esfuerzo en cómo guardan las contraseñas. Es un pequeño hall of shame.

Pero, eso no es todo. También da consejos sobre cómo almacenar contraseñas (y su aliño o salt) de una manera segura. He de decir que algunas las sabía, otras más o menos me sonaban y otras, no tenía ni idea.

Para recordar un poco qué es eso de saltear (aliñar) una contraseña se trata de pasarle un parámetro que permite que el hash utilizado devuelva un resultado distinto para la misma palabra utilizada de contraseña, dependiendo de ese aliño.

Ahora bien. Cuando se tratan de servicios en los que tenemos que guardar la contraseña, hay que tener mucho cuidado de cómo se hace. Si no se hace bien, tal y como sucedió con LinkedIn, la cosa se puede poner muy fea. Eso sí, mejor como estaban que no que las hubieran guardado en claro.

¿Y cómo guardamos o tratamos las contraseñas? Muy bien. Lo primero de todo, utilizar una función hash que sepamos que en ese instante no es vulnerable. Por ejemplo, se sabe que MD5 ya no es de fiar. Por lo que habría que descartarlo. Y, si no me acuerdo mal, SHA1 también tiene algo por ahí... Por supuesto, no crear un algoritmo propio.

Después, pensar en aplicar alguna forma de salteo.

Lo primero de todo: No reutilizar el aliño. Ya sea hardcodeado, o uno obtenido aleatoriamente (por ejemplo, en utilizando un rango determinado). Si dos usuarios ponen la misma contraseña, y el salt es el mismo, tendrán el mismo hash de contraseña. Un ataque a dicho listado, una vez obtenido, devolvería la misma contraseña. Tampoco serviría aplicar uno corto. Lo mejor: que el salt tenga la misma longitud que el hash.

Otro ejemplo que ponen como erroneo. En este caso... Yo hubiera dudado qué decir, la verdad. Incluso ellos reconocen que hay cierta controversia. Se trata del hasheo múltiple. Es decir, hashear el resultado de un hash. Por una parte, afirman que se tiende a pensar que complica un poco el crackeo de las contraseñas en lo que tiempo de cómputo se refiere. Y eso es algo que yo hubiera afirmado.  Sobretodo hacen incapie en que el factor diferenciador en lo que a tiempo se refiere es ínfimo. Además, y ahí está el tema que yo también me temía (y por lo que en ciertas situaciones no me hubiera gustado hacer ciertas cosas), es que si alguien ha conseguido acceso a la base de datos (o donde quiera que se encuentren las contraseñas almacenadas), es altamente probable que tenga acceso al código fuente que trata esas contraseñas. Sólo es cuestión de prepararse un script que las calcule utilizando el algoritmo necesario. Todo independientemente de que se tenga

md5(md5(pass)+md5(salt))

ó

md5(md5(md5(sha1(pass))+md5(salt1)))

Y no digamos si ya se tira de GPU.

La idea para crear un buen salteado es utilizar funciones Cryptographically Secure Pseudo-Random Number Generator (CSPRNG). Estas funciones, que dependerán del lenguaje de programación utilizado, creará una secuencia aleatoria que no será (en teoría) predecible. Después, sólo es cuestión de almacenar el hash y el salt en la base de datos para después, poder validar la posible contraseña introducida.

¿Qué más se puede hacer? Por lo que he entendido, se puede utilizar una técnica llamada key stretching. De lo que se trata es que la función realice los cálculos de una forma lenta. Al menos, es lo que he entendido: Lo suficientemente lenta para que un ataque de cracking sea inviable, pero lo suficientemente rápida como para que la validación sí que funcione.

No hay comentarios:

Publicar un comentario