Der findes ingen ‘dekryptering’ af en kodet VPN-hemmelighed

Sætningen dekryptér den kodede nøgle forudsætter én enkelt handling, som ikke findes. En gemt VPN-hemmelighed kan være basis-kodede bytes, en krypteret blob bundet til et keystore eller en envejs-verifier, som slet ikke kan vendes om, og hver af dem kræver et forskelligt svar. Basis-kodning tilføjer per design ingen fortrolighed, så afkodning kan genskabe en brugbar hemmelighed i stedet for at afsløre en beskyttet. At starte ved feltet og ved det produkt, der skrev det, er den eneste pålidelige identifikation.

Hold værdien væk fra web-dekodere og offentlige forumindlæg, for en kodet hemmelighed er stadig en hemmelighed.

Kodning, kryptering og en verifier er tre ting

RFC 4648 definerer basis-kodninger som repræsentationer af data i begrænsede miljøer, og dens sikkerhedsafsnit siger klart, at de ikke giver nogen beregningsmæssig fortrolighed. Det betyder, at et Base64-felt kan vendes tilbage til bytes af enhver, hvilket er en gendannelsesrisiko snarere end en kryptografisk barriere. Kryptering er anderledes: uden nøglematerialet forbliver bytene uigennemsigtige. En verifier er igen anderledes, fordi den blev designet til ikke at kunne vendes om. At læse det dokumenterede feltnavn fortæller normalt, hvilken af de tre du har.

At kalde en streng Base64 fastslår ikke, hvad den indeholder. Den kan afkodes til en nøgle, til en serialiseret struktur eller til tilfældig udfyldning, og tekstens udseende siger intet om hvilken.

Identificér feltet, før du rører det

Notér det eksporterende produkt og versionen, profilformatet og det dokumenterede feltnavn. Adskil derefter de typer hemmelighed, der er involveret: en gruppe-forud-delt nøgle er ikke en individuel kontoadgangskode, en adgangssætning til en privat nøgle eller et godkendelsestoken. De har forskellige ejere og forskellige udskiftningsprocedurer, og at forveksle dem ændrer den forkerte legitimationsoplysning. En profil, der stadig forbinder, er heller ikke tilladelse til at udtrække en legitimationsoplysning, som tilhører en anden.

De nyttige oplysninger til support er produktet, feltet, fejlen og det autoriserede mål. Selve hemmeligheden er ikke en del af den liste.

Gendannelse er en autoriseret procedure, ikke en dekoder

Hvis produktet dokumenterer en reversibel eksport til autoriseret gendannelse, brug dets egen import- eller gendannelsesprocedure i et beskyttet miljø. Bevar den originale fil, og hold afkodet materiale ude af logfiler, shellhistorik og tickets. Hvis værdien er krypteret eller bundet til et beskyttet lager, kommer den dokumenterede oplåsningsmetode og den nødvendige autorisation fra ejeren, fordi afkodning hverken giver en nøgle eller en anden brugers adgangskontekst. Når feltet indeholder en verifier, følg den dokumenterede udskiftningsvej i stedet for at prøve dekodere.

Når ejeren ikke kan genskabe eller sikkert genudstede værdien, er svaret en ny legitimationsoplysning og opdaterede peer-konfigurationer. Det er et projekt med et skift, ikke en kommando.

Udskiftning af en delt hemmelighed er en koordineret ændring

At overskrive en delt produktionshemmelighed på kun én side ødelægger hver godkendt klient, der stadig har den forrige værdi. Planlæg skiftet, beslut om nogen adgang skal tilbagekaldes, og hold en gendannelsesvej tilgængelig, før du ændrer nogen af endepunkterne. Annoncér vinduet til dem, der vil bemærke det.

Hvis den oprindelige værdi blev afsløret, er rotation det rigtige svar, og at afkode den tilføjer intet. En afsløret hemmelighed er kompromitteret, uanset om nogen har genskabt bytene.

Notér, hvor den nye værdi bor, og hvem der ejer den. Den næste hændelse vil spørge om det, ikke om en dekoder.