Det eksisterer ingen «dekryptering» for en kodet VPN-hemmelighet

Formuleringen å dekryptere den kodede nøkkelen forutsetter én enkelt operasjon som ikke eksisterer. En lagret VPN-hemmelighet kan være base-kodede bytes, en kryptert blob bundet til et nøkkellager, eller en enveis verifikator som ikke kan reverseres i det hele tatt, og hver av dem krever en annen håndtering. Base-koding legger ikke til konfidensialitet av design, så dekoding kan gjenopprette en anvendelig hemmelighet i stedet for å avdekke en beskyttet. Å ta utgangspunkt i feltet og i produktet som skrev det, er den eneste pålitelige identifiseringen.

Hold verdien borte fra både nettkodere og offentlige innlegg på forum, fordi en kodet hemmelighet fortsatt er en hemmelighet.

Koding, kryptering og en verifikator er tre forskjellige ting

RFC 4648 definerer base-kodinger som representasjoner av data i begrensede miljøer, og sikkerhetsdelen sier rett ut at de ikke gir noen beregningsmessig konfidensialitet. Det betyr at et Base64-felt kan gjøres om til bytes av hvem som helst, og det er en gjenopprettingsrisiko, ikke en kryptografisk barriere. Kryptering er noe annet: uten nøkkelmaterialet forblir bytene ugjennomsiktige. En verifikator er atter noe annet, fordi den er konstruert for ikke å kunne reverseres. Å lese det dokumenterte feltnavnet gir vanligvis svaret på hvilken av de tre du har.

Å omtale en streng som Base64 fastslår ikke innholdet. Den kan dekodes til en nøkkel, til en serialisert struktur eller til tilfeldig utfylling, og tekstens utseende sier ingenting om hvilken.

Fastslå feltet før du berører det

Skriv ned produktet som eksporterer og versjonen, profilformatet og det dokumenterte feltnavnet. Deretter skiller du typene hemmelighet som er involvert: en gruppevis forhåndsdelt nøkkel er ikke et individuelt kontopassord, en passfrase for en privatnøkkel eller et autentiseringstoken. De har forskjellige eiere og forskjellige erstatningsrutiner, og å blande dem endrer feil påloggingsinformasjon. En profil som fortsatt kobler til er heller ikke tillatelse til å hente ut påloggingsinformasjon som tilhører noen andre.

Den nyttige informasjonen til støtteapparatet er produktet, feltet, feilen og det godkjente målet. Selve hemmeligheten er ikke en del av den listen.

Gjenoppretting er en autorisert prosedyre, ikke en dekoder

Hvis produktet dokumenterer en reversibel eksport for autorisert gjenoppretting, bruker du dets egen import- eller gjenopprettingsprosedyre i et beskyttet miljø. Bevar originalfilen, og hold dekodet materiale unna logger, skallhistorikk og saksbilletter. Hvis verdien er kryptert eller bundet til et beskyttet lager, kommer den dokumenterte opplåsingsmetoden og den påkrevde autorisasjonen fra eieren, fordi dekoding verken gir en nøkkel eller en annen brukers tilgangskontekst. Når feltet inneholder en verifikator, følger du den dokumenterte erstatningsveien i stedet for å prøve dekodere.

Når eieren ikke kan gjenopprette eller trygt utstede verdien på nytt, er svaret ny påloggingsinformasjon og oppdaterte peer-konfigurasjoner. Det er et prosjekt med en overgang, ikke en kommando.

Å erstatte en delt hemmelighet er en koordinert endring

Å overskrive en delt produksjonshemmelighet på bare én side ødelegger hver godkjente klient som fortsatt sitter på den forrige verdien. Planlegg overgangen, avgjør om noen tilgang må tilbakekalles, og hold en gjenopprettingsvei tilgjengelig før du endrer noen av endepunktene. Kunngjør tidsvinduet til dem som kommer til å merke det.

Hvis den opprinnelige verdien ble eksponert, er rotasjon det riktige svaret, og å dekode den tilfører ingenting. En eksponert hemmelighet er kompromittert enten noen gjenopprettet bytene eller ikke.

Skriv ned hvor den nye verdien befinner seg og hvem som eier den. Den neste hendelsen vil etterspørre det, ikke en dekoder.