Não existe uma «descriptografia» para um segredo VPN codificado

A expressão descodificar a chave codificada pressupõe uma única operação que não existe. Um segredo VPN armazenado pode ser bytes codificados em base, um blob cifrado ligado a um keystore ou um verificador de sentido único que não pode ser invertido de forma alguma, e cada um exige uma resposta diferente. A codificação base não acrescenta confidencialidade por conceção, pelo que descodificá-la pode recuperar um segredo utilizável em vez de revelar um protegido. Começar pelo campo e pelo produto que o escreveu é a única identificação fiável.

Mantenha o valor longe dos descodificadores web e das publicações públicas em fóruns, porque um segredo codificado continua a ser um segredo.

Codificação, cifra e verificador são três coisas

A RFC 4648 define as codificações base como representações de dados em ambientes restritos, e a sua secção de segurança afirma claramente que não proporcionam qualquer confidencialidade computacional. Isto significa que qualquer pessoa pode reconverter um campo Base64 em bytes, o que é um risco de recuperação e não uma barreira criptográfica. A cifra é diferente: sem o material da chave, os bytes permanecem opacos. Um verificador é diferente outra vez, porque foi concebido para não ser invertido. Ler o nome documentado do campo costuma dizer qual dos três tem.

Chamar Base64 a uma cadeia não estabelece o que ela contém. Pode descodificar para uma chave, para uma estrutura serializada ou para preenchimento aleatório, e o aspeto do texto não diz nada sobre qual.

Identifique o campo antes de lhe tocar

Anote o produto exportador e a versão, o formato do perfil e o nome documentado do campo. Depois separe os tipos de segredo envolvidos: uma chave pré-partilhada de grupo não é uma palavra-passe de conta individual, nem uma frase de acesso de chave privada, nem um token de autenticação. Têm proprietários diferentes e procedimentos de substituição diferentes, e confundi-los altera a credencial errada. Um perfil que ainda liga também não é permissão para extrair uma credencial que pertence a outra pessoa.

A informação útil para dar ao suporte é o produto, o campo, o erro e o objetivo autorizado. O segredo em si não faz parte dessa lista.

A recuperação é um procedimento autorizado, não um descodificador

Se o produto documenta uma exportação reversível para recuperação autorizada, use o próprio procedimento de importação ou recuperação dentro de um ambiente protegido. Preserve o ficheiro original e mantenha o material descodificado fora de registos, do histórico da shell e dos pedidos. Se o valor estiver cifrado ou ligado a um armazenamento protegido, o método de desbloqueio documentado e a autorização necessária vêm do proprietário, porque a descodificação não fornece nem uma chave nem o contexto de acesso de outro utilizador. Quando o campo contém um verificador, siga o percurso de substituição documentado em vez de tentar descodificadores.

Quando o proprietário não pode recuperar ou reemitir o valor em segurança, a resposta é uma credencial nova e configurações de par atualizadas. Isso é um projeto com uma transição, não um comando.

Substituir um segredo partilhado é uma mudança coordenada

Sobrescrever um segredo partilhado de produção apenas de um lado quebra todos os clientes aprovados que ainda têm o valor anterior. Planeie a transição, decida se algum acesso deve ser revogado e mantenha um caminho de recuperação disponível antes de alterar qualquer um dos extremos. Anuncie a janela às pessoas que vão notar.

Se o valor original foi exposto, a rotação é a resposta correta e descodificá-lo não acrescenta nada. Um segredo exposto está comprometido quer alguém tenha recuperado os bytes quer não.

Anote onde vive o novo valor e a quem pertence. O próximo incidente vai pedir isso, não um descodificador.