Redator de segredos
Um redator de segredos examina o texto que está prestes a partilhar —um excerto de registo, um ticket de suporte, uma mensagem de chat, um despejo de configuração— e remove as credenciais escondidas dentro dele antes que outra pessoa as leia. Cole texto ou largue um ficheiro aqui e ele encontrará chaves API de fornecedores, tokens de acesso, blocos de chave privada, JSON Web Tokens, números de cartão e endereços de e-mail, mostrará cada ocorrência mascarada numa tabela e construirá uma cópia limpa com cada segredo substituído por [REDACTED]. Tudo funciona 100% no seu navegador: nada é enviado, nada é armazenado e analisar texto não faz nenhum pedido de rede. O guia complementar, redija os segredos antes de colar, explica o que os scanners podem e não podem detetar; para capturas do navegador use o analisador HAR, e para ficheiros de configuração o analisador .env.
Última atualização:
Ou largue um ficheiro de texto em qualquer lugar desta caixa. Limite: 2 MB. O ficheiro é lido apenas neste dispositivo e nunca é enviado.
Resultados da análise
Pré-visualização destacada (mascarada)
Ocorrências
O que o scanner procura — e como decide
A maioria dos segredos não vaza por ataques, mas por vontade de ajudar. Alguém cola um registo num ticket, um ficheiro de configuração num chat, um comando curl num fórum — e a credencial que por acaso ia dentro viaja com isso, para sistemas que indexam, reencaminham e arquivam texto para sempre. Esta página é a pausa antes dessa colagem. Escreva ou largue o texto e a análise corre enquanto escreve: uma faixa de contagens soma as ocorrências por tipo, a pré-visualização destaca cada ocorrência no seu lugar com o valor mascarado, a tabela de ocorrências lista o tipo, a forma mascarada e o número da linha, e a cópia redigida abaixo substitui cada ocorrência pelo marcador único [REDACTED], pronta para copiar ou descarregar como ficheiro .txt.
A primeira camada de deteção é a forma. As credenciais reais de fornecedores reais têm formas reconhecíveis, e o scanner conhece as principais: chaves de acesso da AWS, tokens do GitHub na forma clássica e de grão fino, chaves secretas e restritas da Stripe, chaves de projeto e genéricas da OpenAI, chaves da Anthropic, chaves API da Google e tokens do Slack. Um bloco de chave privada é capturado como uma única ocorrência completa, da sua linha BEGIN à sua linha END, porque redigir apenas parte de um bloco de chave deixa uma chave utilizável. Os JSON Web Tokens são reconhecidos pela sua estrutura de três segmentos base64url, e os números de cartão têm de passar a soma de verificação de Luhn antes de serem assinalados, para que números de encomenda e carimbos de tempo comuns fiquem em silêncio.
Entropia, marcadores de posição e os limites honestos
A segunda camada cobre os segredos que não têm forma de fornecedor: atribuições como password = …, api_key: … ou client_secret = …. Uma palavra-chave nua não prova nada, por isso o valor tem de passar mais duas portas — pelo menos doze caracteres e uma entropia de Shannon de pelo menos 3,2 bits por caráter, que as chaves aleatórias passam facilmente e as palavras comuns não. Os valores de marcador de posição são excluídos por desenho: tudo o que contenha example, test, dummy, xxx, your-, placeholder ou changeme é documentação, não uma credencial, e assinalá-lo treiná-lo-ia para ignorar o scanner. Quando as formas se sobrepõem, ganha o padrão específico: uma chave da Stripe atribuída a uma variável é comunicada uma só vez, como chave da Stripe.
Dois tipos de ocorrência protegem pessoas em vez de sistemas. Os endereços de e-mail são assinalados como dados pessoais, porque um ticket cheio de endereços de clientes é um incidente de privacidade mesmo que não apareça nenhuma palavra-passe. Os números de cartão só são assinalados quando os dígitos passam Luhn, a soma de verificação incorporada em cada número de cartão genuíno — o mesmo teste que permite ao scanner ignorar números de fatura, códigos de rastreio e carimbos Unix que apenas parecem longos e numéricos. No ecrã, cada valor é mascarado até mostrar no máximo os seus quatro primeiros caracteres, de modo que um curioso ou uma captura de ecrã aprendem o tipo e o lugar de um segredo, mas nunca o segredo em si; os valores curtos não mostram nada. O valor completo existe apenas no seu texto original, que nunca sai da página.
Use o redator como um passo dentro de um hábito de partilha mais seguro, não como uma garantia. Redija localmente, partilhe a cópia redigida e envie o segredo real —quando um segredo tem mesmo de mudar de mãos— através de um gestor de segredos ou de uma ligação de partilha que expira, nunca pelo mesmo ticket ou chat que o texto redigido. Se uma credencial real já foi colada sem redação algures, apagar a mensagem não chega: podem já existir cópias, índices e notificações, por isso rode a credencial e trate a antiga como pública. O artigo complementar, redija os segredos antes de colar, percorre esse fluxo completo; o analisador HAR faz o mesmo trabalho para as capturas do navegador, e o analisador .env verifica os ficheiros de configuração antes de os confirmar.
A biblioteca de deteção, em linguagem simples
| Chave de acesso da AWS | AKIA ou ASIA seguido de exatamente 16 letras maiúsculas ou dígitos — a forma dos ID de chave de acesso da AWS, temporários e de longa duração. |
| Token do GitHub | Os prefixos ghp_, gho_, ghu_, ghs_ e ghr_ com pelo menos mais 36 caracteres, além da forma de grão fino github_pat_. |
| Chave da Stripe | sk_ ou rk_ seguido de live_ ou test_ e pelo menos 16 caracteres alfanuméricos — chaves secretas e restritas, modo de teste incluído, porque as chaves de teste revelam a estrutura e os hábitos da conta. |
| Chaves da OpenAI e da Anthropic | As chaves de projeto sk-proj- e as chaves sk- genéricas de 32 caracteres ou mais contam como OpenAI; as chaves sk-ant- são comunicadas como Anthropic, um tipo separado com o seu próprio caminho de rotação. |
| Chave API da Google e token do Slack | AIza seguido de 35 caracteres para a Google; os prefixos xoxb, xoxa, xoxp, xoxr e xoxs para os tokens de bot, aplicação, utilizador, atualização e sessão do Slack. |
| Bloco de chave privada | Um bloco PEM completo, de -----BEGIN PRIVATE KEY----- (variantes RSA, EC, OpenSSH e PGP incluídas) até à linha END correspondente, comunicado e redigido como uma única ocorrência. |
| JSON Web Token | Três segmentos base64url separados por pontos, com os dois primeiros segmentos a começar por eyJ — a forma codificada do cabeçalho e da carga JSON com que todo o JWT começa. |
| Atribuição genérica | Valores atribuídos a nomes como api_key, secret, token, password, passwd, auth_token, access_token ou client_secret, assinalados apenas quando o valor tem pelo menos 12 caracteres e a sua entropia de Shannon chega a 3,2; os marcadores documentados nunca são assinalados. |
| Endereço de e-mail | Endereços de e-mail comuns, comunicados como dados pessoais (PII) para que colagens em massa de endereços de clientes ou funcionários sejam apanhadas antes de se propagarem. |
| Número de cartão | Sequências de 13 a 19 dígitos, com espaços e hífenes permitidos, assinaladas apenas quando passam a soma de verificação de Luhn que todo o número de cartão genuíno satisfaz. |
| Mascaramento e o marcador | No ecrã, um valor mostra no máximo os seus quatro primeiros caracteres mais reticências, e nada para valores de quatro caracteres ou menos. Na cópia redigida, cada ocorrência torna-se o marcador único [REDACTED]; o tipo permanece visível na tabela de ocorrências, nunca em linha. |
Perguntas frequentes
O meu texto é enviado ou armazenado algures?
Não. A análise corre nesta página, no seu dispositivo: nada é enviado, transmitido ou armazenado, e analisar não faz nenhum pedido de rede. É uma regra de desenho deliberada — uma ferramenta que lhe pedisse para enviar texto cheio de segredos a fim de remover os segredos faria parte do problema.
Que tipos de segredos consegue encontrar?
Credenciais com forma de fornecedor — chaves de acesso da AWS e chaves e tokens do GitHub, da Stripe, da OpenAI, da Anthropic, da Google e do Slack — além de blocos completos de chave privada, JSON Web Tokens, valores de alta entropia atribuídos a nomes como password ou api_key, endereços de e-mail e números de cartão que passam a soma de Luhn. A tabela de factos acima lista cada padrão em linguagem simples.
Porque falhou um segredo que eu vejo no meu texto?
Três razões honestas. O valor pode estar dividido entre linhas ou embrulhado, de modo que nenhuma forma corresponde. Pode ser uma palavra-passe humana de baixa entropia atribuída a um nome que a regra genérica não conhece. Ou pode ser um formato que nenhum padrão cobre ainda — uma cadeia de ligação de base de dados, um valor de cookie, um URL com autenticação básica. O scanner captura as formas comuns e bem documentadas de forma determinística; é uma rede de segurança, não uma prova de que o texto está limpo, por isso dê você mesmo uma vista de olhos à pré-visualização antes de partilhar.
Porque assinalou algo que não é um segredo real?
Normalmente porque o valor tem honestamente a forma de um: um valor de teste de aspeto aleatório sem palavras de marcador, um token de exemplo de documentação interna, ou um JWT usado como exemplo de front-end. Veja a tabela de ocorrências antes de partilhar — um falso positivo custa uma vista de olhos, enquanto um falso negativo custa uma rotação. Os valores que contêm example, test, dummy, xxx, your-, placeholder ou changeme nunca são assinalados, por isso marcar as amostras dessa forma mantém o ruído baixo.
Redigir um segredo torna-o seguro se o original já vazou?
Não. A redação protege as cópias que fizer a partir de agora; não pode recuperar um ticket, uma mensagem de chat ou um registo que já saiu com o segredo dentro. Trate qualquer credencial que tenha aparecido sem redação num sistema partilhado como pública: rode-a no fornecedor, revogue a antiga e só então partilhe o texto redigido. O artigo complementar, redija os segredos antes de colar, explica a ordem de rodar primeiro e porque apagar a mensagem não chega.