Vazamento de dados da JobStreet de 2012
O vazamento de dados da JobStreet de 2012 envolve um grande conjunto de dados de pessoas em busca de emprego, atribuído ao serviço de recrutamento.
Tipos de dados expostos
12- Datas de nascimento
- Endereços de e-mail
- Gêneros
- Localizações geográficas
- Documentos de identificação emitidos pelo governo
- Estados civis
- Nomes
- Nacionalidades
- Senhas
- Números de telefone
- Endereços físicos
- Nomes de usuário
Sobre este vazamento
Um registro externo verificado do vazamento informa a data de 7 de março de 2012 e 3.883.455 endereços de e-mail únicos. A tarefa de produção restrita a e-mails processou 3.879.211 linhas e criou 3.879.157 associações únicas de e-mail. Esses valores correspondem a escopos distintos.
Quais fontes documentam o evento?
Em 19 de outubro de 2017, o Lowyat.NET informou que havia examinado vários conjuntos de dados da Malásia oferecidos à venda em seu fórum. A reportagem afirmou que o arquivo atribuído à JobStreet continha quase 17 milhões de linhas e apresentava nomes de candidatos, nomes de login, hashes de senhas, e-mails, nacionalidades, endereços e números de celular; os dados pareciam ser do período de 2012 a 2013 e incluíam pessoas de fora da Malásia. Como indicava o título do artigo, a origem dos dados era desconhecida naquele momento.
Posteriormente, um índice verificado de vazamentos autenticou o conjunto de dados atribuído ao serviço, com 3.883.455 e-mails únicos e 12 categorias estruturadas de dados, e informou que os dados passaram a estar disponíveis para download pela rede Tor. Essa verificação do conjunto de dados não significa que a JobStreet tenha confirmado publicamente o incidente nem que 7 de março tenha sido o dia exato do acesso à rede. A data deve ser entendida como uma data do evento derivada dos registros.
Quais tipos de dados estão incluídos?
As categorias verificadas são datas de nascimento, endereços de e-mail, gêneros, localizações geográficas, números de identificação emitidos pelo governo, estados civis, nomes, nacionalidades, senhas, números de telefone, endereços físicos e nomes de usuário. Não se deve presumir que qualquer um desses campos esteja presente em todos os registros de e-mail; em particular, a cifra de quase 17 milhões relatada para o arquivo de origem não é uma contagem de pessoas únicas nem de e-mails únicos.
Arquivos de currículos, textos de candidaturas, histórico profissional, salários, contas bancárias e cartões de pagamento não estão entre as categorias estruturadas atuais. Embora o registro envolva dados de pessoas em busca de emprego, uma correspondência de e-mail não comprova a profissão, a situação de desemprego, o status de uma candidatura, a nacionalidade ou o estado civil de uma pessoa, nem que os demais campos estivessem presentes juntos na mesma linha.
Qual é a diferença entre 3.883.455, quase 17 milhões e 3.879.157?
O valor de 3.883.455 é o número de endereços de e-mail únicos no conjunto de dados externo verificado. Quase 17 milhões é a contagem de linhas relatada para o arquivo de origem examinado em 2017. O valor local de 3.879.157 é o número de associações únicas de e-mail atualmente indexadas após a importação de uma única coluna de e-mails, 4.298 a menos que a contagem externa. Os três valores não são somados.
A tarefa local contém apenas endereços de e-mail. Os campos de senha, identidade, telefone, endereço e dados demográficos verificados no conjunto de dados externo não são campos armazenados localmente a partir dessa importação de produção.
Que medidas as pessoas podem considerar?
Se uma senha do período de 2012 foi reutilizada em outros serviços, ela pode ser substituída por uma senha exclusiva nas contas em questão. Mensagens de recrutamento que usem uma candidatura antiga, um número de telefone, um endereço ou um dado de identidade não devem ser consideradas confiáveis apenas por isso; o empregador ou a JobStreet devem ser verificados por um canal oficial separado. Documentos de identidade, senhas e códigos de uso único não devem ser fornecidos por meio de um link suspeito.
Verificação e método editorial
A LeakData compara o nome do incidente, a data, a quantidade de registros afetados e os tipos de dados expostos com fontes acessíveis. Campos não verificados não são apresentados como fatos, e os registros são atualizados quando novas evidências ficam disponíveis.
Informar dados ausentes ou incorretos