“Tranquilo, hemos hasheado sus datos personales” o ¿Cómo reidentificar el 97% de los emails que venden los data brokers?
Email hasheado: irreversible pero identificable.
Si tu empresa usa el píxel de Meta, Customer Match o LiveRamp, tu política de privacidad probablemente diga algo que un reciente paper de Yale ha demostrado que es falso. Y esto ni siquiera era una novedad.
Si tu empresa usa el píxel de Meta, Customer Match o LiveRamp, tu política de privacidad probablemente diga algo que un paper de Yale acaba de demostrar que es falso. Y que ni siquiera era una novedad.
Muchos nos hemos encontrado con panfletos publicitarios o -mucho peor- contratos de empresas de publicidad dicen cosas como “si nos pasas los listados de tus clientes o usuarios -sus identificadores, como emails o teléfonos-, los cruzaremos con nuestras propias bases y así optimizaremos la audiencia, encontraremos lookalikes, y maximizaremos el ratio de match perfecto para su campaña”.
Y aquí viene lo bueno: “No preocuparse, nunca podremos leer esos identificadores: los anonimizamos mediante una “función hash” o los convertimos en hashes antes de subirlos a nuestra plataforma, y por eso no podemos leerlos”.
¡JA!
1.- ¿Cara o cruz?
Si lanzo una moneda al aire y oculto el resultado, tú nunca podrás saber si ha salido cara o cruz.
Tampoco podrás saberlo si te digo que he hasheado el resultado y te lo muestro:
El resultado ha sido: “f61f5c5e22749aeba2bd920352dbd4c9f63e0ebaed6df623b09c836ffcbec2eb”
¿O sí puedo saberlo?
Claro que puedo saberlo: necesito saber que función hash has utilizado y hashear los dos resultados posibles. De un vistazo sabré si salió cara o cruz.
Ahora es mucho más fácil entender un ejemplo un poco menos tonto.
Meta, al explicar el “advanced matching” de su Meta pixel, dice que recoge el dato de género de sus usuarios (masculino “m” o “f” femenino) y luego lo “hashea” y se jacta de que con eso protege la privacidad del usuario porque ¿Quién podría saber que, por ejemplo “62c66a7a5dd70c3146618063c344e531e6d4b59e379808443ce962b3abd63c5a” es “masculino”?
De nuevo: volver a extraer el valor original “m” de “
62c66a7a5dd70c3146618063c344e531e6d4b59e379808443ce962b3abd63c5a” es imposible.
El problema es que no hace falta:
Sólo hay dos opciones:
“m”: 62c66a7a5dd70c3146618063c344e531e6d4b59e379808443ce962b3abd63c5a
“f”: 252f10c83610ebca1a059c0bae8255eba2f95be4d1d7bcfa89d7248a82d9f111
La primera es “masculino” y segunda es “femenino”.
Ergo la protección de ese atributo es, en realidad, nula.
Como la del cara o cruz.
Los expertos en criptografía hablan en sánscrito pero el concepto es sencillo, ¿verdad?.
Vamos con otro ejemplo un poco menos tonto.
2.- Cómo saber quién ganará el balón de oro
Imaginen que les digo que le he instalado Pegasus a la persona que cuenta los votos para elegir el Balón de Oro y que le he interceptado la comunicación en la que revela el ganador. Pero esta persona era cuidadosa y había “hasheado” el nombre antes de enviarlo.
El ganador es:
“8cf7dd0d99b272e32d34a6a18dd87b1ddde9b297aa6b0980c1d6a75ef7a886d6”
Sí, lamentablemente el nombre del afortunado venía hasheado con SHA-256. Imposible de crackear.
Como los candidatos son sólo 30, simplemente podemos “hashear” uno a uno o todos de una tacada y comparar, y el match será el ganador.
Pueden jugar a hacerlo en este artefacto.
France Football guarda el nombre del ganador en un sobre cerrado. Imagina que solo publicaran su hash.
El 26 de octubre se entrega el Balón de Oro 2026. Aquí abajo hay un sobre con el nombre del ganador convertido en SHA-256, la misma técnica con la que el sector de los datos "anonimiza" tu correo y tu móvil. Tu misión: abrirlo. Te llevará menos de un minuto.
Prueba a adivinarlo
Escribe el nombre de un futbolista. El navegador calcula su SHA-256 y lo compara con el sello. Un hash se puede calcular hacia delante todas las veces que quieras; lo único que hace falta es tener el candidato.
Antes de cifrar se pasa todo a minúsculas y se quitan las tildes (Kylian Mbappé → kylian mbappe). Los brokers hacen exactamente esta limpieza, porque un hash cambia por completo con una sola letra distinta y sin normalizar no podrían cruzar sus bases.
Construye un diccionario
Adivinar uno a uno cansa. Pero el universo de candidatos es público y pequeño: los 30 nominados oficiales. Cifra los 30 de golpe, guarda los resultados y compara cada uno con el sello. Eso es un diccionario. Puedes pinchar en cualquier tarjeta para cifrarla suelta, o lanzar los 30 seguidos.
El sello sigue siendo tan irreversible como te prometieron. Da igual: nadie ha tenido que invertir nada. Se ha cifrado a los 30 candidatos y se ha mirado cuál coincidía. Un hash sin sal es un seudónimo con la llave puesta.
Si hiciéramos este ejercicio con los números de móvil de España, el diccionario tendría 200 millones de posibilidades. A lo burro, con un script sencillo en un portátil normal, tardaríamos unos tres minutos en recorrerlo entero. Con técnicas triviales, mucho menos: usando todos los núcleos del procesador, medio minuto; con la tarjeta gráfica de un ordenador de juegos, una centésima de segundo; y si el diccionario ya está construido y guardado en disco (8 GB), reidentificar un número concreto es una consulta instantánea.
Lista oficial de nominados publicada por France Football el 8 de septiembre de 2026. El nombre sellado es la apuesta del autor; la gala se celebra el 26 de octubre en Londres.
Todos estos transparentes ejemplos provienen del mismo paper: “Anonymity, Consent, And Other Noble Lies: An Empirical Study of The Data Economy” de Reardon, Egelmann y otros.
Todos ustedes deberían leer este paper: es tan demoledor, preciso y transparente en sus explicaciones como cualquiera de los de Daniel Solove.
Hay otros deliciosos momentos como las citas de abogados de Meta alegando argumentos contrarios en distintos juicios, dependiendo del interés defendido en cada momento.
En Meta Pixel Healthcare sostiene que envía información desidentificada, y en Meta v. BrandTotal su perito declara que hashear IDs de usuario no anonimiza.
Ah, malditos abogados.
No por causalidad está citado en nuestro propio paper «Prompt like a Butterfly, Sting like a Tracker» con IMDEA Networks cuando subrayamos que cuando los agentes de IA comparten tu nombre de usuario y/o tu dirección de email hasheados con terceros (data brokers expertos), no te han proporcionado con ello ninguna protección.
No por casualidad la FTC ha advertido esto ya unas cuantas veces también. La última en un post de título elocuente: “No, Hashing Still Doesn’t Make Your Data Anonymous”.
Este es el nivel de protección que dispensa el hashing de emails
3 ¿Bradley Cooper o Jessica Alba dejan buenas propinas?
Mi ejemplo favorito es el de un periodista listillo que pretendía extraer de un data set “anonimizado” una información que resultaría interesante para muchos: ¿Qué famosos neoyorquinos son rumbosos y cuáles son unos ratas dando propinas a taxistas?
Alguien formuló una solicitud de transparencia contra el ayuntamiento de NYC, que publicó un data set de trayectos de taxis que incluía entre otras columnas, el número de licencia, el “Medallion” -es decir, el numerito que lleva cada taxi en el techo-, el punto de recogida del cliente, el punto de llegada, el tipo de tarifa aplicada, el importe de la carrera y el de la propina del viajero.
Para “preservar la privacidad” de los taxistas, las columnas del número de licencia y medallion fueron ¿lo adivinan? Hasheadas con MD5, convertidas en una ristra alfanumérica como las de antes.
Los hashes son irreversibles. El problema es que hay mucha información adicional a nuestro alcance directamente relacionada con el data set.
Los avispados periodistas buscaron fotografías en las que se pudiera reconocer: (i) a un famosete entrando en un taxi, (ii) el “medallion” de ese taxi y (iii) la calle en la que eso sucedía (“punto de recogida del cliente”).
Encontraron muchas.
A estas alturas ya se pueden imaginar el resto:
Hashearon el medallion del taxi de la foto y buscaron, para ese medallion, la carrera que empezaba ese día en esa calle. Y PAM, ya no hay más que ir a la columna de la propina.
Espoiler: Bradley Cooper y Jessica Alba no tenían propina registrada en un país en el que la costumbre es dejar propinas sustanciosas.
Plot twist: Pero ¡un momento! La propina sólo quedaba registrada si se pagaba con tarjeta y probablemente pagaron en efectivo. Ojo con las columnas vacías en las tablas de datos.
4.- Email hasheado: en la práctica, todo es mucho más fácil
Los autores compraron (bueno, pidieron gratis) muestras de cuatro data brokers: más de 6 millones de emails hasheados. Reidentificaron más de la mitad solo con “tablas arcoíris” de emails inventados, el 88% cruzándolos con brechas públicas y el 97% aplicando técnicas de cracking de contraseñas. Nice.
Pero tooodos estos ejemplos son más o menos llamativos, porque el “atacante” que quiere reidentificar el dataset juega con una mano atada a la espalda.
No es ese el caso de los data brokers en su actividad diaria.
Los data brokers tienen tablas de atributos de cada persona, con muchos puntos de información.
Un ejemplo: todos los móviles tienen un número de identificación a efectos publicitarios (“Android Advertising ID” (AAID) y “ID for Advertisers” (IDFA) en el iPhone).
Tanto Android como iPhones permiten cambiar sus respectivos id a voluntad.
¿Sirve para algo? Para muy poco.
Los data brokers venden tablas con estos identificadores de dispositivos emparejados con el email hasheado. Así, cuando reseteas el ID publicitario, el email te vuelve a vincular con el ID antiguo y con todos tus demás dispositivos.
Además las empresas, sabedoras de la posibilidad, extraen su propio identificador del dispositivo al instalarse (mucho más fácil y barato que el fingerprinting, también posible) y, aunque cambies el id publicitario, en el siguiente “evento” la app comunica tu “nuevo” id publicitario con el id de instalación de toda la vida y ahí quedaron tus intentos de proteger tu privacidad.
Después de este ejemplo, ya es más fácil entender que es trivial reidentificar a la mayoría de usuarios, a través del dispositivo que utilizan, o de cuatro datos de geolocalización (dónde curras / dónde duermes y un par más).
5.- ¿Qué relevancia tiene esto en la práctica?
Cuando te registras para recibir el ticket en formato digital de tu compra en grandes almacenes, te piden dos datos (teléfono móvil y luego la dirección de email -encima a través de WhatsApp de Meta-) donde sólo era estrictamente necesario el email, que es donde te van a mandar el ticket con cada compra.
Cualquier empresa interesada en contratar publicidad facilita los listados de sus clientes o usuarios a empresas como Meta o Google para “determinar audiencias” algo que, explicado de una forma muy simple, significa que, por ejemplo si esos grandes almacenes contratan una campaña de publicidad personalizada en Instagram, esa publicidad (i) no se te mostrará a ti, Mari Pili, que ya eres cliente, lo sabe porque ya has dado tu email y tu móvil) y (ii) se mostrará a “lookalikes”: a Marta y Pedro, que son personas del mismo perfil que Mari Pili (iii) se lo mostrará incansablemente a Mari Pili, si sabe que ha mirado un determinado producto y no lo ha comprado. Como todos sabemos.
El tema es que la política de privacidad de la empresa y la de Meta, y la de Google, y la de Criteo, LiveRamp y demás data brokers te dirán “hasheamos los identificadores de tus usuarios o clientes” antes de hacer nuestra magia y así conseguimos mejorar la relevancia de nuestros anuncios y medir el impacto de nuestras campañas sin identificar al interesado.
Lo cierto es que, como ya ha quedado claro, los grandes almacenes, Meta, Google, Criteo y todos los ahem “socios” o “proveedores de identidad” saben perfectamente que esa hash de letras y números es Mari Pili.
Nota a pie de página: este post podría haber sido orientado a la sugestivas implicaciones de todo esto al aplicar la doctrina SRB /Scania, pero en mi interpretación, no hace falta: Si lo que la tienda, Meta o Criteo quieren es que se muestre un anuncio personalizado de la tienda a Marta y Pedro, pero no a Mari Pili, atendidos el contenido, finalidad y efectos del tratamiento, es completamente irrelevante que la información que se tenga disponible les identifique por su nombre y apellidos (Marta, Pedro, Mari Pili) o por hashes únicos, porque la finalidad (impactarles con la publi personalizada) se consigue igualmente.
6.- Un par de ejemplos
Nasdaq, Inc. En la lista de terceros vinculada a su política de privacidad dice que puede compartir con LiveRamp «hashed and de-identified email addresses», junto con IP e identificadores publicitarios. En la misma frase añade que LiveRamp usa esa información para vincular el dispositivo del usuario con sus bases de datos y hacer publicidad dirigida.
Google. En la ayuda de Customer Match para anunciantes afirma que «Google doesn’t receive actual email addresses», porque transforma los emails de sus cuentas en hashes SHA-256 de un solo sentido. Ahora sabemos que si lo dice cualquiera es falso, pero es que que lo diga Google es la risa ¿eh? ¿EH?
LiveRamp. En un post corporativo sobre RampID sostiene que el enfoque seudonimizado permite consolidar, enriquecer y segmentar datos «without exposing or sharing a customer’s private information».
Yeah baby, yeah.
Procter & Gamble: En «Medios direccionables«: cifra el dato o usa UID2 y sube «una versión seudonimizada (reemplazada con números o letras artificiales)» del email, teléfono o ID publicitario a plataformas como Facebook, YouTube, Instagram o TikTok. Incluye además una lista de plataformas con las que puede compartir una versión con hash del email.
Nota a pie de página 2: Por supuesto, todo esto se puede hacer bien: la solución es añadir “salt” antes de hashear los datos. El salt protege frente a terceros (pero entre quienes comparten la clave), el dato sigue siendo personal… pero este post ya se me ha quedado largo.
Nota a pie de página 3: quizá necesites meterle un repintado a tu política de privacidad si califica como «anónimo» o «desidentificado» a un email hasheado, o repensar la base legal de todo eso que subes a Customer Match o Custom Audiences.
Jorge García Herrero
Abogado y Delegado de Protección de datos