Como o brtech implementa anonimato de verdade: a arquitetura de privacidade por tras dos relatos

Gabriel — Tue, 14 Jul 2026 17:17:25 +0000

Se eu sofrer um ataque e dumparem o banco de dados do brtech, o que o invasor encontra?

Hashes irreversiveis. Nomes aleatorios. Tokens nulos. Zero emails. Zero IPs. Zero user agents.

Nao e "confia que a gente nao vai vazar". E "mesmo que vaze, nao tem o que entregar".

Esse post conta como chegamos nessa arquitetura - e os 6 dias de commits que transformaram uma solucao ingenua em anonimato de verdade.

Dia 1: "So guardar o hash, ne?"

27 de junho. Primeiro commit do auth.ts. O plano parecia simples:

// Solucao ingenua - Dia 1
databaseHooks: {
  user: {
    create: {
      before: async (user) => {
        const hash = hmac(user.email)
        const existing = await prisma.user.findUnique({ where: { emailHash: hash } })
        return {
          data: {
            ...user,
            emailHash: hash,
            email: null, // "pronto, nao guardei email"
          },
        }
      },
    },
  },
}

Funcionava? Tecnicamente sim. O email chegava no hook, era hasheado, e o campo email ia como null para o banco.

Mas tinha um problema. O email ainda transitava pelo hook do Better Auth. A lib recebia o payload do Google/GitHub/LinkedIn com o email em texto puro, chamava o before, e so depois descartava. Se alguem logasse o user dentro do hook - ou se o Better Auth fizesse algum log interno - o email estava la.

Era melhor que guardar no banco. Mas nao era anonimato de verdade.

Dia 2: "anonymousId publico e ma ideia"

28 de junho. O schema tinha um campo anonymousId - 4 caracteres alfanumericos que identificavam o usuario publicamente nos perfis.

model User {
  anonymousId String? @unique
  // ...
}

A ideia era: em vez de mostrar o CUID interno (que e imutavel e poderia ser usado para correlacionar dados entre tabelas), mostramos um ID publico curto.

29 de junho. Removido. O commit ab781c3 deletou o campo do schema, do auth, dos tipos, de tudo.

O problema: qualquer ID estavel e visivel publicamente permite correlacionar contribuicoes ao longo do tempo. Se o usuario aB3x posta um salario na Stone e amanha posta uma review no Nubank, da para juntar as pecas - especialmente se o cargo e senioridade forem parecidos.

Nao ter ID publico nenhum tambem nao funcionava - o usuario precisa ver seu proprio historico. A solucao final foi o anonymousId virar um derivado do emailHash (visivel so para o proprio usuario logado), mas deixamos isso para depois.

Dia 3: "Usuario Anonimo com foto de dado"

2 de julho. Commit b2e1f13. Reescrevemos o before hook para nunca mais deixar o email original tocar campos que vao para o banco:

const generateRandomEmail = () => `${nanoid(16)}@anonimizado.brtech.fyi`
const generateName = () => `Anonimo #${nanoid(7)}`
const generateImage = () => `https://api.dicebear.com/6.x/initials/svg?seed=${nanoid(7)}`

user: {
  create: {
    before: async (user) => ({
      data: {
        ...user,
        emailHash: hashEmail(user.email),  // unica coisa que persiste
        email: generateRandomEmail(),       // falso
        name: generateName(),               // "Anonimo #aB3xK2m"
        image: generateImage(),             // avatar DiceBear aleatorio
        emailVerified: false,
        seniorityLevel: null,
        currentRole: null,
      },
    }),
  },
}

Agora o fluxo era:

Google manda { email: "joao@gmail.com", name: "Joao Silva", image: "https://..." }
O hook gera emailHash via HMAC-SHA256
Substitui email, name, image por dados falsos
O banco nunca ve o email real

Mas ainda faltava uma camada. Os tokens OAuth (access token, refresh token) e os dados de sessao (IP, user agent) continuavam sendo persistidos pelo Better Auth automaticamente. Esses tokens sao a chave para acessar a conta Google/GitHub do usuario - se vazarem, o invasor pode se passar por ele.

Dia 4: O lockdown (o commit que mudou tudo)

5 de julho. Commit 32ebbbc. O "privacy lockdown".

Duas descobertas aconteceram nesse dia:

1. O Better Auth persiste tokens OAuth por padrao. Cada login guarda accessToken, refreshToken, idToken, scope na tabela Account. Esses tokens dao acesso a API do Google/GitHub/LinkedIn em nome do usuario.

2. O Better Auth atualiza os tokens em TODO login. O campo account.updateAccountOnSignIn: true (padrao) reescreve os dados da conta a cada sessao.

A solucao foi atacar em todas as frentes:

advanced: {
  ipAddress: {
    disableIpTracking: true,  // nunca armazena IP
  },
},

account: {
  // Nao atualiza tokens a cada login
  updateAccountOnSignIn: false,

  create: {
    before: async (account) => ({
      data: {
        ...account,
        accessToken: null,
        refreshToken: null,
        idToken: null,
        accessTokenExpiresAt: null,
        refreshTokenExpiresAt: null,
        scope: null,
        password: null,
      },
    }),
    after: async (account) => {
      // Segunda camada: zera email e imagem do User
      // apos o Better Auth terminar de criar a conta
      await prisma.user.update({
        where: { id: account.userId },
        data: {
          email: null,
          emailVerified: false,
          image: null,
        },
      })
    },
  },
  update: {
    before: async (account) => ({
      data: {
        ...account,
        accessToken: null,
        refreshToken: null,
        // ... mesmo tratamento
      },
    }),
  },
},

session: {
  create: {
    before: async (session) => ({
      data: {
        ...session,
        ipAddress: null,   // nunca armazena IP
        userAgent: null,   // nunca armazena user agent
      },
    }),
  },
  update: {
    before: async (session) => ({
      data: {
        ...session,
        ipAddress: null,
        userAgent: null,
      },
    }),
  },
},

user: {
  update: {
    before: async (userData) => ({
      data: {
        ...userData,
        email: generateRandomEmail(),   // re-randomiza a cada update
        emailVerified: false,
      },
    }),
  },
},

O after do account e a jogada mais sutil aqui. Mesmo depois do before limpar os campos, o Better Auth pode popular novamente o User.email e User.image durante a criacao da conta. O after garante que, depois que a lib termina seu trabalho, a gente limpa de novo.

Nesse mesmo dia criei o PRIVACY_DATA_INVENTORY.md - um documento mapeando campo por campo do banco, o que contem, e por que pode ou nao ser anonimizado. Virou a referencia canonica para qualquer decisao futura sobre privacidade.

Dia 5: Cross-provider linking sem email

6 de julho. Commits 5183060 → 673df35 → c7c2b3d.

Agora o banco nao tinha email. Beleza. Mas e o cenario onde o usuario faz login com Google num dia e com GitHub no outro?

Sem email no banco, o Better Auth nao consegue correlacionar as contas. Ele faz findOne(User, { email: "joao@gmail.com" }) e nao acha nada - porque o email no banco e aB3xK2m9nQpL4rSt@anonimizado.brtech.fyi.

A solucao: interceptar as queries do adapter.

O Better Auth usa um adapter de banco de dados para todas as operacoes. Se eu conseguisse interceptar as chamadas findOne no model User filtrando por email, poderia redirecionar para emailHash:

export function withEmailHashLookup(createAdapter) {
  return (...args) => {
    const factory = createAdapter(...args)
    return (options) => wrap(factory(options))
  }
}

function wrap(adapter) {
  return {
    ...adapter,
    findOne: async ({ model, where, select, join }) => {
      // Intercepta queries de User por email
      if (
        model.toLowerCase() === 'user' &&
        where?.length === 1 &&
        where[0]?.field === 'email' &&
        typeof where[0]?.value === 'string'
      ) {
        // Tenta achar por emailHash primeiro
        const hashResult = await adapter.findOne({
          model,
          where: [{ field: 'emailHash', value: hashEmail(where[0].value) }],
          select,
          join,
        })
        if (hashResult) return hashResult
      }
      // Fallback: busca normal por email
      return adapter.findOne({ model, where, select, join })
    },
    // O wrapper tambem precisa funcionar dentro de transacoes
    transaction: async (cb) => {
      return adapter.transaction(async (trx) => cb(wrap(trx)))
    },
  }
}

E na configuracao do auth:

accountLinking: {
  enabled: true,
  trustedProviders: ['google', 'github', 'linkedin', 'microsoft'],
  allowDifferentEmails: false,
  updateUserInfoOnLink: false,
},

Agora o fluxo e:

Usuario faz login com Google → emailHash gerado, conta criada
Usuario faz login com GitHub (mesmo email) → o adapter intercepta a query por email, traduz para emailHash, acha o mesmo usuario
A conta GitHub e linkada ao mesmo usuario sem que o email jamais toque o banco

Bug sutil que quase passou: o adapter usava model === 'User' (case-sensitive) mas o Better Auth internamente chama com 'user' (lowercase) em alguns metodos. Corrigi no commit c7c2b3d mudando para model.toLowerCase() === 'user'. Isso custou uma hora de debug.

Gotcha: pensando agora, nem precisava desse adapter todo. Era so gerar o hash e fazer append de @anonymized.brtech.fyi como email fake - o Better Auth faria o lookup por email normalmente e encontraria o usuario pelo hash deterministico. Sem adapter. Sem wrapper. Sem interceptar query. Mas tambem nao tenho certeza se funcionaria com account linking cross-provider... e ja que ta funcionando assim, vai ficar assim.

Dia 6: Soft delete que apaga ate o hash

Uma vez por mes alguem pede para deletar a conta. A LGPD exige isso.

Mas se eu so marco status: 'deleted', o hash continua la. E hashes podem ser atacados por forca bruta se o espaco de busca for pequeno (ex: "quero saber se joao@gmail.com tem conta no brtech" → gero o hash e comparo).

A solucao: sobrescrever o hash com lixo:

await tx.user.update({
  where: { id: session.id },
  data: {
    status: 'deleted',
    deletedAt: now,
    emailHash: `deleted-${nanoid(32)}`,  // hash original e destruido
  },
})

As contribuicoes (salarios, reviews, entrevistas) nao sao deletadas - elas permanecem anonimas, alimentando as medias e rankings. Mas o ponteiro entre elas e o usuario some para sempre.

O que acontece se o usuario criar uma conta nova depois? Vai gerar um emailHash novo, conta nova, historico zerado. A conta antiga e um fantasma - contribuicoes orfas que nao apontam para ninguem.

O que essa arquitetura NAO protege

Para ser honesto, tem limites:

Fingerprinting comportamental. Se voce postar "Sou Senior na Stone, entrei em 2023, ganho R$18k CLT" e amanha tuitar exatamente a mesma frase, a correlacao e externa ao brtech. Nao tem como impedir que o usuario se auto-identifique fora da plataforma.

Metadados de moderacao. Moderadores veem o conteudo das contribuicoes (precisam revisar). Nao veem identidade - mas veem que o usuario Anonimo #aB3xK2m postou review X e salario Y. Se o usuario usar o mesmo cargo e empresa em ambas, e um padrao visivel.

Rotacao do BETTER_AUTH_SECRET. Se eu trocar a chave do HMAC, todos os hashes mudam. Ninguem consegue fazer login na conta antiga. Isso e documentado: rotacionar o secret requer uma migracao planejada que recalcula todos os emailHash do banco. Nao e operacao de emergencia.

A funcao que amarra tudo

No final, 14 linhas de codigo seguram o castelo:

// src/lib/hash-email.ts
export function hashEmail(email: string): string {
  const secret = process.env.BETTER_AUTH_SECRET
  if (!secret) throw new Error('BETTER_AUTH_SECRET is required')
  return crypto
    .createHmac('sha256', secret)
    .update(email.toLowerCase().trim())
    .digest('hex')
}

Deterministico. Irreversivel. Sem sal (o secret e o sal). A mesma funcao e usada em 4 lugares: auth hook, adapter, seed script, e representative lookup. Se algum lugar usar um algoritmo diferente, usuarios duplicados aparecem.

E essa funcao que me deixa dormir tranquilo. Se um dia alguem pedir acesso ao banco com um mandado judicial, o que vou entregar sao hashes HMAC-SHA256, nomes Anonimo # aleatorios, e tokens nulos.

E salarios que nao apontam para ninguem.

O codigo esta no ar. A versao de preview em dev.brtech.fyi tem dados ficticios para testar. A versao oficial em brtech.fyi já tem algumas contribuições, com dados reais.

O repo e aberto: github.com/tuf/brtech (ou onde estiver hospedado).

Consegui negociar R$50k a mais por ano porque um desconhecido compartilhou como foi a entrevista dele. Entao construi o brtech.

Gabriel — Tue, 14 Jul 2026 12:06:49 +0000

Antes da entrevista, encontrei um relato no Teamlyzer - uma plataforma portuguesa que mistura Reclame Aqui com Levels.fyi. La tinha um relato dizendo que a empresa costumava focar bastante em filas (queues) para a entrevista tecnica de backend.

Estudei exatamente aquilo. Cheguei muito mais preparado.

Nessa mesma plataforma tambem da para ver salarios. Vendo o que outras pessoas tinham compartilhado, eu que ia pedir €33k acabei pedindo €45k, eles iam pagar inicialmente €30k.
Fechamos em €41 mil por ano (cerca de R$50k a mais do que eu ganhava antes). Pode nao parecer muito, mas e bastante em Portugal.

Enfim, voltei para o Brasil e comecei a procurar emprego de novo e Senti falta de algo parecido.

No maximo voce consegue usar a busca em grupos do facebook como a APDA ou achar um relato de 3 anos atras no Reddit que esta [removido pelo usuario].

Decidi desenvolver e lancar a brtech para cobrir esses pontos.

Tres objetivos

Centralizar salarios como o Levels.fyi, mas focado no mercado BR. Salario base, bonus, VR/VA, modelo de trabalho (CLT/PJ/Cooperado), senioridade. Tudo em real.

Relatos de entrevista. Para o candidato saber o que esperar antes de entrar num teste tecnico. Quantas etapas, quanto tempo, o que perguntaram.

Reviews de quem trabalha la. Nao e nota 1 estrela com "RH e uma mae". Sao pros e contras estruturados, com nota para gestao, reconhecimento e equilibrio vida/trabalho.

Hobby, nao startup

O projeto e totalmente hobby. Nao tem anuncios, nao tem paywall, nao esconde informacao atras de cadastro. Qualquer pessoa pode consumir tudo gratuitamente.

Existe login, mas foi a forma que encontrei de evitar spam. O login e via OAuth (Google, GitHub, LinkedIn, Microsoft) e como aqui so tem dev posso garantir: a unica informacao que utilizo e o email, que e transformado em hash irreversivel (HMAC-SHA256) e descartado, ele nunca nem bate no banco de dados. Em um login futuro é possivel criar novamente o hash e linkar ao seu user, voce continua com seu historico mesmo sem ter nenhum dado seu no banco.

Traduzindo: mesmo que o banco vaze, nao e possivel saber de quem sao os relatos. Inclusive acho bem dificil acontecer. fechei todas as portas do VPS e me conecto via Tailscale. Para servir o app, uso os tunnels da Cloudflare.

Status atual

Ainda estou finalizando detalhes (a famosa versao v1.0.67-final.5).

Enquanto isso, subi uma versao de demonstracao com dados ficticios para mostrar como a plataforma funciona e ouvir os primeiros feedbacks:

👉 dev.brtech.fyi

A versao oficial em brtech.fyi comeca vazia, com dados reais. Que durante essa postagem ainda está fechada para ajustes, mas quando vc ler pode ser que já esteja disponivel.

Se a ideia fizer sentido, queria muito ouvir criticas e sugestoes antes de abrir a versao definitiva.

PS: A plataforma pode parecer grande, mas foi tudo feito por mim. Tem termos de uso e cookies isso e gracas ao video em que o Mano Deyvin e comenta sobre compliance juridico no SaaS dele. Os termos de uso e politica de privacidade foram escritos pelo meu advogado Qwen 3.7 Plus. Tambem tem analytics nao sei nem o basico de como isso pode me ajudar, mas baseado nas tasks criadas pelos meus antigos PMs deve ser possivel identificar e melhorar o UX. Aceitem os cookies para me ajudar a ver como funciona isso.

Obrigado 🍻

DEV Community: Gabriel