Non esiste una «decifratura» per un segreto VPN codificato

La frase decifrare la chiave codificata presuppone un’unica operazione che non esiste. Un segreto VPN memorizzato può essere byte codificati in base, un blob cifrato legato a un keystore o un verificatore a senso unico che non può essere invertito affatto, e ciascuno richiede una risposta diversa. La codifica base non aggiunge riservatezza per concezione, quindi decodificarla può recuperare un segreto utilizzabile invece di rivelarne uno protetto. Partire dal campo e dal prodotto che lo ha scritto è l’unica identificazione affidabile.

Tenete il valore lontano dai decodificatori web e dai post pubblici sui forum, perché un segreto codificato resta un segreto.

Codifica, cifratura e verificatore sono tre cose

La RFC 4648 definisce le codifiche base come rappresentazioni di dati in ambienti vincolati, e la sua sezione sicurezza afferma chiaramente che non forniscono alcuna riservatezza computazionale. Ciò significa che chiunque può riconvertire un campo Base64 in byte, il che è un rischio di recupero e non una barriera crittografica. La cifratura è diversa: senza il materiale di chiave, i byte restano opachi. Un verificatore è ancora diverso, perché è stato progettato per non essere invertito. Leggere il nome documentato del campo di solito indica quale dei tre avete.

Chiamare Base64 una stringa non stabilisce cosa contiene. Può decodificarsi in una chiave, in una struttura serializzata o in un riempimento casuale, e l’aspetto del testo non dice nulla su quale.

Identificate il campo prima di toccarlo

Annotate il prodotto che esporta e la versione, il formato del profilo e il nome documentato del campo. Poi separate i tipi di segreto coinvolti: una chiave pre-condivisa di gruppo non è una password di account individuale, né una passphrase di chiave privata, né un token di autenticazione. Hanno proprietari diversi e procedure di sostituzione diverse, e confonderli modifica la credenziale sbagliata. Un profilo che si connette ancora non è nemmeno il permesso di estrarre una credenziale che appartiene a qualcun altro.

Le informazioni utili da dare al supporto sono il prodotto, il campo, l’errore e l’obiettivo autorizzato. Il segreto stesso non fa parte di quell’elenco.

Il recupero è una procedura autorizzata, non un decodificatore

Se il prodotto documenta un’esportazione reversibile per un recupero autorizzato, usate la sua procedura di importazione o di recupero in un ambiente protetto. Conservate il file originale e tenete il materiale decodificato fuori da log, cronologia della shell e ticket. Se il valore è cifrato o legato a un archivio protetto, il metodo di sblocco documentato e l’autorizzazione richiesta provengono dal proprietario, perché la decodifica non fornisce né una chiave né il contesto di accesso di un altro utente. Quando il campo contiene un verificatore, seguite il percorso di sostituzione documentato invece di provare decodificatori.

Quando il proprietario non può recuperare o riemettere il valore in sicurezza, la risposta è una nuova credenziale e configurazioni dei peer aggiornate. È un progetto con un passaggio, non un comando.

Sostituire un segreto condiviso è un cambiamento coordinato

Sovrascrivere un segreto condiviso di produzione solo da un lato rompe ogni client approvato che detiene ancora il valore precedente. Pianificate il passaggio, decidete se revocare qualche accesso e mantenete disponibile un percorso di recupero prima di cambiare una delle estremità. Annunciate la finestra alle persone che se ne accorgeranno.

Se il valore originale è stato esposto, la rotazione è la risposta corretta e decodificarlo non aggiunge nulla. Un segreto esposto è compromesso, che qualcuno abbia recuperato i byte o no.

Annotate dove vive il nuovo valore e a chi appartiene. Il prossimo incidente chiederà quello, non un decodificatore.