Defensores y detractores. Pero sea como sea esta dupla lleva con nosotros desde hace décadas. Hace muchos años, se entendió que el mejor sistema para autentificar a una persona en el mundo digital era esta combinación. Y es lógico, un usuario y una contraseña es relativamente sencillo de recordar (cumpliendo la premisa de ser simple), era por lo general inequívoca (cumpliendo la premisa de identificar de forma fiable a quien se quiere identificar), y por último era lo suficientemente segura para ser viable, ya que no se dependía solo de un usuario, sino además una cadena que tenía que coincidir.

Estas premisas han hecho que a día de hoy sea el modo de autentificación más extendido en el mundo, digitalmente hablando. Tal es así que el que más o el que menos casi con toda posibilidad contará este tipo de autentificación por decenas.

Bien, pero antes de continuar, es necesario entender como funcionan bien estos usuarios y contraseñas, ya que también han evolucionado con los años enormemente. Puede parecer algo trivial, pero tiene bastante más… “sustancia” de la que podemos imaginar. Además, es nuestro método principal de autentificación, que menos que saber como dios manda como funciona. También veremos los diferentes problemas de seguridad que conllevan su uso.


Funcionamiento Básico de Usuarios y Contraseña

Parece un poco estúpido per sé, todos sabemos que es un usuario y una contraseña… ¿o no?. En una definición simple, un usuario es una cadena de caracteres normalmente no secreta que identifica a la persona dentro del sistema, mientras que la contraseña es, por lo general, una cadena de caracteres secreta, conocida sólo por su dueño, que está asociada de forma íntima al usuario, y que permite su verificación sencillamente por cotejamiento contra el sistema donde queremos autentificarnos.

El modo de funcionamiento de este sistema ha ido evolucionando mucho, por suerte. Pero todos se han basado en la misma premisa:

  1. El interesado crea/genera/… para el servicio indicado la tupla Usuario/Contraseña. Requiere los dos para acceder al servicio, requiere memorizarlo.
  2. El servicio almacena (por lo general en una base de datos de usuarios) dicha tupla de algún modo/formato

A partir de ahí, cuando el interesado quiere volver a ingresar en el sistema para que le autentifique, debe de proporcionar tanto el usuario y contraseña:

  1. El sistema solicita el usuario y contraseña
  2. El sistema realiza una búsqueda en su base de datos (o donde estén almacenadas las credenciales) por el usuario especificado.
  3. Si hay coincidencia, el usuario está en la base de datos, se compara la contraseña suministrada con la almacenada.
  4. Si no hay coincidencia con el usuario o la contraseña suministrada no es igual a la almacenada, se nos denegará el acceso. Si coincide, el sistema entenderá que somos quien decimos que somos y nos dará acceso.

Aunque el esquema anterior es el que se sigue usando como base, ningún sistema que podamos llamar mínimamente seguro y fiable lo aplica de forma estricta. Ver ahora los múltiples problemas que trae consigo ese esquema es fácil, pero recordemos que estamos en 2019, y que diablos.. antes éramos mucho más ingenuos y con mejor voluntad, que por desgracia la que corre en estos tiempos.

En vez de ir enumerando los diferentes posibles esquemas que pueden usarse para la autentificación Usuario/Contraseña, vamos a ver mejor los problemas que engendra, y las diferentes formas que podemos mejorar ese esquema básico para solucionar en lo posible dichos problemas:

  1. Adivinación, Imaginación
  2. Ataques de Fuerza Bruta
  3. Reusabilidad
  4. Ingeniería Social
  5. Robo/Acceso a la base de datos del Sistema
  6. Transmisión de las credenciales y Malware

Adivinación, Imaginación

Esto puede parecer gracioso y un tanto estúpido, pero funciona, ha funcionado desde el principio de los tiempos y seguirá funcionando, normalmente por desconocimiento, y sobre todo, dejadez de cada uno. Reíros, pero a lo largo de los años y simplemente por adivinación, un poco de imaginación y conocimiento, he sacado tantas contraseñas que ya ni recuerdo.

El problema es inherente a la propia contraseña. La contraseña es una cadena que se tiene que memorizar, hay quienes prefieren apuntarlas, pero entonces el problema se multiplicaría y habría que lidiar con otros factores. Dado que la contraseña la solemos memorizar, aun se cae en el error de forma casi mayoritaria de usar como contraseña aquellas cosas que nos son familiares: Números de teléfonos, DNI, fechas importantes (nacimiento, aniversarios..), nombre de mascotas, de animales que nos gustan, libros, series/películas, música…

Bien, ahora cada cual que piense en las contraseñas que tiene establecidas en sus diferentes cuentas… ¿Cuantos caen en ello? La cosa llega al absurdo de que incluso existen contraseñas “famosas” y usadas a lo largo y ancho de la tierra con una gran prominencia: “123456”, “password” o “qwerty” son solo algunos ejemplos.

¿Como podemos luchar contra esto? Bueno, en cuanto al esquema básico usado, este problema de seguridad no se ve afectado por ello. Esto afecta sólo a la parte del usuario. La solución pasa por concienciar a las masas. Todos entendemos que memorizar lo que algunos llaman “contraseñas seguras” es casi imposible, pero hay más opciones. Mi opción favorita es usar de contraseña una frase corta, a la cual podemos ponerle una mayúscula/numero adicional si la queremos hacer aun más segura.

Obviamente lo ideal es usar una cadena alfanumérica de al menos 8 caracteres combinando entre números, mayúsculas, minúsculas… pero entonces estaríamos eliminando la premisa de simplicidad. Esto para mi es capital, porque si un sistema para ser seguro requiere complicarnos la existencia o tener que apuntar la contraseña en algún lado o… entonces no es adecuado. Será seguro, eso no lo dudo, pero no viable para el día a día.

Por favor, de verdad, dejar de usar contraseñas de vuestra vida.


Ataques de Fuerza Bruta

Técnicamente, los ataques de Fuerza Bruta son por lo general 100% efectivos. Cualquier contraseña por compleja que sea, en teoría, puede sacarse por fuerza bruta. La fuerza bruta es el aliado número 1 para el Hacker. “Sólo” requiere una cosa: Tiempo.

A lo largo de los años, he sacado demasiadas contraseñas simplemente adivinándolas, y cuando no ha sido posible, el siguiente vector tengo que reconocer que ha sido este. La fuerza bruta no solo se aplica a usuarios/contraseña, sino a un sin fin de metodologías.

Su funcionamiento es casi tan viejo como la historia, lo único que sucede es que nos aprovechamos de la computación para ello: Probar, Probar y Probar. Hace tiempo también escribí sobre ello AQUI

En teoría, si una contraseña no es más que una cadena de caracteres, y dado que los caracteres a usar son finitos, así como la longitud de las contraseñas, cualquier contraseña se podría averiguar sencillamente probando con todas las combinaciones posibles del espacio de caracteres usados. Algo así como la cuenta de la vieja. Puede parecer algo imposible, pero cuando tenemos equipos que pueden realizar comprobaciones a cientos de miles o millones de contraseñas por segundo, la cosa empieza a tener otro color.

Eso no significa que los ataques de fuerza bruta sean siempre viables (posibles sí, viables no). De este modo, decimos que una contraseña es segura desde este punto de vista, cuando a efectos prácticos no es viable por el tiempo estimado que se requeriría. Y este tiempo va a depender precisamente de la longitud y el espacio de caracteres usados.

El ejemplo más simple: Una contraseña de 4 caracteres sólo numéricos: 4 Caracteres, cada uno de ellos tiene 10 opciones diferentes = 10^4

Es decir, que si comprobásemos una a una 10.000 contraseñas, daríamos con la solución. Dicho de otro modo, probar desde el 0000, 0001, 0002… hasta el 9999. A mano sería complicado, pero un equipo podría probar todo ello en cuestión de segundos, o incluso fracciones de segundos si se realiza de forma local.

La defensa ante este tipo de ataques es por ende asegurarnos que cualquier posible contraseña que tengamos cumple mínimamente una longitud/complejidad suficiente para anular cualquier ataque de fuerza bruta, o incluso de diccionario, no comentados en este artículo. Se ha escrito mucho sobre el asunto y calculando que podríamos considerar realmente una contraseña segura. No hay respuesta para esto, además la tecnología sigue su progreso, y lo que antes era imposible computacionalmente o por las redes de entonces, hoy es posible, y dentro de unos años lo que hoy consideraríamos seguro, podría ser insuficiente.

¿En lo personal, que considero seguro? Bueno, podemos siempre usar una contraseña más sencilla a costa de una mayor longitud, o primera mayor complejidad sin ser necesaria una longitud alta. En el artículo que he enlazado anteriormente pongo algunos números. En este caso hablamos sobre todo de autentificaciones online, no locales, lo cual hace que el proceso de un ataque de fuerza bruta sea mucho más lento. En mi opinión:

-Sólo Numéricas: Usar al menos 11-12 cifras. Requeriría años. 10 Cifras sería posible pasarla solo en unos pocos meses, lo que quedaría dentro de lo viable.

-Solo letras minúsculas ó mayúsculas: Tenemos 26 caracteres un espacio mucho mayor que solo 10 números. En este caso a partir de 8 letras debería de ser suficientemente seguro, 7 letras caería en lo posible (en el régimen de meses)

-Mayúsculas y Minúsculas: 26+26 caracteres. A partir de 7 caracteres, 6 sería relativamente viable

-Letras y Números: 26+26+10. 6 caracteres serían suficiente en principio, por ejemplo: “Do1Re2”, aunque parezca corta, un ataque online (no local), entraría en años.

Son valores muy por encima, y repito, siempre en ámbito “online”. Esos valores serían muy insuficientes si se lanzasen sobre contraseñas locales. Esto es debido a que no es lo mismo depender de las estructuras de red, que depender solo del potencial de la CPU/GPU

¿Mi consejo? Soy práctico, una pequeña frase corta con sentido solo para cada uno. Si se usan espacios y sólo minúsculas tendremos un espacio de caracteres de 26+33, y una frase corta se escribe y recuerda fácil. Lo único que tendríamos que tener más cuidado sería con ataques de diccionario, pero con más de 3-4 palabras tampoco serían viable, o incluir una palabra no existente. Un ejemplo simple:

“Mi casa”

Longitud = 7, complejidad = 26+26+33. Un ataque online tardaría decenas de años, algo tan “simple” como eso. Por supuesto se podría hacer aun mejor para evitar diccionarios y otros: “Mi cas@”

Repito una vez más, hablamos de ataques online, no locales, donde estas complejidades no serían suficiente. Por su parte, y para terminar, es buena política que los propios servicios nos obliguen a crear contraseñas que cumplan un mínimo de seguridad, siendo por tanto un paso más a la hora de forzar una seguridad mayor.


Rehusabilidad

Este es otro gran problema de los usuarios y contraseñas. Todos tendemos a reusarlas, y sí, yo me incluyo. Obviamente no uso una sola contraseña para todo, pero tampoco puedo decir que uso una contraseña diferente para cada cosa, sería imposible para mi, ¿decenas de servicios con diferentes contraseñas y otro puñado diferente de usuarios? Imposible… al menos, en principio.

Nuestra memoria es limitada, y, o usamos trucos memotécnicos, o gestores de contraseñas, o repetimos antes o después. Pero… ¿por qué es tan peligroso el usar la misma contraseña en varios servicios? Porque si esa contraseña es expuesta por cualquier motivo, no solo expondremos un servicio, sino todos los que usamos con ella. Te robo la contraseña de Facebook, y es posible que logre con ello la contraseña de Instagram, el correo electrónico…

Si no podemos memorizar todo, podemos emplear diferentes técnicas:

  1. Trucos Memotécnicos: Usar una sola contraseña “fija” pero derivarla para cada servicio, o usar contraseñas diferentes también dependiendo del servicio en el que el propio servicio nos sirva de contraseña en nuestra cabeza… por ejemplo para Google = 6Letras. Tontería, sí, pero funciona.
  2. Gestores de Contraseña: En lo personal, me he rendido ante su uso. Nunca me han entusiasmado, pero es un modo “seguro” y ordenado de guardar todas nuestras credenciales. Básicamente los gestores de contraseñas mantienen una base de datos/archivo fuertemente cifrado. En conjunto con extensiones de navegadores Webs, aplicaciones móviles… nos permiten no guardar jamás una sola contraseña en ellos (recordados en el navegador por ejemplo), tener contraseñas únicas y complejas, y simplemente tener el gestor de fondo interactuando con nuestros navegadores.
  3. Usar contraseñas separadas. Para cualquier servicio que sea más crítico, usar siempre contraseñas únicas o en combinación con otros métodos que veremos más tarde, mientras que podemos tener contraseñas mucho más simples y rápidas para cosas que incluso en el peor de los casos no nos importaría mucho que nos robasen.
  4. Tener una memoria privilegiada que sea capaz de mantener contraseñas complejas para cada servicio de forma única… no es mi caso.

En cualquier caso… por favor, no uséis la misma contraseña para todo. Las últimas brechas de seguridad con cientos de millones de credenciales de seguridad lo dejan bien claro.

Algunos sistemas/servicios que queremos acceder toman medidas para evitar el rehuso. Algunas medidas es obligar el cambio de contraseña cada X días, impedir el uso de contraseñas que ya se han usado..


Ingeniería Social

Parece increíble, pero al margen de las contraseñas frágiles, este problema es el que se lleva de la mano el mayor índice de contraseñas robadas (sin incluir las brechas de seguridad, que son muy escasas pero de gran extensión)

La ingeniería social no es un harte Hacker, no hay que ser físico nuclear, ni colarse en sistemas super protegidos. Simplemente se trata de conocer a tu enemigo, ser ingenioso… y por supuesto, mentir como un bellaco de forma que parezca creíble.

Aquí tendríamos técnicas como el Spoofing o el Phising, algo que ya dediqué en su día largo y tendido. Por lo general hay dos formas habituales de pertrechar un ataque de este tipo.

El primero es induciendo o intentando que la víctima acceda a una web falsa que le solicita unas credenciales concretas, que al ponerlas lo que hará será enviárselas al atacante. El segundo, es hacerse pasar por amigo/familiar/empresa… y solicitar datos más o menos importantes que podrían llevar a dar con la contraseña, o incluso solicitar la contraseña directamente, a fin de cuenta si nos creemos que el correo es de nuestro padre/madre y que la necesita para algo, se la daremos…

Protegerse de este tipo de ataques es más sencillo, solo hay que tener cuidado. Recordar que si un sistema es fiable, ni siquiera el propio sistema debería de conocer nuestra contraseña, en todo caso resetearla por otra. Eso significa que jamás le demos nuestra contraseña a nadie, diga quien diga que sea.

Protegerse del Phising es fácil también, aunque algo más complicado para los móviles/tablets donde la URL por lo general se corta. Aquí el modo a seguir es simple… asegurarnos siempre al 1000% que la web que estamos visitando es realmente la que dice ser, desconfiar siempre de correos electrónicos digan lo que digan si nos instan a identificarnos o cambiar contraseñas o…

Más adelante detallaré el ataque más persistente que recuerdo que se está aun llevando a cabo a millones de personas, en el que se mezcla la ingeniería social, con brecha de seguridad, con reusabilidad..

Desde el punto de vista de los sistemas, lo tienen complicado protegerse de estos ataques. Una buena información a sus usuarios, uso de técnicas contra el SPAM como dmarc se hacen obligatorias.


Robo/Acceso a la base de datos del Sistema

Uno de los mayores peligros en el uso de usuarios y contraseñas, es que nuestras credenciales tienen que ser almacenadas en los servidores de los servicios/sistemas que nos tienen que identificar, como hemos dicho estos sistemas tienen que cotejar nuestros datos con los que ellos tienen. En un mundo ideal en el que fuese imposible para nadie acceder a dichas bases de datos no habría problema, pero… ¿que pasaría un hacker o un fallo de seguridad expone dicha base de datos? Pues que de un plumazo quedarían expuestas las credenciales de miles, decenas de miles o incluso decenas de millones de usuarios. Obviamente este tipo de brechas de seguridad son raras, pero suceden, y cuando suceden son millones los afectados.

Por desgracia, la única manera fiable de que esto no suceda es no usando sistemas de usuario/contraseña, más adelante, en otros capítulos de esta serie, veremos como existen sistemas de autentificación que no tienen estos problemas.

Eso no quiere decir de todos modos que no existan técnicas no sólo para evitar los accesos no autorizados en sí a la base de datos, sino para que los datos que contiene, en caso de ser robada o accedida ilegítimamente, no tenga información de extrema sensibilidad.

En nuestro esquema base, decíamos que al crear la cuenta, nuestras credenciales eran insertadas en la base de datos del servicio que fuese, y se usaría luego para compararlas cuando iniciásemos sesión. Eso implicaría almacenar la contraseña en lo que llamamos texto plano, lo cual siempre es un peligro. En un sistema que sea seguro, la contraseña jamás tendría que ser conocida ni siquiera por el proveedor del servicio, es decir, jamás se debería de almacenar en texto plano, además, no es necesario.

En criptografía, es bien conocido el término de Hash. Un Hash es un algoritmo de un solo camino que es capaz de tomar cualquier entrada y convertirla a una cadena de una longitud fija. Los Hash tienen propiedades muy interesantes. Un Hash siempre dará la misma salida para exactamente la misma entrada, pero si se modificase aunque fuese un solo bit en la entrada, el hash se modificaría por completo. Esto hace al Hash ideal para verificar la integridad de los datos por ejemplo, se calcula el hash en origen, se envían los datos y en destino se vuelve a comprobar el mismo hash, si es igual al que se calculó en origen, los datos no han sido modificados.

Otra peculiaridad de los Hash, es que al contrario que el cifrado, un Hash no es reversible, es imposible obtener la entrada a partir de la salida. Es más, dado que los hash tienen una longitud fija (dependiendo del algoritmo usado tendrá una u otra) y la entrada es totalmente arbitraria, diferentes entradas podrían en un casual producir salidas iguales. A esto se llama colisión, y de cara a la seguridad del Hash es primordial. No obstante, por lo general, usamos hash con salidas grandes. El viejo MD5 está cada vez más en deshuso, con una salida de 128bits. Actualmente los Hash más usados, por citar algunos, serían MD5 (aun), SHA-1, SHA256, HMAC…

Esta peculiaridad de los Hash, esta transformación unidireccional que pueden aplicar, se usa además para comprobar integridad, para crear derivados únicos de datos sensibles. Esto es muy útil para almacenar contraseñas sin necesidad de cifrarlas, o para anonimizar datos. Con todo ello ya podemos imaginar por tanto como va a funcionar la cosa…

En cualquier esquema que se precie, el sistema/servicio jamás almacenará la contraseña del usuario, en vez de eso almacenará por ejemplo un hash de dicha contraseña. Para el usuario que quiere acceder es indiferente, porque cuando el sistema quiera cotejar la contraseña insertada por el usuario, este la transformará con el mismo hash, y será el hash de la contraeña el que se busque correspondencia.

Ante una brecha de seguridad, tan solo se podría acceder a los hash de las contraseñas, no a las contraseñas mismas. Dado que los hash son funciones de una sola dirección, en teoría es complicado obtener las contraseñas reales. Por supuesto no es oro todo lo que reluce, y ante esto también hay ataques, generalmente con lo que se llaman tablas arcoíris, tablas precalculadas de hash de todo tipo de contraseñas. Algo así como una tabla creada por fuerza bruta que contiene la lista de millones de posibles contraseñas y su hash correspondiente. De este modo los hachers comparan los hash con el delas tablas arcoiris, y si identifican un hash en su tabla, ya sabrán la contraseña asociada.

En cualquier caso, aunque las tablas arcoiris son muy eficientes y rápidas, por lo general su efectividad es limitada, volveríamos a la necesidad de contraseñas más o menos seguras. Pero no olvidemos algo, en caso de brecha de seguridad todo ese tipo de ataques ya no serían sobre internet, serían en local, un hacker podría someter la base de datos robada a un análisis exhaustivo en su equipo o en centros de datos mucho más potentes para buscar correspondencias en tablas arcoíris y poder “revertir” muchos hash.

Debido a esto, y para luchar contra los ataques de fuerza bruta y las tablas arcoiris, hace muchos años que alguien inventó lo que hoy conocemos como “Sal” (Salt en ingles). La Sal suele ser una pequeña cadena de bytes aleatorios que se añade/intercala a la contraseña antes de realizarle el hash. Esto puede parecer un sinsentido, pero evita enormemente que cualquier ataque de fuerza bruta, de diccionario o de tabla arcoiris pueda afectar a contraseñas débiles o poco seguras. Cualquier añadido que le hagamos a la contraseña de forma automática, invalidaría cualquier intento en una tabla arcoiris o en cualquier ataque de fuerza bruta, ya que la contraseña usada sería diferente. La Sal suele ser única para cada contraseña, y se almacena en la base de datos como texto plano. Pero entonces ¿no podrían también robar la Sal, y con ello poder crear tablas arcoiris? Claro que sí, la cuestión está que precalcular las tablas arcoíris requiere una enorme cantidad de tiempo, cuantos más caracteres de entrada tengamos mucho más! eso implica que el hacker tendría que recrear las tablas arcoiris para cada usuario, no podría nunca reusarlas porque la Sal en cada uno es diferente. Precisamente las tablas arcoiris son tan útiles porque aunque se tarde años en calcular tablas maravillosas, luego puedes usarlas una y otra vez, y los resultados son casi instantáneos si el hash ya se ha computado. Pero claro, si hay Sal por medio, dichas tablas no valen para nada.

Para el usuario esto es también transparente, simplemente el sistema además de almacenar usuario y contraseña, almacenaría la Sal usada. El usuario al identificarse solo pondría su contraseña, el sistema leería la Sal de la base de datos, se la añadiría, calcularía el Hash y lo comprovaría con el almacenado.

Como última medida, se podría directamente cifrar el contenido de la base de datos, añadiría complejidad al sistema y lentitud. Además, se deberí ade usar una clave para cada entrada, si fuese una sola contraseña general para todos y fuese igualmente filtrada o averiguada, permitiría desencriptar toda la base de datos.

Nosotros, como usuarios, no podemos evitar las brechas de seguridad. Pero eso no significa que no podamos hacer nada:

  1. Cambiar las contraseña de cuando en cuando, esto impide que brechas de seguridad viejas afecten a nuestras cuentas a día de hoy.
  2. Usar contraseñas decentes, mejora la resistencia frente a posibles ataques.
  3. Fiarnos siempre de los servicios a usar, no todos usan buenas políticas, a día de hoy aun hay miles/cientos de miles de servicios que siguen almacenando las contraseñas en formato plano.
  4. Esta web nos permite de forma rápida saber si en algún momento alguna brecha de seguridad de algún servicio expuso nuestra contraseña. Puede ser vieja, puede ser actual… no significa que no estar ahí implique que estamos a salvo, pero es un buen comienzo

Para entender la importancia de las brechas de seguridad, pensemos que no hace ni 2 días (a fecha de 20 de Enero), que Facebook tuvo que reconocer que cientos de millones de contraseñas de cuentas de Facebook e Instagram se habían estado registrado/guardando en texto plano (sin hasheo, sin encriptación, nada). Aunque aseguraron que no tenían constancia que hackers pudiesen a ver accedido a ellas, si reconocen que sus empleados tuvieron accesos, y de echo se sabe que se realizaron miles de búsquedas en dicha base de datos de sus propios empleados. Dicho de otro modo si se prefiere, las contraseñas de cientos de millones de personas han estado expuesta a sabe dios quien.

La única solución efectiva ante este tipo de ataques y problemas, los veremos más adelante, como por ejemplo sistemas que no intercambian información sensible como contraseñas, o sistemas de doble autentificación.


Transmisión de Credenciales y Malware

Para acabar, y no menos importante, está el problema que conlleva el tener que usar una cadena concreta como la contraseña. Ya hemos visto el peligro que acarrea que las bases de datos externas tengan que almacenarlas, pero también es un peligro cada vez que las usamos.

Hay diferentes “lugares” o “puntos” en los que nuestras contraseñas deberían de estar protegidas. Si una contraseña es tan importante, al igual que se almacenan de forma codificada en los servidores (al menos deberían), tendríamos que tomar las medidas igualmente adecuadas para asegurarnos que llegan al destino sin que nadie pueda interceptarlas.

El primer problema aquí estaría en nuestro propio equipo, cuya responsabilidad es nuestra. Un sistema puede ser extremadamente seguro, pero si tenemos un malware que registra cada tecla que presionamos, estaremos dándole a atacantes todas las contraseñas que quieran. Los KeyLogger son demasiado habituales a día de hoy como no tenerlos en cuenta. Ante esto, lo único posible es tener buenas políticas de saneamiento de nuestros equipos, no instalar nada que sea dudoso, y ante la duda pasarlo por antivirus, mi recomendación siempre: Virustotal.

Pero ahí no se acaban los problemas, solo empiezan. Muchas webs solicitan las contraseñas en sus formularios de inicio de sesión o registro de forma directa, es decir, no las transforman antes de ser enviadas. Al igual que se puede guardar la contraseña en una base de datos de forma “codificada” con un Hash, el código de la página web del servicio en cuestión podría igualmente optar por medidas como codificar directamente a algún hash la contraseña antes de ser enviada. Esto hay muchos que no lo comparten, puesto que si alguien intercepta nuestro tráfico, aun cuando se estuviese transmitiendo un hash, podrían en principio clonar la sesión o hacer uso del mismo hash para identificarse. Es verdad que el sistema no es perfecto, pero al menos no conocerían nuestra contraseña real, ya que esta no se transferiría nunca como tal

Pero quizás la medida más importante, sea el asegurarnos que cualquier contraseña o dato sensible que pudiese transferirse a través de internet, va cifrado, al margen de que la contraseña vaya protegida o no. Y sí, hablamos obviamente de que las páginas visitas estén siempre protegidas por certificados digitales y sea posible su navegación por protocolo seguro HTTPs.

Cuando conectamos por HTTPs, todo el tráfico entre el servidor remoto y nuestro PC, es cifrado extremo a extremo, sin que nadie en medio pueda saber la transmisión de datos, sean sensibles o no. Esto cuando transmitimos datos “sensibles” es de vital importancia. Pensar que es extremadamente sencillo colocar un analizador de paquetes en una red cualquiera y realizar ataques de Man-in-the-Middle (MiTM). Peor aun, quien nos dice que la red WIFI a la que nos conectamos en el trabajo, en la universidad, en casa de vecinos/amigos… ¿es segura?

Este experimento lo he realizado varias veces. Se trata sencillamente de crear una red de “invitados” en mi Router sin ningún tipo de seguridad, para que se conecten a ella quien quiera. Luego, como el Router lo control completamente, me es muy sencillo crear un “proxy” transparente de modo que el 100% del tráfico que esa red genere me sea reenviado y poder ver así absolutamente todo lo que hacen. Bien, pues es bien simple, todo el tráfico que no vaya cifrado, aparecerá tal cual por delante de mis ojos, incluyendo contraseñas si se están transmitiendo en plano:

POST /wp-login.php HTTP/1.1
Host: miblog.com
Content-Length: 123
Cache-Control: max-age=0
Origin: http://miblog.com
Upgrade-Insecure-Requests: 1
DNT: 1
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3739.1 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3
Referer: http://miblog.com/wp-login.php?loggedout=true
Accept-Encoding: gzip, deflate
Accept-Language: en,en-US;q=0.9,es;q=0.8
Cookie: viewed_cookie_policy=yes;
Connection: close
log=Admin&pwd=MyPassword&wp-submit=Acceder&redirect_to=http%3A%2F%2Fmiblog.com%2Fwp-admin%2F&testcookie=1

Cuando se transfiere la página por HTTPs, en principio todo el tráfico que podría leerse estaría cifrado. No obstante, técnicamente es posible también intentar usar ataques de inyección de certificados, pero por la propia naturaleza de estos, quien visitase dichas páginas vería avisos de seguridad.

Lo que está claro es que, al margen de que un Hacker puede buscar mil vueltas para llevar a cabo sus designios, tenemos que tener siempre un mínimo de cuidado. Y en cuanto a contraseñas se refieren, jamás, pase lo que pase, introducir una credencial o cualquier dato que pueda ser sensible en una página que no está bajo conexión segura, y con un certificado válido.

Cada vez más se usan certificados digitales en los servidores Web para proteger las transmisiones (Gracias Let’s Encrypt!!) , pero esto también propicia a que los programadores y los encargados en diseñar los sistemas presupongan que las comunicaciones siempre se harán bajo HTTPs, con lo que no toman medidas a la hora de “codificar” los datos sensibles antes de que salgan del propio navegador del usuario. En el ejemplo anterior, vemos que WordPress no codifica las contraseñas, las transmite en plano. A día de hoy posiblemente más de un 30% de las webs sean WordPress, pero el porcentaje de todas ellas que usan HTTPs es “pequeño”. Eso significa un numero ingente de páginas, algunas bien conocidas, que pueden transmitir los datos al servidor de forma clara, tan clara que cualquiera podría interceptarlos.


El nuevo ataque que está causando estragos desde hace meses, y apuntes finales

Me gustaría terminar con los usuarios y contraseñas con un ataque real que se lleva realizando desde hace meses, y es extremadamente peligroso por el ingenio que hay detrás, y por desgracia el miedo y el desconocimiento del usuario.

El uso de este sistema de autentificación es obsoleto, aunque muy cómodo, hasta el punto que continuamos usándolo por defecto y de forma mayoritaria. Los problemas que tiene son muchos, y aunque hay “soluciones” parciales a parte de ellos, es algo que tenemos que tener bien presente, y a medida que sea posible, migrar nuestros sistemas tradicionales a otros mucho más seguros, que veremos en otros artículos.

Quien no esté al tanto, en los últimos meses se han ido filtrando listados de cientos de millones de credenciales, provenientes de muy variados servicios de en los que en algún momento dado alguien logró acceso a sus bases de datos. Repito, hablo de listados de cientos de millones de usuarios-contraseña, perteneciente a todo tipo de servicios, algunos más conocidos otros menos. Por supuesto, muchas de esas brechas de seguridad son viejas, cuentas de hace años muchas abandonadas u olvidadas, y contraseñas igualmente viejas. Otras mucas en cambio son recientes…

En números… tengo por ahí el último leak masivo, hablamos de TeraBytes de información, solo en listados.

Bien, eso es el precio a pagar a usar usuarios/contraseñas, y servicios mal protegidos o con políticas deficientes. A raiz de estas filtraciones masivas, muchos pensaron como sacarle rédito… muchas credenciales aun son válidas, pero hablamos de cientos de millones, como sacar partido a todo ello.

En algún momento de estos meses atrás, a saber quien fue el primero al que se le ocurrió la idea, se puso en marcha un ingenioso ataque masivo, usando como base dichas filtraciones, sin importar realmente que los datos que contenían seguían siendo válidos o no, ya que para sus intenciones esto realmente daba igual.

  1. El ataque trataba en enviar de forma masiva correos electrónicos a las cuentas de correo que venían en las filtraciones, que como ya he dicho eran de diferentes servicios, no necesariamente a servicios de correo electrónico, pero sabemos que el correo electrónico suele usarse como usuario. Con lo que el primer daño estaba hecho, miles de millones de correos electrónico expuestos, ideal también para los Spammers
  2. Para meter miedo y llamar la atención, en el asunto del mensaje se especificaba algo como: “Conozco tu contraseña: 123456”, siendo 123456 la contraseña que se había filtrado junto al usuario dado que normalmente es el correo electrónico. Obviamente esa contraseña podría ser vieja, podría ser de cualquier servicio, pero sea como sea las filtraciones son reales, así que el usuario lo que ve en su correo es que alguien le ha enviado un correo y en el asunto reconoce una contraseña de él.
  3. Se redactaba un correo intimidatorio, diciendo que era un hacker, que se había apoderado de su PC e instalado software malintencionado, que lo estaba vigilando por la cámara Web, que sabía todo lo que hacía… y que como prueba de todo ello sabía su contraseña, especificada en el asunto. Hay muchas versiones, en algunas intimidan diciendo que conocen todas las webs pornográficas visitas, otras que tienen material sensible de ellos, otras que… en realidad son correos genéricos cuyo texto podría más o menor cuadrar en el 80% de la población, similar a los horóscopos, escribes algo genérico que casi todo el mundo cumplirá, y le das tintes de veracidad con la contraseña o cualquier otra cosa. Todo Mentira, obviamente, simplemente te mandan dicho correo que se filtro enalgún momento tu correo electrónico y posiblemente la contraseña de algún servicio.
  4. Por último, se insta a realizar un pago en bitcoins como extorsion para evitar que los datos comprometidos que supuestamente tienen de nosotros vean la luz.

Bien, puede parecer una tontería, pero muchos se han hecho de oro. Haciendo uso de filtraciones viejas, ingeniería social, instigar miedo, dar tintes de realidad con datos que supuestamente tienen de nosotros… cuando la triste realidad es otra, es todo mentira, no son hackers, no tiene nada, en el mejor de los casos una contraseña, que de ser cierto que la usamos en ese mismo momento en algún servicio, sería bueno cambiarla de inmediato. Os dejo la imagen de un correo de este tipo que ha estado dando guerra desde hace meses, aunque es verdad que hace ya uno o dos meses que no me llegan detalles de que se siga usando, pero si algo hemos aprendido de los ataques informáticos, es que tarde o temprano volverá:

Es hora de avanzar, no es malo seguir usando usuarios/contraseñas, pero podemos usarlos en conjunción de otros sistemas que eviten las sorpresas, o incluso sustituirlos por completo. Lo que está claro es que si queremos una autentificación fiable, segura y sin riesgo, hacerla por usuario/contraseña implica muchos riesgos.

Hay una frase que me encanta, y que usaremos por aquí en varias ocasiones, en relación a cuando un sistema podemos considerarlo seguro, cuando este esté protegido por: “Una cosa que seamos, Una cosa que tengamos y una Cosa que sepamos”

Las contraseñas, a fin de cuenta, cumplen el tercer requerimiento, es algo, en teoría, que solo nosotros deberíamos de saber.