Identificador de Hash

Duas classes de hash, dois níveis de certeza

Formatos modernos de senha são autodescritivos. Um valor que começa com $2b$, $argon2id$ ou $y$ anuncia o próprio esquema, e o restante da string é dividido em campos por cifrão: parâmetros, salt e digest. Aí a identificação não é palpite, é leitura. Foi por isso que o padrão do crypt(3) foi desenhado assim: para validar a senha, o sistema precisa saber com qual função e com quais parâmetros o hash foi gerado.

Digests crus são o oposto. Um SHA-256 é só a saída da função, 32 bytes sem nenhum metadado, escritos como 64 caracteres hexadecimais. Nada nesses 64 caracteres distingue um SHA-256 de um Keccak-256 ou de um BLAKE2s-256. Por isso a ferramenta muda de linguagem nesse caso: em vez de afirmar, ela ranqueia por frequência observada e explica cada posição, deixando claro que a decisão final depende de onde o dado foi encontrado.

• Com prefixo: formato lido diretamente da string, com parâmetros e salt separados.
• Sem prefixo: candidatos ranqueados por probabilidade, com o motivo de cada posição.
• Alfabeto e comprimento aparecem como fatos, não como conclusão.
• Quando a entrada não é hash, a ferramenta diz o que ela é.

O que os parâmetros do hash contam sobre o sistema

Identificar o algoritmo é metade da informação. A outra metade são os parâmetros, e eles ficam visíveis no próprio hash. No bcrypt, o número entre cifrões é o fator de custo: 12 significa 2 elevado a 12, ou seja, 4096 iterações da função de derivação. No Argon2, m é a memória em KiB, t é o número de passagens e p é o paralelismo, os três parâmetros que definem quanto hardware um ataque precisaria. No PBKDF2, sha256crypt e sha512crypt, o campo de iterações diz a mesma coisa em uma escala diferente.

Isso muda a leitura de uma auditoria. Um bcrypt com custo 4 e um bcrypt com custo 14 são o mesmo algoritmo com ordens de grandeza de diferença no custo de ataque. Um Argon2id com 64 MiB de memória e um com 8 MiB idem. Ver esses números junto do nome do formato é o que transforma a identificação em diagnóstico, e é por isso que a ferramenta extrai e mostra cada um deles em vez de parar no nome.

O que a identificação por inspeção não resolve

Nenhuma ferramenta de identificação, esta ou qualquer outra, distingue algoritmos que produzem saídas do mesmo tamanho e do mesmo alfabeto. Truncamento também engana: um SHA-256 cortado em 32 caracteres passa a parecer MD5, e não há como saber pela string que houve corte. Da mesma forma, um hash com salt guardado em outra coluna do banco chega aqui como um digest cru, sem sinal nenhum de que existe salt em algum lugar.

O contexto de origem resolve quase todos esses casos e nenhuma inspeção substitui ele. Um valor exportado de um controlador de domínio é NTLM, mesmo tendo a cara de MD5. Um valor tirado do campo de senha de um CMS antigo costuma ser MD5 ou phpass, dependendo da versão. Um valor em um arquivo de integridade é quase sempre SHA-256. Por isso a saída aqui é uma hipótese ranqueada com o raciocínio à mostra, para você confirmar com o que sabe da origem, e nunca uma sentença.

• Digests truncados imitam o comprimento de outros algoritmos.
• Salt guardado em coluna separada não aparece no valor.
• Codificação (base64, hex maiúsculo) muda a aparência sem mudar o algoritmo.
• A origem do dado costuma valer mais que qualquer heurística de formato.