Por qué no es una buena idea reutilizar contraseñas (el caso HSBC)

Por qué no es una buena idea reutilizar contraseñas (el caso HSBC)

Hace pocos días uno de los bancos más grandes el mundo, HSBC, confirmó que algunos de sus clientes en los Estados Unidos fueron víctimas de un ataque conocido como credential stuffing.

Este tipo de ataque utiliza nombres de usuario y contraseñas previamente comprometidos para obtener acceso a otros servicios. En respuesta a la BBC, el banco informó:

HSBC lamenta este incidente, y tomamos la responsabilidad de proteger a nuestros clientes muy en serio. Hemos notificado a los clientes cuyas cuentas han podido ser víctimas de este acceso no autorizado, y les hemos ofrecido un año de servicio de monitoreo de crédito –credit monitoring- y protección de robo de identidad -identity theft protection-.

HSBC confirmó que las cuentas de los clientes fueron accedidas durante los primeros quince días del mes de Octubre, y que la violación de datos incluyó nombres y apellidos de los clientes, su dirección postal, números de teléfonos, direcciones de e-mail, fecha de nacimiento, número y tipo de cuenta, historial de transacciones y saldo de sus cuentas.

Responsabilidad compartida

Podríamos culpar al usuario por haber reutilizado las contraseñas, pero también al banco por no haber implementado los mecanismos de seguridad necesarios para prevenir este tipo de hechos (autenticación de dos pasos, bloqueo por repetidos intentos de inicio de sesión fallidos, etc).

Administradores de contraseñas

Como explicaba hace un tiempo en este post, ningún ser humano puede recordar una contraseña única para cada sitio/servicio online, a menos que solo tenga una cuenta de e-mail y una de redes sociales. Pero todos sabemos que en la mayoría de los casos, son muchas más que solo dos. Yo, por ejemplo, tengo al día de publicación de este post 359 cuentas en LastPass.

Para liberarnos de este dolor de cabeza están los administradores de contraseñas, que no solo nos evitan tener que recordar cada contraseña, sino que nos ayudan a usar contraseñas fuertes y únicas.

Adicionalmente, LastPass y 1Password verifican periodicamente que las contraseñas guardadas en nuestras “cajas fuertes” no hayan aparecido en alguna violación de datos. Para ello utilizan servicios como el de Have I Been Pwned, que recomiendo con total seguridad.

Autenticación de dos pasos

Si HSBC hubiese obligado a sus clientes a utilizar un mecanismo de autenticación de dos pasos para acceder a sus cuentas, esta situación podría haberse evitado por completo.

Algunos bancos, como ocurre en Argentina, solicitan a sus clientes el ingreso de un token solo durante la ejecución de transacciones específicas pero no para acceder a sus cuentas.

La autenticación de dos pasos -doble factor de autenticación, 2FA, MFA- obliga al usuario a combinar dos métodos de autenticación entre los siguientes:

  • Algo que sabe (un usuario y una contraseña).
  • Algo que tiene (un token físico o virtual, una llave de autenticación, una smart-card).
  • Algo que es (su huella digital, sus rasgos faciales, su retina, entre otros).

En este post hablo más sobre la autenticación de dos pasos, y doy algunos ejemplos de configuración.

Notas finales

Cada uno de nosotros es responsable de su propia seguridad. Ya lo menciona Twitter en sus términos de uso:

Usted es responsable de la seguridad de su cuenta, por lo que debe usar una contraseña fuerte y limitar su uso a esta cuenta. No podemos ser considerados responsables, ni lo seremos, de ninguna pérdida o daño derivado de su incumplimiento de las anteriores condiciones.

Queda claro que en este caso se sumaron varios sucesos desafortunados: el usuario que reutilizó contraseñas, el banco que no pensó en la importancia de obligar a sus clientes a utilizar un segundo factor de autenticación, o -y este es un llamado de atención para los administradores de sitios web- que no instrumentó las acciones necesarias para asegurarse que ningún usuario pudiera utilizar una contraseña que ya hubiese sido identificada en alguna violación de datos.

GitHub, la plataforma de alojamiento de código fuente y desarrollo colaborativo, introdujo hace algunos meses una nueva funcionalidad que les permite verificación si la contraseña que el usuario está utilizando en su sitio ya fue identificada en alguna violación de datos . Todos los detalles están en este post.

Pero no nos olvidemos que, finalmente, quien debe ser responsable ante la ley por este hecho es el atacante.