• Saltar al contenido principal
  • Saltar a la barra lateral principal
  • Saltar al pie de página

Una al Día

Boletín de noticias de Seguridad Informática ofrecido por Hispasec

Usted está aquí: Inicio / General / Los sitios web que no amaban a las contraseñas

Los sitios web que no amaban a las contraseñas

2 febrero, 2016 Por Hispasec Deja un comentario

Todos los días abrimos y cerramos la puerta de nuestra casa sin cuestionarnos el funcionamiento de la cerradura. Lo mismo ocurre cuando nos autenticamos en algún servicio online, introducimos nuestra contraseña sin preguntarnos qué procesos ocurren para que el sistema nos deje acceder. Las contraseñas son las llaves del mundo digital, pero… ¿son seguras las cerraduras digitales?
Lamentablemente cada vez son más frecuentes las noticias de fugas de información, ataques a servicios en Internet, y en muchos casos comprobamos como millones de contraseñas terminan expuestas de forma pública. Las buenas prácticas y un poco de lógica nos dice que todos los servicios deberían almacenar las contraseñas de sus usuarios de forma segura, pero… ¿se cumple realmente esta regla en todos los casos?
Todos los usuarios nos enfrentamos diariamente con diferentes formularios de autenticación. Incluso de vez en cuando nos registramos en un sitio nuevo y debemos proceder con un nuevo proceso de alta. Ya sabemos, nombre, correo, algunos otros datos en función del tipo que servicio, y por supuesto la ya clásica contraseña.
A los usuarios se nos recomienda (y hasta se nos obliga) que la contraseña que creemos sea segura, de una determinada longitud, con caracteres en mayúscula y minúscula, con números, etc. Además, se nos recuerda que no debemos dejar la contraseña apuntada en un sitio que la pueda ver todo el mundo (evitar el clásico post-it con la clave apuntada). ¿Pero estamos seguros que tras introducir esa compleja contraseña el servicio la trata y mantiene con el mismo cuidado con el que se nos insta a nosotros? Ya que ideal y técnicamente no deberían guardar la contraseña, sino una imagen (en sentido funcional) irreversible.
Está claro que nuestra clave, de una forma u otra, pasa a formar parte de una base de datos. Queremos pensar que siempre se almacena de una forma segura. Pero… ¿es siempre cierto? ¿Todos los programadores piensan en la seguridad cuando desarrollan?
No es menos frecuente que tras el proceso de alta recibamos un correo indicando que el alta en el servicio se ha llevado a cabo de forma correcta. Pero llama la atención cuando en ese mismo mensaje se nos indica en texto claro la contraseña que hemos introducido. Desde luego esto no es una buena práctica. Es un pecado mortal de consecuencias catastróficas y un indicativo directo de la postura en materia de seguridad de la organización. En pocas palabras, un correo con una contraseña en texto claro podría indicar una compañía con una cultura de seguridad potencialmente baja.
Por otra parte, esto nos puede hacer sospechar que nuestra contraseña se ha guardado en texto plano. Es cierto que el mensaje puede construirse y enviarse antes de almacenarla de forma segura en la base de datos, pero desde luego no es un buen síntoma. La contraseña en texto claro no debería aparecer en ningún sitio, ni mucho menos enviarse en un correo electrónico.
Las buenas prácticas de gestión de contraseñas dictaminan que una contraseña nunca, repetimos, nunca debe ser almacenada en texto plano.
Cada vez que recibo un mail con una contraseña en claro un escalofrío recorre mi cuerpo. ¿Se habrá guardado esa contraseña de forma correcta?
¿Cómo se deben almacenar las contraseñas de forma segura?
El proyecto OWASP (Open Web Application Security Project) tiene como objetivo ofrecer una metodología, de libre acceso y utilización, que pueda ser utilizada como material de referencia por parte de los arquitectos de software, desarrolladores, fabricantes y profesionales de la seguridad involucrados en el diseño, desarrollo, despliegue y verificación de la seguridad de las aplicaciones y servicios web.
En este sentido la OWASP es muy clara, y ofrece claros consejos a seguir sobre el almacenamiento de contraseñas:
https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
La primera recomendación pasa por no limitar ni el conjunto de caracteres ni la longitud máxima de la contraseña.
Por otra parte, la forma más recomendable para almacenar una contraseña es mediante el uso de funciones hash. Hay que aclarar que una función hash no cifra el texto, sino que crea un resumen o «firma» del mismo. De forma que al introducir posteriormente la contraseña, se puede comprobar si ese resumen coincide con el de la contraseña introducida.
Un hash es una función criptográfica que produce una salida de longitud fija a partir de una entrada arbitrariamente larga. Un buen «hash» debe cumplir las siguientes propiedades:
a) El resultado final no debe dejar traslucir ninguna información sobre los datos originales.
b) Dado un resultado determinado, no hay otro sistema aparte de la fuerza bruta que genere datos de entrada capaces de producir dicho resultado.
c) Dados unos datos de entrada y su «hash«, no debe haber un atajo (aparte de la fuerza bruta) para generar otros datos de entrada distintos y con el mismo «hash«.
Una característica fundamental de las funciones hash, es que teniendo el hash no es posible conseguir la contraseña original. Pero sí se puede intentar probar diferentes contraseñas hasta que alguna coincida con el hash dado. Pura fuerza bruta.
Existen muchos algoritmos de «hash«, pero lo más recomendable en la actualidad pasa por usar la familia SHA2 como mínimo. La OWASP recomienda el uso de las funciones PDKDF2 o scrypt.
Lo que sí que existen son las conocidas tablas arcoíris («rainbow tables«) para diferentes funciones, básicamente son listas de millones de hashes y sus correspondientes contraseñas. De esta forma basta realizar una búsqueda en un archivo para obtener la contraseña. Podemos encontrar una amplia lista de tablas arcoíris en:
http://project-rainbowcrack.com/table.htm
Para complicar los ataques por diccionario, surge la necesidad de emplear hash con sal o «salt«. Que no es sino una cadena aleatoria que se añade al principio o final de la contraseña antes de crear el hash. Para cada contraseña se debe usar un salt diferente. Así se consigue eliminar la posibilidad de que el resultado pueda buscarse en alguna tabla rainbow.
Resumiendo, se deben usar funciones irreversibles (tipo PDKDF2 o scrypt) y aplicar una sal de gran tamaño (64bits) en la fórmula de generación de la «imagen» (de nuevo, en sentido matemático).
[dato protegido] = [salt] + proteger ([function hash], [salt] + [credencial]);
¡Oh, no! ¡He olvidado mi contraseña!
Tratando con contraseñas, no podemos olvidar a la madre de todos los problemas: el método de regeneración de contraseñas. Según nuestra experiencia en la realización de auditorías es en este punto en el que suelen fallar muchas de las aplicaciones y sistemas que auditamos. Una debilidad en este aspecto puede permitir a un atacante acceder a la cuenta de cualquier usuario. De ahí la importancia de que este proceso se realice correctamente.
Es una funcionalidad que no se puede evitar, todos los sistemas tienen que tener un método para cuando hayamos olvidado nuestra contraseña. Y es que con la gran cantidad de contraseñas que mantenemos actualmente, esto suele ocurrir con frecuencia.
Existen diferentes estrategias para llevar esto a cabo. Pero siempre se debe generar una contraseña nueva. Como dijimos anteriormente las contraseñas nunca deben ser almacenadas en texto plano. Por lo que el servicio no puede tener capacidad para saber nuestra contraseña anterior. En caso de que al tratar de recuperar el acceso al servicio tras haber olvidado la contraseña se nos envíe la que habíamos introducido originalmente deben saltar todas las alarmas. Ningún sistema correctamente desarrollado puede acceder a la contraseña original en texto plano. Por desgracia ocurre más veces de lo que quisiéramos.
Otro punto débil, todavía empleado en algunos sitios, es el de las preguntas de seguridad. Las preguntas secretas siempre han resultado un método polémico para la recuperación de contraseñas en caso de olvido de la contraseña empleada habitualmente. Las clásicas preguntas del nombre de tu mascota, la fecha de nacimiento, o el nombre de la pareja nunca han parecido un método muy seguro para proteger una contraseña. ¿Dejarías entrar en tu casa a cualquiera que sepa en qué colegio estudiaste?
En muchos sitios aún se recurre a las preguntas de seguridad
Son muchos los casos de famosos (París Hilton, Sarah Palin o Scarlett Johansson entre otros) que han visto sus datos y hasta fotos personales al descubierto porque alguien obtuvo su contraseña a través de este mecanismo. Por fortuna cada vez se encuentran menos sitios que recurren a este método para confirmar que quien recupera la contraseña es quien dice ser.
Por otra parte, en los sitios que aún emplean este método… ¿se aplica el mismo nivel de cifrado o seguridad a la pregunta de seguridad que a la contraseña? Conocer la respuesta de esa pregunta puede permitir a un atacante acceder a la cuenta del usuario, por lo que sin duda debería seguir las mismas reglas de seguridad que la propia contraseña. Si se puede acceder a la respuesta de seguridad en texto plano, ¿qué sentido tiene almacenar correctamente el hash de la contraseña?
En este punto sería interesante analizar el tratamiento que los diferentes sitios que aún emplean este método realizan sobre las diferencias tipográficas. Por ejemplo, si la pregunta es la calle en la que naciste, se puede escribir C/ Olmos, calle olmos c/olmos… todas serían igualmente correctas. Se consideran correctas esas variaciones a la hora de recuperar la contraseña o no. Evidentemente si se guarda el hash solo se admitiría una respuesta como correcta si se escribe igual que como se introdujo originalmente.
Nuestra experiencia nos dice que, por lo general, cuando desgraciadamente se usa este burdo sistema de restablecimiento se guardan las cadenas en texto plano; y el fallo al poner mayúsculas-minúsculas simplemente se trata a través de un «case-insensitive» aplicado a la función de comparación de cadenas.
Por fortuna cada vez se emplea menos la pregunta de seguridad y se utilizan opciones más seguras. Entre los métodos más habituales para obtener una nueva contraseña, suele estar la generación de una nueva contraseña aleatoria y temporal, que se envía al usuario e instarle a cambiarla tras entrar en el sistema.
Aunque un método más adecuado, es enviar al correo del usuario una URL única, generada específicamente (y no predecible) y con un tiempo de vida útil (tras el cual debe caducar) que le permita introducir una nueva contraseña. El usuario solo debe seguir el enlace que recibe e introducir la nueva contraseña que solo él conoce. Fácil y mucho más seguro que otros métodos.
La doble autenticación
Por otra parte, en los últimos años son múltiples los servicios online que han introducido un doble factor de autenticación. Generalmente se trata de una opción para los usuarios que desean una protección adicional para sus datos.
Proceso de verificación en dos pasos de Google
Tradicionalmente el doble factor de autenticación solía venir a través de un dispositivo generador de claves. Pero en la actualidad el método más empleado se basa en el uso del teléfono móvil. Al configurar esta opción de autenticación el usuario debe introducir su número de móvil; y cuando precisa autenticarse, tras introducir su contraseña habitual, se le envía por SMS una contraseña de uso único y temporal que le permitirá acceder al servicio. Básicamente es añadir un «lo que tengo» al «lo que se» (tengo un móvil, se una credencial).
Google, LinkedIn, Facebook, Twitter o Evernote ya ofrecen esta función que sin duda añade mayor seguridad a la cuenta del usuario. Algunos de estos servicios, prácticamente se vieron obligados a implementar esta medida tras diferentes ataques sufridos contra sus usuarios y que podrían haberse evitado con un doble factor de autenticación implementado.
Se puede consultar una lista de todos los servicios que ofrecen doble autenticación en twofactorauth.org/, incluyendo las opciones que ofrecen y agrupados por categorías.
Pero como siempre no solo basta que el método de obtención de contraseñas sea seguro, también debe estar correctamente implementado y de forma segura. Un error de desarrollo en la implementación, en cualquiera de los puntos (generación de nuevas contraseñas, al guardarlas en la base de datos, en la comprobación del hash, etc.) puede hacer que el resto de medidas de seguridad implementadas queden en nada. Y que cualquier atacante pueda saltarse el sistema y acceder a los datos de cualquier usuario.

Más información:
Password Storage Cheat Sheet
https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
List of Rainbow Tables
http://project-rainbowcrack.com/table.htm
El lado humano de las contraseñas
http://unaaldia.hispasec.com/2004/12/el-lado-humano-de-las-contrasenas.html
una-al-dia (27/02/2005) La pregunta secreta del caso «Paris Hilton»
http://unaaldia.hispasec.com/2005/02/la-pregunta-secreta-del-caso-hilton.html
una-al-dia (22/09/2008) Ataques «magistrales» de «hackers» mediáticos
http://unaaldia.hispasec.com/2008/09/ataques-de-mediaticos.html
una-al-dia (11/03/2006) Teoría y práctica en la seguridad de las contraseñas
http://www.hispasec.com/unaaldia/2695
una-al-dia (14/10/2011) El culo de Scarlett y el eslabón más débil (I) y (II)
http://unaaldia.hispasec.com/2011/10/el-culo-de-scarlett-y-el-eslabon-mas_14.html
http://unaaldia.hispasec.com/2011/10/el-culo-de-scarlett-y-el-eslabon-mas.html
una-al-dia (26/05/2015) Secretos, mentiras y recuperación de cuentas
http://unaaldia.hispasec.com/2015/05/secretos-mentiras-y-recuperacion-de.html
                                                                                                  
Antonio Ropero
antonior@hispasec.com
Twitter: @aropero

Acerca de Hispasec

Hispasec Ha escrito 6940 publicaciones.

  • View all posts by Hispasec →
  • Blog

Compártelo:

  • Twitter
  • Facebook
  • LinkedIn
  • Reddit
  • Telegram
  • WhatsApp

Publicaciones relacionadas

Publicado en: General

Interacciones con los lectores

Deja una respuesta Cancelar la respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

Barra lateral principal

Buscar

Síguenos

siguenos en twitter

UAD360 EDICIÓN 2022

https://www.youtube.com/watch?v=go_CSWK56yU

Populares de UAD

  • Microsoft lanza parches para 80 vulnerabilidades, 2 0-day(s)
  • USB Killer, el enchufable que puede freir tu equipo
  • Ataques de ransomware VS seguridad en Amazon S3
  • Técnica permite modificar ficheros PDF con firma digital
  • Código fuente de GoDaddy filtrado

Entradas recientes

  • Microsoft lanza parches para 80 vulnerabilidades, 2 0-day(s)
  • Ataques de ransomware VS seguridad en Amazon S3
  • Código fuente de GoDaddy filtrado
  • Account Takeover en AnswerDev (CVE-2023-0744)
  • Vulnerabilidad zero-day en AWS Glue
  • Evasión de CloudTrail en AWS a través de API no documentada
  • Parches de enero 2023: Microsoft corrige 98 vulnerabilidades
  • Correo electrónico
  • Facebook
  • LinkedIn
  • RSS
  • Twitter

Footer

UAD

UAD nació a raíz de un inocente comentario en un canal IRC hace 24 años. A través de los archivos, un lector curioso puede ver cómo ha cambiado (o no) la seguridad de la información desde entonces.

Aviso Legal

  • Aviso Legal
  • Términos y Condiciones
  • Política de Privacidad
  • Política de Cookies

Copyright © 2023 · Hispasec Sistemas, S.L. Todos los derechos reservados

Este sitio web utiliza cookies propias y de terceros para fines analíticos y para mostrarte publicidad (tanto general como personalizada) relacionada con tus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación (por ejemplo, páginas visitadas), para optimizar la web y para poder valorar las opiniones de los servicios consultados por los usuarios. Para administrar o deshabilitar estas cookies haz clic en: Configurar Cookies


Rechazar todo Aceptar Todo
Configurar Cookies

Resumen de privacidad

Este sitio web utiliza cookies para mejorar su experiencia mientras navega por el sitio web. De estas, las cookies que se clasifican como necesarias se almacenan en su navegador, ya que son esenciales para el funcionamiento de las funcionalidades básicas del sitio web. También utilizamos cookies de terceros que nos ayudan a analizar y comprender cómo utiliza este sitio web. Estas cookies se almacenarán en su navegador solo con su consentimiento. También tiene la opción de optar por no recibir estas cookies. Pero la exclusión voluntaria de algunas de estas cookies puede afectar su experiencia de navegación.
Necesaria
Siempre activado
Las cookies necesarias son absolutamente esenciales para que el sitio web funcione correctamente. Estas cookies garantizan funcionalidades básicas y características de seguridad del sitio web, de forma anónima.
CookieDuraciónDescripción
cookielawinfo-checkbox-analytics11 monthsEsta cookie está configurada por el complemento de consentimiento de cookies de GDPR. La cookie se utiliza para almacenar el consentimiento del usuario para las cookies en la categoría "Análisis".
cookielawinfo-checkbox-functional11 monthsLa cookie está configurada por el consentimiento de cookies de GDPR para registrar el consentimiento del usuario para las cookies en la categoría "Funcional".
cookielawinfo-checkbox-necessary11 monthsEsta cookie está configurada por el complemento de consentimiento de cookies de GDPR. Las cookies se utilizan para almacenar el consentimiento del usuario para las cookies en la categoría "Necesario".
cookielawinfo-checkbox-others11 monthsEsta cookie está configurada por el complemento de consentimiento de cookies de GDPR. La cookie se utiliza para almacenar el consentimiento del usuario para las cookies en la categoría "Otro.
cookielawinfo-checkbox-performance11 monthsEsta cookie está configurada por el complemento de consentimiento de cookies de GDPR. La cookie se utiliza para almacenar el consentimiento del usuario para las cookies en la categoría "Rendimiento".
viewed_cookie_policy11 monthsLa cookie está configurada por el complemento de consentimiento de cookies de GDPR y se utiliza para almacenar si el usuario ha dado su consentimiento o no para el uso de cookies. No almacena ningún dato personal.
Analítica
Las cookies analíticas se utilizan para comprender cómo interactúan los visitantes con el sitio web. Estas cookies ayudan a proporcionar información sobre métricas, el número de visitantes, la tasa de rebote, la fuente de tráfico, etc.
GUARDAR Y ACEPTAR