Mi columna en El Español de esta semana se titula «Usuario y contraseña«, y habla de la muy necesaria evolución de los sistemas de seguridad basados en usuario y contraseña, un método que ya ha demostrado claramente carecer de escalabilidad y ser una fuente de problemas de todo tipo.
La enésima noticia de publicación de un descomunal listado de nombres de usuario y contraseñas obtenidos a partir de una intrusión en un servicio nos genera, como es lógico, la misma sensación de déjà vu y de hartazgo que nos generan todas las demás: lo normal es que el usuario, como mucho, cambie la contraseña del servicio afectado, o simplemente haga caso omiso si no se lo piden específicamente.
En este caso han sido Dropbox, un servicio utilizado por muchísimos usuarios – he visto incluso usuarios que no recuerdan serlo, porque venía pre-configurado para su activación con su smartphone para almacenar fotografías – y LastFM, un servicio de música en streaming. Dropbox sufrió una intrusión en el año 2012 que logró hacerse con cuatro ficheros de unos 5GB que contenían información detallada de 68,680,741 cuentas. Aunque unos 32 millones de ellas estaban cifradas con métodos aún considerados fuertes, el resto lo estaban con SHA-1, un algoritmo considerado antiguo y vulnerable. Y aunque Dropbox ha avisado a los usuarios comprometidos y les ha forzado a cambiar sus contraseñas, es muy posible que esos pares de usuario y contraseña sean utilizados en otros servicios, y que los posibles delincuentes en busca de una oportunidad puedan encontrarlos.
Ante una noticia de este tipo, lo primero que debe hacerse es acudir a un servicio del tipo Have I been pwned? y comprobar si estamos afectados. El servicio te informa si esa dirección de correo electrónico está en alguna de las bases de datos publicadas – considerando que robos como el de MySpace, LinkedIn, Adobe o Badoo afectaron a varios centenares de miles de cuentas, lo raro es casi no aparecer – y, si efectivamente es así, tratar de hacer memoria de en qué páginas hemos utilizado ese correo como login y si hemos repetido la contraseña interceptada, además, lógicamente, de no volverla a utilizar.
El problema viene de la misma esencia del sistema: plantear que nuestras contraseñas deban tener requisitos como ser complejas para evitar un ataque de diccionario, que las sustituciones habituales (un 4 por una A, un cero por una O, un 3 por una E, etc. no sirven porque ya están contempladas), que deben contener caracteres especiales, tener una longitud mínima determinada, y poco menos que ser imposibles de recordar es algo que, claramente, no funciona. La memoria de los usuarios es incapaz de recordar contraseñas así, y además, supuestamente, una para cada servicio, en un entorno en el que fácilmente podemos estar utilizando decenas de ellos. Una cosa es que utilizar password, 1234 o qwerty sea de débiles mentales, que lo es, y otra muy distinta plantear requisitos que resultan prácticamente imposibles. Entrar en algunos servicios termina por convertirse en un procedimiento tan farragoso e incómodo, que termina por darnos pereza. A partir de un punto determinado, el problema deja de estar en los usuarios y pasa a estar en otro sitio.
La seguridad basada en usuario y contraseña tiene que ser replanteada, y además, lo antes posible. El incremento en la sofisticación de las herramientas utilizadas en los ataques hace que no hacer nada ya no sea una opción. Optar por un gestor de contraseñas es una opción que no deja de tener su peligro – ¿quien asegura que el propio gestor de contraseñas no acabe teniendo una vulnerabilidad? – pero, decididamente, es un peligro muy inferior al que tenemos si no lo utilizamos. Sistemas con autenticación en dos pasos, en combinación con el lector de huella del smartphone o similares pueden plantearse para algunos servicios, pero difícilmente para todos. Y simplemente encomendarse a la suerte, santiguarse o apuntar mil contraseñas en un papelito ya no son una opción seria. Esto es cada vez más insostenible. Algo tiene que cambiar.
La verdad es que la solución podría pasar por OpenID o Google o Apple, alguno que esté siempre al día y no se deje hackear con facilidad. Incluso Facebook usando su API…
La cosa es que tengo ya más de 800 contraseñas y también es horrible usar un gestor de contraseñas si quieres cambiarlo, si cambias una clave, si se resetea… cada vez que me enfrento a actualizarlo me resisto porque pueden ser días y días de trabajo… para que te lo vuelvan a hackear.
¿Una combinación de 2 claves libremente puestas en base a 2 preguntas que tú mismo pones? Y las hasheas en sistemas distintos.
Otra cosa que me pone de los nervios es que unos servicios piden mayúsculas y minúsculas con símbolos y 8 carácteres de longitud, pero otros piden 6 sin nada, otros piden 15…. es una locura no tener un estándar o peor… tener un máximo. La de 15 no la puedo usar en casi ningún lado porque es demasiado largo. En fin….
Saludos!
OpenID cada vez esta mas en desuso. Hasta hace poco yo disponia de un login OpenID proporcionado por Verisign y lo cerraron hace unos meses. La verdad es que ya hacia años que no lo usaba para nada (y cuando lo usaba era para pocas cosas) asi que la perdida no ha sido gran cosa.
Lo que me da mas miedo son los logins de Facebook o Google, que te obligan a pasar por el aro de esas empresas.
Al parecer la información sustraída a Dropbox no contenía contraseñas, sino cada uno de los hash generados por éstas. Por otra parte, a menudo se confunden los conceptos cifrado y hashing.
Existen lo que se llaman «rainbow tables». Son listados de pares hash-contraseña.
Asi por ejemplo, en una rainbow table puedes encontrar listas como
aaaa->lfjasflsahffwh
aaab->fksjaiower,mx
Con realizar una busqueda del hash es instantaneo localizar la contraseña.
Lo que se suele usar en combinacion con los algoritmos de hashing es agregar un parametro «salt» desconocido, una variacion de la clave antes de almacenarla.
Por ejemplo, si tu clave es «osezno», antes de hashearla pueden modificarla añadiendo VAR (los tres ultimos caracteres de tu apellido) y codificar «oseznoVAR», o segun el numero de letras o cualquier cosa parecida, o poner una modificacion en el propio hash. Se trata de modificar la clave antes de almacenarla para que no se pueda usar directamente una tabla ya generada.
Debería utilizarse lo que se llama la huella digital, lo que los «recolectores de datos digitales» utilizan para asociar a tu usuario, tus movimientos por la red, Un conjunto de datos que enviamos automáticamente, que configuran nuestra «huella digital»·, la direccion IP, el sistema operativo, el tipo de pantalla, el email principal. el modelo de procesador, nuemros de registros de programas, cookies,…. Todo ello conforma una serie de características que no siempre están presentes, por ejemplo, podemos haber borrado las cookies o podemos entrar en Internet desde el PC de un amigo, o haber escrito mal la contraseña. pero las estadísticas ballesianas pueden definir con ujn indice de error, si eres o no quien aparentas ser , y en función de lo que vayas a hacer, permitirlo o solicitar mas confirmación en caso de duda.
Por ejemplo si lo que quieres es consultar el tiempo, bastaría con que el lector de huellas digitales mandar algo que se parece con un margen de un 40%, porque el riesgo de que alguien nos suplante en ello es muy bajo, pero en cambio, para hacer un pago con el teléfono, puede elevarse la coincidencia en general de todos los datos de al 88% y si no llega, exigir confirmaciones adicionales previamente pactada, por ejemplo el nombre de un compañero de colegio, la ciudad donde veraneabas de pequeño, o el numero de la matricula de tu coche.
Con ello, no te darían la lata constantemente con claves imposibles de recordar o procesos muy complejos, Si trabajas desde tu ordenador para casi todo ni se necesitaría introducir la contraseña, pero para los casos delicados, se podría conseguir una alta seguridad, pues aunque te hubieran robado las contraseñas, les faltaria el entorno de tu huella digital y no sabrian dar las confirmaciones adicionales.
Siempre he mantenido que en la nube no pongas nada confidencial.
Pero lo mejor es la solución que ha ideado un «experto» en seguridad
https://haveibeenpwned.com/
Entras en esta web e introduces tu correo. Y te dice si has sido afectado por fallo de seguridad o no. Pero atención que aui viene lo bueno.
Imaginate que tenias una cuenta en algún servicio de «intercambios», coge un correo de alguien de tu entorno y lo introduces, y sabes al instante que tenías cuenta.
Maravilloso que listos son algunos…
Enrique, como ya ha explicado Miguel A. Tovar en un comentario anterior, no se almacenan passwords en los servidores en los que se requiere un login.
Solo se almacena la función ‘hash’ de esa combinación. Y la vulnerabilidad del servidor, con la que se ha accedido a los datos de los usuarios de DropBox, no tiene que ver con la seguridad de la longitud de la clave.
Tras acceder con las credenciales de empleados de Dropbox en 2012 – no de los usuarios – ha sido ahora cuando se ha descubierto un volcado de las credenciales de 68 millones de cuentas, extraídas mediante esa brecha de seguridad.
Sencillamente, el algoritmo de hash utilizado hasta 2012, el SHA1, es susceptible de ser más vulnerable que el que se utiliza en la actualidad en la totalidad de las cuentas de Dropbox, desde esa fecha, BCrypt.
La vulnerabilidad que ha hecho explotable remotamente esas credenciales, de hecho reside en un SDK de Dropbox para Android, con el que se aplicaban las funciones de seguridad mediante ‘hash’ en el acceso móvil.
Hubiese dado lo mismo que fuesen datos biométricos, ya que es el hash de esa autenticación el que se ha filtrado.
Me temo que es un ‘brief’ un poco técnico, pero la medida que sí ha tomado Dropbox es solicitar una autenticación de dos factores a todos los usuarios de las cuentas antiguas afectadas por esa vulnerabilidad.
–
68 Million Credentials Spilled in 2012 Dropbox Hack
DroppedIn: Remotely Exploiting the Dropbox SDK for Android
–
«If someone steals your password, you can change it. But if someone steals your thumbprint, you can’t get a new thumb. The failure modes are very different.»
Bruce Schneier
Totalmente deacuerdo contigo. Es vergonzoso lo que ha pasado con Dropbox.
SHA-1 no es que sea un algoritmo considerado antiguo y vulnerable, SHA-1 es un algoritmo para producir hashes. Que no es lo mismo que un algoritmo para producir hashes de contraseñas, como son bcrypt o scrypt.
Estás poniendo un enlace que nada tiene que ver con el hecho de porque no hay que usar SHA-1 para contraseñas.