Det finst inga «dekryptering» av eit koda VPN-løyndom

Uttrykket dekrypter den koda nøkkelen føreset éin einaste operasjon som ikkje finst. Ein lagra VPN-løyndom kan vere base-koda bytes, ein kryptert blob knytt til eit nøkkellager, eller ein einvegs verifikator som ikkje kan snuast i det heile, og kvar av dei krev eit anna svar. Base-koding gir ingen konfidensialitet av design, så dekoding kan vinne attende ein brukbar løyndom i staden for å avdekkje ein verna. Å byrje ved feltet og ved produktet som skreiv det, er den einaste pålitelege identifikasjonen.

Hald verdien unna både nettkodarar og offentlege foruminnlegg, fordi ein koda løyndom framleis er ein løyndom.

Koding, kryptering og ein verifikator er tre ting

RFC 4648 definerer base-kodingar som representasjonar av data i avgrensa miljø, og tryggleiksavsnittet seier klart at dei ikkje gir nokon berekningsmessig konfidensialitet. Det tyder at eit Base64-felt kan gjerast om til bytes av kven som helst, noko som er ein gjenopprettingsrisiko og ikkje ein kryptografisk barriere. Kryptering er annleis: utan nøkkelmaterialet blir byta ugjennomsiktige. Ein verifikator er igjen annleis, fordi han er laga for ikkje å kunne snuast. Å lese det dokumenterte feltnamnet fortel vanlegvis kva av dei tre du har.

Å kalle ein streng Base64 slår ikkje fast kva han inneheld. Han kan dekodast til ein nøkkel, til ein serialisert struktur eller til tilfeldig utfylling, og utsjånaden til teksten seier ingenting om kva.

Identifiser feltet før du rører det

Noter produktet som eksporterer og versjonen, profilformatet og det dokumenterte feltnamnet. Skil så ut kva slag løyndom som er involvert: ein gruppe-førehandsdel nøkkel er ikkje eit individuelt kontopassord, ei passfrase for ein privatnøkkel eller eit autentiseringstoken. Dei har ulike eigarar og ulike erstatningsprosedyrar, og å blande dei endrar feil legitimasjon. Ein profil som framleis koplar til er heller ikkje løyve til å hente ut legitimasjon som høyrer til nokon andre.

Den nyttige informasjonen å gi til støtte er produktet, feltet, feilen og det autoriserte målet. Sjølve løyndommen er ikkje del av den lista.

Gjenoppretting er ein autorisert prosedyre, ikkje ein dekodar

Viss produktet dokumenterer ein reversibel eksport for autorisert gjenoppretting, bruk produktet sin eigen import- eller gjenopprettingsprosedyre i eit verna miljø. Ta vare på originalfila, og hald dekoda materiale unna loggar, skalehistorikk og saker. Viss verdien er kryptert eller bunden til eit verna lager, kjem den dokumenterte opplåsingsmetoden og den nødvendige autorisasjonen frå eigaren, fordi dekoding korkje gir ein nøkkel eller tilgangskonteksten til ein annan brukar. Når feltet inneheld ein verifikator, følg den dokumenterte erstatningsvegen i staden for å prøve dekodarar.

Når eigaren ikkje kan gjenopprette eller trygt gi ut verdien på nytt, er svaret ny legitimasjon og oppdaterte peer-konfigurasjonar. Det er eit prosjekt med ein overgang, ikkje ein kommando.

Å erstatte ein delt løyndom er ei koordinert endring

Å skrive over ein delt produksjonsløyndom berre på éi side bryt kvar godkjend klient som framleis har den førre verdien. Planlegg overgangen, avgjer om nokon tilgang må trekkjast attende, og hald ein gjenopprettingsveg tilgjengeleg før du endrar nokon av endepunkta. Kunngjer vindauget til dei som vil merke det.

Viss den opphavlege verdien vart avdekt, er rotasjon det rette svaret, og å dekode han tilfører ingenting. Ein avdekt løyndom er kompromittert anten nokon gjenoppretta byta eller ikkje.

Noter kvar den nye verdien held til og kven som eig han. Den neste hendinga vil spørje etter det, ikkje etter ein dekodar.