Ferramentas para desenvolvedores · SHA calculadora de hash
SHA-1 Colisões explicadas: o que ainda é seguro e o que deve ser migrado
· Por que é importante
sha-256 criptografia segurança
Um scanner sinaliza SHA-1 e a gerência pergunta qual é a urgência. Esta postagem explica o que um ataque de colisão faz e o que não interrompe, onde SHA-1 ainda é tolerado e como planejar uma migração.
O scanner diz que SHA-1 está quebrado — mas quebrado para quê? A questão que decide a urgência da migração
Um scanner de segurança de rede sinaliza SHA-1 em sua infraestrutura. A administração pergunta quão urgente é isso. A resposta depende inteiramente para que você está usando SHA-1, e essa pergunta revela se você tem um problema de conformidade, um problema de segurança ativo ou simplesmente um artefato legado que deve ser catalogado. SHA-1 está criptograficamente quebrado – demonstrações acadêmicas provaram colisões. Mas "quebrado" significa coisas diferentes dependendo da função que SHA-1 desempenha em seu sistema.
Um hash criptográfico serve a propósitos diferentes em contextos diferentes. Às vezes, é uma soma de verificação que protege contra corrupção acidental. Às vezes é um compromisso, como uma soma de verificação de download publicada que permite aos usuários verificar se receberam o arquivo pretendido pelo editor. Às vezes, faz parte de uma cadeia de assinaturas ou certificados, onde um invasor com controle suficiente pode produzir dois documentos, ambos significativos, que compartilham o mesmo hash e, assim, falsificar a autenticação. A gravidade de uma colisão SHA-1 depende criticamente de qual dessas funções SHA-1 possui em seu sistema.
Colisão versus pré-imagem — por que os ataques demonstrados publicamente têm como alvo colisões e o que isso significa para um hash existente
Um ataque de colisão produz duas entradas diferentes com a mesma saída. Um invasor não encontra uma mensagem com hash para um valor predeterminado – isso seria um ataque de pré-imagem e permanece inviável para SHA-1. Em vez disso, um ataque de colisão significa que o invasor pode criar dois documentos com hash idêntico. Se um sistema depende de um hash para provar que duas coisas são iguais, uma colisão quebra essa prova. O invasor deve criar ambas as entradas, o que requer tempo e computação, mas o resultado são duas coisas distintas que parecem idênticas no hash.
Um ataque de pré-imagem significaria que um invasor poderia pegar um hash SHA-1 publicado e encontrar alguma entrada correspondente a ele. Não é assim que os ataques SHA-1 funcionam. Se você possui um repositório de resumos SHA-1 e se preocupa se um arquivo realmente corresponde a eles, um ataque de colisão não é a ameaça. A ameaça é se alguém com acesso ao seu repositório poderia falsificar um arquivo diferente para o mesmo resumo. Na maioria dos casos, isso também não é realista sem o controle do próprio processo de hashing. O modelo de ataque específico é tão importante quanto o algoritmo.
As demonstrações 2017 — dois arquivos diferentes com o mesmo SHA-1, descritos qualitativamente, e o trabalho com prefixo escolhido que se seguiu
O ataque SHAttered de 2017 demonstrou uma colisão prática: dois arquivos PDF diferentes com o mesmo resumo SHA-1. Os pesquisadores construíram cuidadosamente ambos os arquivos, transformando-os em PDFs válidos durante a colisão. O trabalho exigiu um esforço computacional substancial e hardware especializado. O que importa é que isso foi possível: a resistência à colisão que justifica o uso de SHA-1 para segurança desapareceu. O ataque provou que dois documentos semanticamente diferentes poderiam comcomcompartilhar um resumo, o que quebra qualquer sistema que confie no resumo como prova de identidade.
O ataque que se seguiu em 2020, chamado "SHA-1 é uma bagunça", deu o próximo passo: colisões de prefixo escolhido. Esta variante significa que um invasor pode pegar dois documentos arbitrários, concatenar sufixos diferentes para cada um e produzir uma colisão. Este é o ataque perigoso para assinaturas e certificados. Um invasor não precisa começar do zero; eles podem colidir dois documentos distintos e significativos. Isso quebra o modelo de segurança de qualquer sistema que assine resumos SHA-1. O invasor pode produzir dois documentos com hash iguais e com significados diferentes.
Onde SHA-1 é inaceitável — assinaturas, certificados e qualquer coisa que um invasor possa influenciar ambos os lados
A distinção é importante porque SHA-1 ainda é tolerável em algumas funções e absolutamente inaceitável em outras. No Git, SHA-1 é usado como endereço de conteúdo – um nome para um instantâneo específico de arquivos. Git não usa SHA-1 para autenticação; é um esquema de nomenclatura. Um invasor poderia, teoricamente, calcular dois estados de repositório diferentes com o mesmo ID, mas isso requer o controle de todo o processo de criação de conteúdo e o envio de ambas as versões antes que alguém perceba. Para a maioria das equipes, esse nível de controle do invasor não é o modelo de ameaça. É por isso que o Git está fazendo a transição para SHA-256 deliberadamente, em vez de tratá-lo como uma emergência.
Em um cenário de verificação de download na Web, um editor publica um arquivo e sua soma de verificação SHA-1 no mesmo servidor. Um invasor que compromete esse servidor controla tanto o arquivo quanto a soma de verificação. Eles podem fazer upload de um arquivo e postar seu SHA-1, e nenhuma colisão é necessária. Se a soma de verificação for postada em outro lugar — em um VPN seguro, impressa em um e-mail assinado, publicada em infraestrutura diferente — então o invasor deverá colidir, e isso se tornará inviável. A soma de verificação é tão confiável quanto seu canal. É por isso que a verificação de download requer mais do que um hash.
Onde permanece com menos risco — identificação de conteúdo em ambientes não adversários e transição gradual do Git para SHA-256
Para assinaturas e certificados, SHA-1 é indefensável. Um certificado é encadeado a partir de uma raiz confiável. Se uma CA assinar dois certificados diferentes usando o mesmo resumo SHA-1, um ataque de colisão permitirá que um invasor forje um deles. Isto não é teórico: foram documentados ataques contra CAs intermediárias. Qualquer esquema de assinatura que dependa de SHA-1 é potencialmente falsificável por um invasor com recursos suficientes. Todos os principais fornecedores de navegadores e sistemas operacionais descontinuaram SHA-1 em certificados. Novos certificados devem usar SHA-256. Os fornecedores da plataforma falaram claramente porque a ameaça é real e imediata.
NIST, o órgão de padronização dos EUA, declarou um cronograma explícito. A partir de 2024, SHA-1 não deve ser usado para novos aplicativos. A partir de 2030, espera-se que SHA-1 seja totalmente retirado dos sistemas federais. Esta não é uma depreciação vaga; é um mandato concreto para os contratantes governamentais e um sinal para a indústria. Seguir o cronograma de NIST garante que seus sistemas fiquem à frente da curva de depreciação, em vez de correr atrás do prazo.
A evidência do repositório suporta a descontinuação de SHA-1, e não uma publicação NIST não lida ou data de desativação
Os documentos de origem do repositório SHA-1 como interoperabilidade legada e nomes demonstraram trabalho de colisão, mas não contém um cronograma de desativação do órgão de padrões. Esta seção, portanto, corrige o esboço tratando a depreciação como um problema de inventário de engenharia, em vez de citar um número de publicação não lido ou uma data de conformidade.
Para ambientes controlados por políticas, consulte a autoridade que rege essa implantação e registre o documento exato revisado. As evidências do produto aqui apoiam uma ação mais restrita: manter SHA-1 disponível para reproduzir valores existentes, rotulá-lo como inadequado para novos usos de segurança e calcular uma substituição de SHA-256 sempre que o protocolo circundante permitir a migração.
Exemplo resolvido – uma lista de verificação de migração aplicada a uma página legada de verificação de download
Um caminho de migração de SHA-1 geralmente começa com um inventário: onde SHA-1 é usado? Certificados e assinaturas? Prioridade imediata. Repositórios Git e endereçamento de conteúdo? Prioridade média, siga o ritmo de migração do Git. Somas de verificação publicadas para downloads? Depende do modelo de confiança. Somas de verificação internas para desduplicação ou arquivamento? Menor prioridade, mais tempo para planejamento. A fase de inventário revela a verdadeira área de superfície e ajuda a priorizar com base no risco real, em vez da urgência abstrata.
Para cada função, a migração parece diferente. Os certificados são atualizados para SHA-256 imediatamente. Os repositórios Git entram gradualmente nas referências SHA-256, mantendo SHA-1 para compatibilidade com versões anteriores. As somas de verificação de download começam a ser publicadas em SHA-1 e SHA-256 e, eventualmente, apenas em SHA-256. Os resumos SHA-1 legados em um banco de dados de soma de verificação podem ser verificados com a calculadora de hash ToolAcre SHA, e novas entradas devem usar SHA-256. A ferramenta oferece suporte a ambos os lados da transição, permitindo verificar hashes antigos e criar novos.
Conclusão: SHA-1 para comparação, SHA-256 para novos trabalhos - a calculadora de hash ToolAcre SHA inclui SHA-1 para que resumos legados possam ser verificados, não como um endosso
Para a maioria das organizações, a migração não significa “desligar SHA-1 amanhã”. É “entender onde ele é usado, priorizar funções críticas de segurança e ter um plano plurianual”. Um repositório Git com anos de commits SHA-1 deve fazer a transição gradualmente, com ferramentas que lidam com ambos. Uma infraestrutura de certificados já deveria ter migrado. As somas de verificação publicadas devem ser de algoritmo duplo durante uma janela de transição. A migração gradual reduz alterações significativas e dá tempo aos sistemas para se adaptarem à nova realidade.
A calculadora de hash ToolAcre SHA fornece ambos os lados dessa transição. Você pode verificar os resumos SHA-1 existentes de seus sistemas legados para confirmar se um arquivo corresponde a eles. Você pode calcular hashes SHA-256 para começar a publicar o caminho de migração. A ferramenta não finge que SHA-1 é segura; ele o rotula como quebrado e explica o porquê. Mas permite que você trabalhe com os hashes legados que você ainda precisa manter enquanto constrói a ponte para SHA-256 e planeja sua descontinuação.