Det finnes ingen «dekryptering» av en kodet VPN-hemmelighet

Uttrykket dekrypter den kodede nøkkelen forutsetter én enkelt operasjon som ikke finnes. En lagret VPN-hemmelighet kan være base-kodede bytes, en kryptert blob knyttet til et nøkkellager, eller en enveis verifikator som ikke kan reverseres i det hele tatt, og hver av dem krever en annen respons. Base-koding gir ingen konfidensialitet av design, så dekoding kan gjenopprette en brukbar hemmelighet i stedet for å avsløre en beskyttet. Å starte ved feltet og ved produktet som skrev det, er den eneste pålitelige identifikasjonen.

Hold verdien unna både nettkodere og offentlige foruminlegg, fordi en kodet hemmelighet fortsatt er en hemmelighet.

Koding, kryptering og en verifikator er tre ting

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

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

Identifiser feltet før du rører det

Noter produktet som eksporterer og versjonen, profilformatet og det dokumenterte feltnavnet. Skill deretter ut hvilke typer hemmelighet som er involvert: en gruppe-forhåndsdelt nøkkel er ikke et individuelt kontopassord, en passfrase for en privatnøkkel eller et autentiseringstoken. De har ulike eiere og ulike erstatningsprosedyrer, og å blande dem endrer feil legitimasjon. En profil som fortsatt kobler til er heller ikke tillatelse til å hente ut legitimasjon som tilhører noen andre.

Den nyttige informasjonen å gi til støtte er produktet, feltet, feilen og det autoriserte 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, bruk produktets egen import- eller gjenopprettingsprosedyre i et beskyttet miljø. Ta vare på originalfilen, og hold dekodet materiale unna logger, skallhistorikk og saker. Hvis verdien er kryptert eller bundet til et beskyttet lager, kommer den dokumenterte opplåsingsmetoden og den nødvendige autorisasjonen fra eieren, fordi dekoding verken gir en nøkkel eller en annen brukers tilgangskontekst. Når feltet inneholder en verifikator, følg den dokumenterte erstatningsveien i stedet for å prøve dekodere.

Når eieren ikke kan gjenopprette eller trygt utstede verdien på nytt, er svaret ny legitimasjon 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 bryter hver godkjente klient som fortsatt har 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 vinduet til dem som vil merke det.

Hvis den opprinnelige verdien ble avslørt, er rotasjon det riktige svaret, og å dekode den tilfører ingenting. En avslørt hemmelighet er kompromittert uansett om noen gjenopprettet bytene.

Noter hvor den nye verdien ligger og hvem som eier den. Den neste hendelsen vil spørre etter det, ikke etter en dekoder.