Non existe un «descifrado» para un segredo VPN codificado
A codificación base non engade confidencialidade, e un verificador non se pode inverter de ningún xeito. Identifique o campo antes de recorrer a un decodificador ou a unha substitución.
A frase descifrar a clave codificada supón unha única operación que non existe. Un segredo VPN almacenado pode ser bytes codificados en base, un blob cifrado ligado a un almacén de claves ou un verificador dun só sentido que non se pode inverter de ningún xeito, e cada un precisa unha resposta distinta. A codificación base non engade confidencialidade por deseño, así que decodificala pode recuperar un segredo utilizábel en lugar de revelar un protexido. Comezar polo campo e polo produto que o escribiu é a única identificación fiable.
Manteña o valor fóra dos decodificadores web e das publicacións públicas en foros, porque un segredo codificado segue a ser un segredo.
Codificación, cifrado e verificador son tres cousas
A RFC 4648 define as codificacións base como representacións de datos en ambientes restrinxidos, e a súa sección de seguridade afirma claramente que non proporcionan ningunha confidencialidade computacional. Iso significa que calquera pode devolver un campo Base64 a bytes, o que é un risco de recuperación e non unha barreira criptográfica. O cifrado é distinto: sen o material de clave, os bytes permanecen opacos. Un verificador é distinto outra vez, porque se deseñou para non ser invertido. Ler o nome documentado do campo adoita dicir cal dos tres ten.
Chamar Base64 a unha cadea non establece que contén. Pode decodificar a unha clave, a unha estrutura serializada ou a recheo aleatorizado, e o aspecto do texto non di nada sobre cal.
Identifique o campo antes de tocalo
Anote o produto exportador e a versión, o formato do perfil e o nome documentado do campo. Despois separe os tipos de segredo implicados: unha clave precompartida de grupo non é un contrasinal de conta individual, nin unha frase de paso de clave privada, nin un token de autenticación. Teñen propietarios distintos e procedementos de substitución distintos, e confundilos cambia a credencial equivocada. Un perfil que aínda conecta tampouco é permiso para extraer unha credencial que pertence a outra persoa.
A información útil para o soporte é o produto, o campo, o erro e o obxectivo autorizado. O segredo en si non forma parte desa lista.
A recuperación é un procedemento autorizado, non un decodificador
Se o produto documenta unha exportación reversible para unha recuperación autorizada, use o seu propio procedemento de importación ou recuperación dentro dun ambiente protexido. Conserve o ficheiro orixinal e manteña o material decodificado fóra dos rexistros, do historial da consola e dos tíckets. Se o valor está cifrado ou ligado a un almacén protexido, o método de desbloqueo documentado e a autorización necesaria veñen do propietario, porque a decodificación non achega nin unha clave nin o contexto de acceso doutro usuario. Cando o campo contén un verificador, siga a ruta de substitución documentada en lugar de probar decodificadores.
Cando o propietario non pode recuperar ou reemitir o valor con seguridade, a resposta é unha credencial nova e configuracións de par actualizadas. Iso é un proxecto cunha transición, non un comando.
Substituír un segredo compartido é un cambio coordinado
Sobrescribir un segredo compartido de produción só nun lado rompe todos os clientes aprobados que aínda manteñen o valor anterior. Planifique a transición, decida se se debe revogar algún acceso e manteña dispoñible unha vía de recuperación antes de cambiar calquera dos extremos. Anuncie a xanela ás persoas que o notarán.
Se o valor orixinal quedou exposto, a rotación é a resposta correcta e decodificalo non engade nada. Un segredo exposto está comprometido tanto se alguén recuperou os bytes como se non.
Anote onde vive o novo valor e a quen pertence. O próximo incidente pedirá iso, non un decodificador.