Daar is geen ‘ontsleutel’ vir ’n geënkodeerde VPN-geheim nie

Die frase ontsleutel die geënkodeerde sleutel veronderstel ’n enkele bewerking wat nie bestaan nie. ’n Gestoor VPN-geheim kan basis-geënkodeerde grepe wees, ’n geïnkripteerde blob wat aan ’n keystore gekoppel is, of ’n eenrigting-verifieerder wat glad nie omgekeer kan word nie, en elkeen vra ’n ander reaksie. Basis-enkodering voeg by ontwerp geen vertroulikheid by nie, so die dekodering daarvan kan ’n bruikbare geheim terugkry eerder as om ’n beskermde een te openbaar. Om by die veld en die produk wat dit geskryf het te begin, is die enigste betroubare identifisering.

Hou die waarde uit web-dekodeerders sowel as openbare forumplasings, want ’n geënkodeerde geheim is steeds ’n geheim.

Enkodering, inkripsie en ’n verifieerder is drie dinge

RFC 4648 omskryf basis-enkoderings as voorstellings vir data in beperkte omgewings, en sy sekuriteitsafdeling stel dit duidelik dat hulle geen berekeningsvertroulikheid bied nie. Dit beteken dat ’n Base64-veld deur enigiemand terug in grepe verander kan word, wat ’n herwinningsrisiko eerder as ’n kriptografiese versperring is. Inkripsie is anders: sonder die sleutelmateriaal bly die grepe ondeursigtig. ’n Verifieerder is weer anders, want dit is ontwerp om nie omgekeer te word nie. Om die gedokumenteerde veldnaam te lees, sê gewoonlik watter van die drie jy het.

Om ’n string Base64 te noem, bepaal nie wat dit bevat nie. Dit kan na ’n sleutel dekodeer, na ’n geserialiseerde struktuur of na gerandomiseerde vulling, en die voorkoms van die teks sê niks oor watter een nie.

Identifiseer die veld voordat jy dit aanraak

Teken die uitvoerende produk en weergawe aan, die profielformaat en die gedokumenteerde veldnaam. Skei dan die soorte geheim wat betrokke is: ’n groep-vooraf-gedeelde sleutel is nie ’n individuele rekeningwagwoord, ’n privaatsleutel-wagfrase of ’n verifikasietoken nie. Dié het verskillende eienaars en verskillende vervangingsprosedures, en om hulle te verwar verander die verkeerde geloofsbrief. ’n Profiel wat steeds verbind, is ook nie toestemming om ’n geloofsbrief te onttrek wat aan iemand anders behoort nie.

Die nuttige inligting om aan ondersteuning te gee is die produk, die veld, die fout en die gemagtigde doel. Die geheim self is nie deel van daardie lys nie.

Herwinning is ’n gemagtigde prosedure, nie ’n dekodeerder nie

As die produk ’n omkeerbare uitvoer vir gemagtigde herwinning dokumenteer, gebruik sy eie invoer- of herwinningsprosedure binne ’n beskermde omgewing. Bewaar die oorspronklike lêer, en hou gedekodeerde materiaal uit logs, shell-geskiedenis en tickets. As die waarde geïnkripteer is of aan ’n beskermde stoor gebind is, kom die gedokumenteerde ontsluitingsmetode en die vereiste magtiging van die eienaar, want dekodering verskaf nóg ’n sleutel nóg ’n ander gebruiker se toegangskonteks. Wanneer die veld ’n verifieerder hou, volg die gedokumenteerde vervangingsroete eerder as om dekodeerders te probeer.

Wanneer die eienaar die waarde nie kan herwin of veilig heruitreik nie, is die antwoord ’n nuwe geloofsbrief en bygewerkte eweknie-konfigurasies. Dit is ’n projek met ’n oorskakeling, nie ’n opdrag nie.

Om ’n gedeelde geheim te vervang is ’n gekoördineerde verandering

Om ’n produksie-gedeelde geheim alleen aan een kant te oorskryf, breek elke goedgekeurde kliënt wat nog die vorige waarde hou. Beplan die oorskakeling, besluit of enige toegang ingetrek moet word, en hou ’n herwinningspad beskikbaar voordat jy een van die eindpunte verander. Kondig die venster aan die mense wat dit sal raaksien.

As die oorspronklike waarde blootgelê is, is rotasie die korrekte reaksie en voeg dekodering daarvan niks by nie. ’n Blootgelêde geheim is gekompromitteer, of iemand die grepe herwin het al dan nie.

Teken aan waar die nuwe waarde leef en wie dit besit. Die volgende voorval sal daarvoor vra, nie vir ’n dekodeerder nie.