Pular para o conteúdo
Criar conta grátis
Criar conta grátis

Quão seguro é o Crunu?

Construímos o Crunu partindo do princípio de que o servidor dele vai ser atacado. Aqui está o que cada atacante do modelo de ameaças do produto consegue, o que não consegue e qual camada fica no caminho, incluindo onde o Crunu não tem como ajudar.

Criar conta grátisLeia o modelo de segurança
  • AES-256-GCM criptografa cada versão
  • X25519 sela as chaves, Ed25519 assina
  • Chave da conta gerada a partir da sua senha (PBKDF2-SHA256, 1.000.000 iterações) e de uma Secret Key de cerca de 128 bits, nenhuma das duas enviada ao servidor
  • Nenhuma chave de descriptografia no servidor, em nenhuma etapa

Três camadas de proteção e versões publicadas que você pode conferir

O modelo de ameaças do Crunu marca cada defesa com a camada que a oferece. Isso importa mais quando o atacante é o próprio servidor, porque aí só algumas camadas continuam funcionando.

  • Criptografia

    Quem tem a chave

    As chaves dos ambientes são seladas apenas para as pessoas, máquinas e tokens que você permite, e as listas de acesso e as versões são assinadas. Sem a chave, texto cifrado continua sendo texto cifrado.

    Se alguém tomar o controle do servidorContinua funcionando.

  • Servidor

    Para quem ele envia texto cifrado e de quem aceita alterações

    Limites de login, expiração de sessões, regras de rede, o período de espera do código de recuperação e o corte de acesso de quem você removeu.

    Se alguém tomar o controle do servidorPara de funcionar.

  • Cliente

    O que o seu navegador e o agente conferem

    Assinaturas, números de versão e impressões digitais: os dispositivos recusam qualquer coisa sem assinatura ou mais antiga do que já viram. Esconder valores na tela também é uma regra do cliente, e evita acidentes, não cópias.

    Se alguém tomar o controle do servidorContinua funcionando, a menos que o servidor envie uma página web adulterada.

  • Versões publicadas verificáveis

    Se o código que você roda é autêntico

    Cada versão do agente e do app web é assinada com Ed25519. O build web é reproduzível, e a página não permite scripts de terceiros.

    Se alguém tomar o controle do servidorO agente continua conferindo as atualizações. O app web se confere dentro da própria página que confere, então não consegue pegar um servidor que altere as duas coisas.

Exemplo. A Kiteline é uma empresa fictícia.

Ataque por ataque

Um cartão para cada atacante do modelo de ameaças do Crunu. O veredito diz respeito aos valores dos seus ambientes; todo o resto que um atacante consegue está listado no cartão.

  • ProtegidoOs seus valores continuam ilegíveis e inalterados.
  • LimitadoEle consegue algo real, indicado no cartão.
  • Sem proteçãoO Crunu não tem como impedir. O cartão diz o que ajuda.

  1. Uma cópia do banco de dados vaza

    Protegido

    Um backup vazado, um disco roubado, uma invasão de outro serviço ou uma empresa de hospedagem agindo de má-fé.

    O que consegue

    • Texto cifrado de todos os ambientes, chaves públicas e registros assinados
    • Metadados: nomes de projetos e ambientes, quem está na equipe e com que frequência as coisas mudam
    • Tokens, mas só como hashes com chave (HMAC)

    O que não consegue

    • Os seus valores: não há nenhuma chave de descriptografia em lugar nenhum da cópia
    • Um atalho para a sua senha: cada palpite também precisa da sua Secret Key, que nunca esteve no servidor, então testar um único palpite significa percorrer cerca de 2¹²⁸ possibilidades
    • Tokens que funcionem: a chave desses hashes não fica armazenada no banco de dados

    Não coloque segredos em nomes: um projeto com o nome de um negócio ainda não anunciado conta sobre esse negócio a quem ler a cópia.

    Protegido porCriptografiaServidor

  2. Alguém toma o controle do servidor

    Limitado

    Controle do código e do banco de dados dele: um invasor, um operador mal-intencionado ou uma conta de nuvem sequestrada. Em app.crunu.com, quem opera esse servidor é o Crunu; num servidor próprio, é você.

    O que consegue

    • Tudo o que há numa cópia do banco de dados, mais quem baixou qual versão e quando
    • O poder de negar o serviço ou de perder as suas alterações
    • A chance de enviar uma página web adulterada que capture a sua senha e a sua Secret Key quando você entra. Este é o principal risco que resta.

    O que não consegue

    • Um lugar entre os destinatários: as chaves dos ambientes são seladas apenas para chaves que a sua organização certificou, e os seus dispositivos conferem a lista de acesso assinada
    • Uma chave trocada ou dados alterados: as chaves ficam fixadas em registros assinados, e cada versão é assinada e vinculada ao seu ambiente e ao seu número
    • Uma reversão silenciosa num dispositivo que já viu dados mais novos. Um dispositivo que nunca os viu não tem como perceber.

    O app se confere com o manifesto assinado do Crunu a cada carregamento, e a página não permite scripts de terceiros. Essa verificação roda dentro da mesma página, então não consegue pegar um servidor que altere as duas coisas.

    Protegido porCriptografiaCliente

  3. Alguém intercepta a conexão

    Limitado

    Um certificado TLS forjado ou um proxy malicioso entre o seu dispositivo e o servidor.

    O que consegue

    • O que o servidor vê nessa conexão: texto cifrado e metadados
    • A mesma chance que tem quem toma o controle do servidor de enviar uma página web adulterada

    O que não consegue

    • A sua senha ou a sua Secret Key: nenhuma das duas passa pela rede, de forma alguma
    • Um login para reaproveitar: cada assinatura de login inclui o endereço do servidor e um valor de uso único (nonce), então funciona uma vez, e só nesse servidor

    Protegido porCriptografiaCliente

  4. Um colega sai em maus termos

    Limitado

    Alguém que você removeu da organização e que guardou tudo o que pôde.

    O que consegue

    • Tudo o que a pessoa viu antes da remoção. Esses valores continuam funcionando nos seus provedores até você reemiti-los.

    O que não consegue

    • Mais nada do servidor: ele para de atender a pessoa na hora
    • Versões novas: cada chave de ambiente que a pessoa tinha é rotacionada, então as chaves antigas dela não abrem nada novo, mesmo com texto cifrado roubado

    O relatório de exposição mostra quais versões a pessoa recebeu, e o checklist de reemissão lista os valores a trocar em cada provedor.

    Protegido porServidorCriptografia

  5. Um colega olha além da própria função

    Protegido

    Um membro honesto, mas curioso: uma pessoa desenvolvedora com acesso a development ou alguém com a função Operator que configura máquinas.

    O que consegue

    • Os ambientes que recebeu, que pode copiar. Esconder valores no app é uma escolha de exibição, não criptografia.

    O que não consegue

    • O ambiente production a partir de um acesso a development: a pessoa não tem a chave dele
    • Valor nenhum como Operator: essa função não tem nenhuma chave de ambiente
    • Outros arquivos com a função Specific files: a pessoa recebe uma cópia selada apenas dos arquivos escolhidos

    Protegido porCriptografia

  6. Um token de sessão é roubado

    Limitado

    Copiado da memória do navegador ou de um log de proxy.

    O que consegue

    • O que o servidor permite àquela conta até a sessão terminar: depois de 12 horas sem atividade ou, no máximo, 7 dias

    O que não consegue

    • Os seus valores: descriptografá-los exige chaves que o token não carrega
    • Alterações assinadas: uma lista de acesso ou uma versão precisa da sua chave de assinatura
    • O controle da sua conta: trocar a sua senha ou a sua Secret Key exige as duas

    A sua conta lista cada dispositivo e cada sessão, e você pode encerrar uma ou todas.

    Protegido porServidorCriptografia

  7. O seu notebook é roubado

    Limitado

    Um dispositivo em que você entrou na conta, levado com o app aberto ou bloqueado.

    O que consegue

    • A sua Secret Key, que o navegador guarda por padrão, deixando a sua senha como barreira
    • O que estiver aberto, até o app bloquear após 10 minutos sem atividade (o padrão)

    O que não consegue

    • As suas chaves depois que o app bloqueia: elas continuam criptografadas sem a sua senha
    • A sua conta: uma sessão aberta não consegue alterar a sua senha, a sua Secret Key nem as chaves da sua conta

    De outro dispositivo, remova o roubado ou use Device compromised: ele substitui as chaves da sua conta e rotaciona cada ambiente cuja chave você tinha.

    Protegido porCriptografiaServidor

  8. Alguém obtém root numa máquina com o agente

    Limitado

    Um servidor que roda o agente crunu é um destinatário legítimo, e quem o controla também é.

    O que consegue

    • Tudo o que foi entregue a essa máquina. Um programa que já está rodando mantém as suas variáveis até ser reiniciado.

    O que não consegue

    • Outras máquinas ou ambientes: cada máquina tem as próprias chaves e recebe só o que lhe foi dado
    • Acesso por muito tempo: uma concessão termina após 24 horas sem contato, e uma máquina revogada perde os seus ambientes em minutos enquanto estiver online

    Protegido porCriptografiaServidor

  9. Um código de registro vaza

    Protegido

    O código de uso único que você passa para o crunu enroll numa máquina nova.

    O que consegue

    • A chance de registrar uma máquina própria, se usar o código antes da sua máquina

    O que não consegue

    • A aprovação: um administrador só aprova uma máquina depois de comparar a impressão digital que o crunu enroll mostra na máquina real
    • Uma segunda tentativa silenciosa: o código dura 15 minutos por padrão, é invalidado no primeiro uso, e um código reutilizado dispara um alerta

    Protegido porCriptografiaServidor

  10. Um token de CI vaza

    Limitado

    Um token de serviço copiado do armazenamento de segredos de um pipeline.

    O que consegue

    • Exatamente o que o token recebeu, muitas vezes um único ambiente, até você revogá-lo ou ele expirar

    O que não consegue

    • Qualquer outro ambiente: a chave de production nunca é selada para um token que não recebeu production
    • Um login de qualquer outro lugar, se o token estiver vinculado com OIDC: sem o token do seu provedor de CI para o repositório e o branch certos, ele não entra

    Protegido porCriptografiaServidor

  11. Alguém tenta adivinhar senhas no servidor

    Protegido

    Tentativas de login a partir de um endereço ou espalhadas por muitos.

    O que consegue

    • 10 tentativas com falha por endereço IP e 5 por conta a cada 15 minutos

    O que não consegue

    • Uma pista de que a conta existe: um e-mail desconhecido e uma senha errada recebem a mesma resposta
    • Entrar só com a senha: o login também precisa da sua Secret Key, e um dispositivo novo precisa do seu segundo fator depois que você ativa um
    • Um atalho por códigos e links: eles têm pelo menos 128 bits aleatórios e são armazenados como hashes com chave

    Protegido porServidorCriptografia

  12. Alguém adultera uma versão do agente

    Protegido

    Um binário do crunu ou um script de instalação modificado.

    O que consegue

    • Uma forma de entrar só se também controlar o app web que mostra o seu comando de instalação, como quando alguém toma o controle do servidor

    O que não consegue

    • Uma instalação silenciosa: o comando de instalação no app web traz somas de verificação SHA-256 do manifesto da versão, e o app web confere a assinatura Ed25519 do manifesto
    • Uma atualização silenciosa: o crunu self-update confere a assinatura da versão com uma chave embutida no agente

    Protegido porCriptografiaCliente

  13. Um malware roda no seu dispositivo

    Sem proteção

    Um keylogger, uma extensão de navegador maliciosa ou alguém com root no seu computador.

    O que consegue

    • A sua senha e a sua Secret Key enquanto você as digita, e tudo o que esse dispositivo descriptografa

    O que não consegue

    • Ambientes que a sua conta não consegue abrir

    Nenhuma criptografia protege um dispositivo de si mesmo. Use dispositivos que você controla e, depois de um comprometimento, use Device compromised a partir de um dispositivo limpo e reemita os valores que ele podia alcançar.

    Protegido porNada no Crunu

Cada limite conhecido e o que fazer a respeito

A criptografia

Blocos padrão em duas implementações: o WebCrypto nativo do navegador e a biblioteca padrão do Go no agente. As duas são testadas com os mesmos vetores de teste compartilhados.

A criptografia
AlgoritmoO que faz no CrunuOnde roda
AES-256-GCMCriptografa cada versão de um ambiente. Os dados autenticados adicionais (AAD) vinculam o texto cifrado à sua organização, ao seu ambiente e ao seu número de versão, então ele não pode se passar por outro.Navegador e agente
X25519Sela uma chave de ambiente para um destinatário: uma pessoa, uma máquina ou um token de serviço. Cada cópia selada usa um par de chaves novo.Navegador e agente
Ed25519Assina listas de acesso, versões, links de compartilhamento e versões publicadas. Os dispositivos conferem cada assinatura antes de confiar num registro.Navegador e agente; o Crunu assina as versões publicadas
HKDF-SHA256Deriva uma chave separada para cada função a partir de um único segredo, então nenhuma chave serve a dois propósitos.Navegador, agente e servidor
PBKDF2-SHA256, 1.000.000 iterações e a Secret KeyTransforma a sua senha em uma metade da chave da sua conta. A sua Secret Key, cerca de 128 bits aleatórios, é a outra metade. Nenhuma das duas sai do seu dispositivo.O seu navegador, ou o crunu no terminal
SHA-256Encadeia as entradas do log de auditoria numa cadeia de hashes e gera impressões digitais de chaves que dá para comparar a olho.O servidor escreve a cadeia; o seu navegador e as suas próprias ferramentas podem recalculá-la
Preenchimento até 4.096 bytesArredonda cada versão criptografada para blocos inteiros de 4 KB, então o tamanho exato dela não aparece.Navegador e agente, antes de criptografar
  • Uma chave para cada ambiente. Acesso a development não abre nada em production. Cada pessoa, máquina e token recebe a própria cópia selada apenas das chaves que lhe são permitidas.
  • Todo formato traz a sua versão. Cada registro informa a versão do seu formato ("v": 2), e a derivação de chaves tem a dela (kdf.v). Os dispositivos recusam versões que não conhecem, então o servidor não consegue facilitar a adivinhação da sua senha nem introduzir um formato mais antigo.

Computadores quânticos

Um computador quântico grande o bastante quebraria alguns desses blocos e mal arranharia outros. Nenhum computador assim existe hoje. Aqui está a posição do Crunu, sem tentar adivinhar quando um poderá existir.

Computadores quânticos
AlgoritmoAtaque quânticoO que significaria para o Crunu
AES-256-GCMAlgoritmo de Grover: uma busca mais rápida pela chaveRestam cerca de 128 bits de segurança. O NIST espera que o AES-256 continue seguro por muito tempo.
SHA-256 e HMACBusca no estilo de GroverSobra uma margem ampla para a cadeia de hashes do log de auditoria e para os hashes com chave. O NIST usa o SHA-256 como referência para os seus níveis de segurança pós-quântica.
PBKDF2 e a Secret KeyBusca no estilo de Grover; o algoritmo de Shor não se aplicaAdivinhar ainda exige os 128 bits aleatórios da Secret Key, o tamanho de uma chave AES-128, que o NIST espera que continue segura por décadas. Nem a senha nem a Secret Key chegam ao servidor.
X25519Algoritmo de Shor: a chave privada a partir da públicaQuebrado. As chaves de ambiente seladas com ele poderiam ser abertas.
Ed25519Algoritmo de ShorQuebrado. Assinaturas poderiam ser forjadas, mas só no momento de um ataque. Dados passados não ficam expostos.

Colher agora, descriptografar depois

Cada chave de ambiente é selada para as chaves públicas X25519 dos destinatários, e as cópias seladas ficam armazenadas no servidor ao lado dessas chaves públicas. Quem guardar uma cópia do banco de dados poderia, quando existir um computador quântico grande, abrir essas cópias seladas e ler as versões salvas naquela cópia do banco. O NIST chama essa ameaça de “harvest now, decrypt later” (colher agora, descriptografar depois).

Ela alcança só o que essa cópia contém. Versões salvas depois que a cópia foi feita não estão nela, e uma credencial que você já reemitiu no provedor não vale nada para quem descriptografar a antiga.

A sua senha, a sua Secret Key e a chave da sua conta não ficam expostas dessa forma: elas nunca chegam ao servidor, e só funções simétricas são usadas nelas. O ataque também não precisa delas, porque vai direto às chaves X25519.

Assinaturas

As assinaturas Ed25519 protegem listas de acesso, versões e versões publicadas. Um computador quântico permitiria forjar assinaturas novas, mas uma falsificação só importa quando é feita e aceita, então é um risco para o dia em que esse computador existir, não para dados registrados hoje. O NIST diz o mesmo: as assinaturas não correm risco com “harvest now, decrypt later”.

O que o Crunu usa hoje e o que vem depois

Hoje o Crunu não usa algoritmos pós-quânticos. O NIST publicou os primeiros padrões pós-quânticos em agosto de 2024: ML-KEM para estabelecer chaves (FIPS 203) e ML-DSA para assinaturas (FIPS 204). O plano de transição do NIST, finalizado em outubro de 2026, inclui o acordo de chaves com curvas elípticas e o EdDSA entre os algoritmos que vai descontinuar depois de 2030 e deixar de permitir nos padrões do NIST depois de 2035.

A migração para a criptografia pós-quântica está no roadmap do Crunu. Não anunciamos algoritmos nem datas com que ainda não podemos nos comprometer: quando a criptografia do Crunu mudar, esta página vai informar isso.

O que você pode fazer agora

  • Pense por quanto tempo cada segredo continua valioso. Uma chave que você reemite a cada poucos meses perde pouco com uma cópia descriptografada anos depois; uma credencial raiz de longa duração perde mais.
  • Reemita valores de longa duração nos provedores de forma periódica e salve cada valor novo como uma nova versão.
  • Se uma cópia do banco de dados nas mãos de outra pessoa é a sua preocupação, rode o seu próprio servidor. Assim, o banco de dados e os backups dele ficam com você.

Fontes

  1. NIST: NIST Releases First 3 Finalized Post-Quantum Encryption Standards (August 13, 2024)
  2. NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (August 2024)
  3. NIST FIPS 204: Module-Lattice-Based Digital Signature Standard (August 2024)
  4. NIST IR 8547: Transition to Post-Quantum Cryptography Standards (October 2026)
  5. NIST: Post-Quantum Cryptography FAQs (AES and Grover’s algorithm)
  6. L. K. Grover: A fast quantum mechanical algorithm for database search (1996)
  7. P. W. Shor: Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer (1997)

Conferido em 28 de outubro de 2026.

Confira por conta própria

Ainda não temos selos nem certificados para mostrar. Aqui está o que você pode conferir hoje e o que ainda não existe.

  • Versões assinadas.Cada versão do agente e do app web é assinada com uma chave de release Ed25519. O crunu self-update confere a assinatura com uma chave embutida no agente, e o app web mostra Signed build depois de se conferir com o manifesto assinado.
  • Um build web reproduzível.Um mesmo commit do código-fonte sempre gera os mesmos arquivos, byte a byte. O código-fonte não é público, então hoje só o Crunu consegue gerar uma versão de novo e comparar.
  • Nenhum script de terceiros.A política de segurança de conteúdo (CSP) da página só permite o código do próprio Crunu, que ela carrega com somas de integridade (SRI).
  • Poucas dependências.O agente usa apenas a biblioteca padrão do Go, e o código do navegador inclui um único pacote npm, o yaml.
  • Um log de auditoria que você pode conferir fora do Crunu.Owners e admins podem exportar o log em JSONL e recalcular a cadeia de hashes SHA-256 com as próprias ferramentas.
  • O que falta.Nenhuma auditoria de segurança externa, nenhuma certificação SOC 2 ou ISO 27001 e nenhum código-fonte publicado. O Crunu está em acesso antecipado; Auditorias e documentos lista os documentos que temos.
  • Encontrou um problema?Escreva para security@crunu.com. O mesmo contato está no nosso security.txt, e Limitações conhecidas lista cada limite que já conhecemos.
Exemplo. A Kiteline é uma empresa fictícia.

Perguntas sobre a segurança do Crunu

O Crunu consegue ler os meus segredos?

Não. O servidor, operado pelo Crunu em app.crunu.com ou por você num servidor próprio, armazena só texto cifrado e não tem nenhuma chave capaz de descriptografá-lo. Ele vê metadados: nomes, endereços de e-mail, o log de auditoria e quando cada versão foi salva. Chegar aos seus valores exigiria alterar o código no seu dispositivo, por exemplo com uma página web adulterada, que é o principal risco que resta nesta página.

O que acontece se o servidor de vocês for invadido?

Quem invadir consegue texto cifrado, chaves públicas, hashes com chave dos tokens e metadados. Não consegue descriptografar os seus valores, se incluir numa lista de acesso nem alterar uma versão sem que os seus dispositivos percebam. Pode parar de atender você ou enviar uma página web adulterada. Se app.crunu.com for invadido, avisaremos por e-mail os titulares das contas afetadas sem demora injustificada.

E se eu esquecer a minha senha?

Ninguém consegue redefini-la, nem nós, porque nunca recebemos a sua senha nem a sua Secret Key. O seu Emergency Kit impresso e um código de recuperação são os caminhos de volta. Se você perder tudo isso, a sua conta não pode ser aberta, embora owners e admins ainda consigam abrir os ambientes compartilhados da organização.

O Crunu protege contra computadores quânticos?

Em parte. Espera-se que o AES-256 e o SHA-256 resistam. O X25519 e o Ed25519 cairiam diante de um computador quântico grande, que não existe hoje. Hoje o Crunu não usa algoritmos pós-quânticos, então uma cópia do banco de dados guardada por anos poderia um dia expor as versões que contém. A migração para a criptografia pós-quântica está no roadmap do Crunu.

O Crunu já passou por auditoria?

Não. O Crunu está em acesso antecipado, não tem certificação SOC 2 nem ISO 27001, e nenhuma auditoria de segurança externa foi publicada. O código-fonte também não é público. O que você pode conferir hoje está acima, em “Confira por conta própria”.

Rodar o meu próprio servidor é mais seguro que usar app.crunu.com?

Muda em quem você confia, não a criptografia. O seu próprio servidor mantém o banco de dados e os backups com você e entrega a página web a partir de uma infraestrutura que você controla. Em troca, backups, atualizações e o segredo próprio do servidor passam a ser responsabilidade sua. O servidor é disponibilizado sob pedido: escreva para support@crunu.com.

Como relato uma vulnerabilidade?

Escreva para security@crunu.com com os passos para reproduzi-la e não inclua segredos reais no relato. O mesmo contato está no nosso arquivo security.txt, e a página Modelo de segurança lista as regras para testes.

Guarde os segredos da sua equipe num servidor que não consegue lê-los

Crie a sua conta em app.crunu.com. As suas chaves são geradas no seu navegador, e o servidor só recebe texto cifrado.

Grátis durante o acesso antecipado. Leia o modelo de segurança