Incidentes e Vulnerabilidades
Vazamento de dados do Takufile-bin (2019) — por que armazenar senhas em texto puro é fatal, e a defesa do hashing
Em janeiro de 2019, o serviço japonês de transferência de arquivos Takufile-bin (Ogis-Research Institute) foi invadido e ~4,8 milhões de registros vazaram. A falha decisiva: as senhas de login vazadas estavam armazenadas sem criptografia, em texto puro. Defenda-se com hash de mão única e sal.
Lemos vazamentos reais e públicos não como notícia reprisada, mas como "como você se defende disto?" Este artigo se baseia no registro público (declarações da empresa, reportagem confiável). As fontes estão listadas ao final, e nenhum passo a passo de ataque está incluído.
- Alvo
- Usuários do serviço de transferência de arquivos "Takufile-bin" (operador: Ogis-Research Institute)
- Detectado
- 22–25 de janeiro de 2019 (um arquivo suspeito foi notado → serviço interrompido → divulgado)
- Padrão
- Acesso não autorizado por uma vulnerabilidade de servidor → roubo de dados de clientes (senhas de login armazenadas em texto puro)
- Escala
- ~4,8 milhões de registros (nomes, e-mails, senhas de login, datas de nascimento, gênero; incluindo clientes que já haviam cancelado)
- Causa raiz
- Senhas armazenadas em texto puro (forma reversível) + uma vulnerabilidade de servidor + retenção de dados desnecessários, incluindo usuários que cancelaram
- Correção real
- Hash de mão única + sal (bcrypt/Argon2id); não guarde dados de que você não precisa / minimize a retenção; gestão de vulnerabilidades; prepare-se para o reúso (2FA)
O que aconteceu (em termos simples)
Um serviço recebe as senhas dos usuários em confiança. A questão é como ele as guarda. Armazene uma senha em texto puro (legível como está), ou apenas com criptografia reversível, e no momento em que os dados vazarem seu conteúdo é diretamente utilizável.
No Takufile-bin, uma vulnerabilidade de servidor foi explorada para acesso não autorizado e dados de clientes vazaram. Um relatório de acompanhamento então divulgou que as senhas de login vazadas não tinham sido criptografadas — estavam em texto puro. Como muitas pessoas reutilizam a mesma senha entre serviços, um vazamento em texto puro permite que um atacante a experimente em outro lugar para o sequestro de contas. Mais do que a intrusão em si, foi o armazenamento em texto puro que ampliou o dano.
'Criptografia' e 'hashing' não são a mesma coisa
Um equívoco comum no armazenamento de senhas é que a criptografia torna tudo seguro. A criptografia é reversível com uma chave, então, se a chave também vazar, não é melhor que texto puro. A abordagem correta é um hash de mão única que não pode ser revertido, mais um sal por usuário, usando um algoritmo deliberadamente lento (bcrypt / Argon2id). No login, você aplica o hash à entrada da mesma forma e compara — então não há necessidade alguma de armazenar o texto puro.
A cadeia do ataque também é um mapa de defesa
Esta foi uma cadeia com um ponto de parada em cada etapa. Leia-a como onde ela poderia ter sido interrompida, não como um passo a passo.
1. Acesso não autorizado por uma vulnerabilidade de servidor
Uma fraqueza conhecida e negligenciada vira a porta de entrada.
Parada: gestão de vulnerabilidades; disciplina de patches; minimizar a superfície de ataque
2. Dados de clientes e senhas de login capturados
Um grande acervo de dados, incluindo clientes que cancelaram, estava guardado.
Parada: não guarde dados de que você não precisa; minimize a retenção
3. Senhas em texto puro = imediatamente utilizáveis
Não criptografadas, então utilizáveis no momento em que vazaram.
Parada: hash de mão única + sal (bcrypt/Argon2id) = não diretamente utilizável se vazar
4. Dano secundário via reúso (sequestro de contas)
Outros serviços que compartilham a mesma senha viram alvo.
Parada: pare de reutilizar senhas; 2FA; redefinição forçada e imediata em um vazamento
Cronologia divulgada
2019-01-22
Um arquivo que a empresa não reconhecia é encontrado em um servidor (um sinal de acesso não autorizado).2019-01-23
O serviço é interrompido por precaução.2019-01-25
O acesso não autorizado e o vazamento de dados são divulgados (~4,8 milhões de registros, incluindo usuários que cancelaram).2019-01-30
Um relatório de acompanhamento divulga que as senhas de login vazadas não tinham sido criptografadas (texto puro).2019-03
Conclusões detalhadas de uma empresa de segurança externa são relatadas; o serviço permanece suspenso.2020-01-14
O encerramento é anunciado (dado o custo/tempo de uma reconstrução segura); o serviço termina naquele ano.
A causa raiz não foi apenas "ter sido invadido"
Descartar isto como "eles foram hackeados" perde o ponto. A intrusão pode acontecer; o que importa é se o armazenamento minimiza o dano quando os dados vazam.
A configuração que falhou
- Senhas de login armazenadas em texto puro (utilizáveis no momento em que vazam)
- Um grande acervo de dados, incluindo usuários que cancelaram, mantido guardado
- Uma vulnerabilidade de servidor virou a porta de entrada
- Difícil interromper o sequestro de contas em sites de reúso após o vazamento
A configuração que resiste
- Senhas armazenadas como um hash de mão única + sal (bcrypt/Argon2id)
- Não guarde dados de que você não precisa; minimize a retenção (apague após o cancelamento)
- Gestão de vulnerabilidades / disciplina de patches fecha a porta de entrada
- 2FA e redefinição forçada e imediata em um vazamento limitam o dano secundário
A conta a posteriori supera em muito o investimento de projeto feito antecipadamente
O Takufile-bin permaneceu suspenso e acabou sendo encerrado por completo (dado o custo e o tempo de uma reconstrução segura). Aplicar hash às senhas corretamente é barato, enquanto o custo da confiança perdida, dos cancelamentos e do dano secundário do armazenamento em texto puro é muito maior. Projete como você armazena senhas corretamente quando você o constrói, não depois.
Como você se defende disto
Se você recebe em confiança a senha de até mesmo um único usuário, isto é seu. Em ordem de prioridade:
Armazene senhas como um hash de mão única com sal
Não armazene texto puro nem 'criptografia reversível'. Use um hash de mão única com um sal por usuário, via um algoritmo deliberadamente lento como bcrypt ou Argon2id. Para o passo a passo completo, veja como armazenar senhas com segurança.
Não guarde dados de que você não precisa
Colete o mínimo de campos e apague os dados assim que um usuário cancelar ou eles não forem mais necessários. Dados que você não guarda não podem vazar. Não acumule registros de usuários que cancelaram.
Feche a porta de entrada — gerencie vulnerabilidades
Corrija vulnerabilidades de servidor e de bibliotecas e minimize a superfície de ataque exposta. Assuma que a intrusão é possível e reduza as portas de entrada.
Limite o dano mesmo se vazar (2FA, defesa contra reúso)
Ofereça autenticação de dois fatores e force uma redefinição imediata em um vazamento. Incentive os usuários a se afastar do reúso. Junto com o hashing, busque um estado em que um vazamento não seja diretamente utilizável.
Onde isto se sobrepõe a como este site é construído
No fundo, este incidente manteve o segredo mais importante — a senha — em uma forma utilizável como está se vazasse (texto puro). Isso é a imagem invertida dos próprios princípios deste site — tratar segredos em uma forma irreversível, não guardar nada de que você não precisa e encolher o raio de explosão. "Nós criptografamos, então está seguro" é uma suposição perigosa; senhas pertencem a um hash de mão única + sal. "Não guarde texto puro, não guarde dados desnecessários, torne um vazamento inutilizável" é uma defesa que qualquer um pode implementar em qualquer escala.
Fontes (registro público)
Os fatos aqui se baseiam nas seguintes informações públicas. Nenhum passo a passo de ataque está incluído — apenas as lições defensivas.
- Declarações oficiais do Ogis-Research Institute ("Sobre o acesso não autorizado ao serviço Takufile-bin" / pedido de desculpas e relatório, 2019–2020) — ogis-ri.co.jp
- Reportagem da época (suspensão do serviço, conclusões detalhadas e encerramento, 2019–2020), baseada nas divulgações primárias
Leia a seguir
- Prática: Como armazenar senhas com segurança (hashing e sal)
- Glossário: O que é hashing de senha / O que é um sal
- Glossário: Autenticação de dois fatores (2FA) (para que um vazamento não seja diretamente utilizável) · Prática: Checklist de base de segurança
FAQ
QQual foi o problema mais grave no incidente do Takufile-bin?
Que as senhas de login vazadas estavam armazenadas sem criptografia — em texto puro. O gatilho foi o acesso não autorizado por uma vulnerabilidade de servidor, mas, como as senhas estavam em texto puro, ficaram imediatamente utilizáveis no momento em que vazaram. Se as senhas tivessem sido armazenadas como um hash de mão única (com um sal), um vazamento não teria exposto senhas utilizáveis, e o dano teria sido bem menor.
Q'Criptografar' senhas é seguro o suficiente?
'Criptografia' e 'hashing' são coisas diferentes. A criptografia é reversível com uma chave, então, se a chave também vazar, não é melhor que texto puro. A abordagem certa é um <strong>hash</strong> de mão única que não pode ser revertido, mais um <strong>sal</strong> por usuário, usando um algoritmo deliberadamente lento como bcrypt ou Argon2id. No login, você aplica o hash à entrada da mesma forma e compara — então não há necessidade alguma de armazenar o texto puro.
QComo usuário individual, o que eu posso fazer?
Sim: (1) nunca reutilize uma senha entre serviços (assim, mesmo um vazamento em texto puro não leva ao sequestro de conta em outro lugar); (2) use um gerenciador de senhas para valores longos e aleatórios; (3) ative a autenticação de dois fatores ou uma passkey onde quer que seja oferecida. Mesmo que o operador armazene senhas mal, não reutilizá-las quebra a cadeia de dano secundário.