Filtración de datos de Kaneva de 2016
La filtración de datos de Kaneva de 2016 afecta a datos de cuentas atribuidos al servicio de red social y mundo virtual 3D gratuito.
Tipos de datos expuestos
4- Fechas de nacimiento
- Direcciones de correo electrónico
- Contraseñas
- Nombres de usuario
Acerca de esta brecha de datos
Un registro externo verificado de la filtración indica la fecha del 1 de julio de 2016, 3 901 179 direcciones de correo electrónico únicas y cuatro categorías de datos estructurados. El proceso de producción dedicado exclusivamente a direcciones de correo electrónico procesó 3 908 470 líneas válidas y creó 3 908 307 asociaciones únicas de correo electrónico en el índice activo. Estas cifras corresponden a distintas capas del conjunto de datos y no se suman entre sí.
¿Qué se verificó sobre el incidente y el servicio?
La descripción externa verificada disponible actualmente indica que quedaron expuestos 3,9 millones de registros de usuarios del servicio Kaneva, ya desaparecido, y que contenían direcciones de correo electrónico, nombres de usuario, fechas de nacimiento y hashes MD5 de contraseñas con sal. Su lista estructurada de categorías incluye esas mismas cuatro. No se encontró ningún aviso público del operador, registro de un organismo regulador, método de acceso inicial, actor responsable, duración del acceso ni fecha de publicación. El 1 de julio es la fecha del incidente que figura en el registro externo y no se interpreta como el momento exacto del acceso a la red.
Una captura archivada del 30 de junio de 2016 presenta Kaneva como un servicio que combinaba una red social con un mundo virtual 3D gratuito, donde los usuarios podían construir y explorar mundos virtuales con amigos. La captura respalda la identidad de la organización y del servicio; no es un aviso independiente del incidente. Dado que kaneva.com ahora redirige a un sitio web sin relación con Kaneva, el registro público enlaza en su lugar a la captura archivada de la época del incidente.
¿Qué tipos de datos se incluyen?
Las categorías verificadas en la fuente externa son fechas de nacimiento, direcciones de correo electrónico, contraseñas y nombres de usuario. Las contraseñas se describen como hashes MD5 con sal; no se ha demostrado que se expusieran contraseñas en texto plano. La sal reduce la utilidad de las tablas de consulta precalculadas, pero MD5 es un método rápido y débil para el almacenamiento moderno de contraseñas.
Los nombres, números de teléfono, direcciones postales, documentos de identidad oficiales, tarjetas de pago, mensajes privados, contenido de avatares y actividad en el mundo virtual no son categorías verificadas. Una coincidencia de correo electrónico, por sí sola, no demuestra que una persona tuviera una cuenta de Kaneva, que su dirección figurara en una misma fila junto con una fecha de nacimiento, un nombre de usuario o un hash concretos, ni que utilizara el mundo virtual.
¿Por qué difieren los recuentos externos y locales?
La cifra de 3 901 179 corresponde al recuento de direcciones de correo electrónico únicas del conjunto de datos externo. El índice local contiene 3 908 307 asociaciones únicas de correo electrónico, 7 128 más que el recuento externo, mientras que las 3 908 470 líneas válidas procesadas superan en 163 las asociaciones únicas locales. Como no se han conciliado los detalles sobre la versión del conjunto de datos, la normalización y la eliminación de duplicados, no se atribuye ninguna causa a estas diferencias.
El proceso local contiene únicamente direcciones de correo electrónico. Las fechas de nacimiento, los nombres de usuario y los hashes de contraseñas son categorías verificadas en la fuente externa, no campos almacenados localmente a partir de esta importación de producción. Quienes sepan por sí mismos que reutilizaron una antigua contraseña de Kaneva en otro servicio pueden sustituirla en ese servicio por una contraseña única y activar la autenticación multifactor cuando esté disponible.
Método de verificación y revisión editorial
LeakData compara el nombre del incidente, la fecha, la cantidad de registros afectados y los tipos de datos expuestos con fuentes accesibles. Los campos no verificados no se presentan como hechos, y los registros se actualizan cuando se dispone de nuevas pruebas.
Notificar errores u omisiones en la información