Walang ‘decrypt’ para sa isang naka-encode na VPN secret
Walang naidaragdag na pagiging lihim ang base encoding, at ang verifier ay hindi mababaligtad nang todo. Tukuyin ang field bago kumuha ng decoder o kapalit.
Ang pariralang i-decrypt ang naka-encode na key ay nagpapalagay ng isang operasyon na wala naman. Ang naka-store na VPN secret ay maaaring base-encoded na bytes, isang naka-encrypt na blob na nakatali sa isang keystore, o isang one-way na verifier na hindi mababaligtad nang todo, at bawat isa ay nangangailangan ng ibang tugon. Ang base encoding ay walang naidaragdag na pagiging lihim ayon sa disenyo, kaya ang pag-decode nito ay maaaring makabawi ng magagamit na secret sa halip na magbunyag ng protektado. Ang pagsisimula sa field at sa produktong sumulat nito ang tanging maaasahang pagkakakilanlan.
Ilayo ang halaga sa mga web decoder at sa mga pampublikong post sa forum, dahil ang naka-encode na secret ay secret pa rin.
Ang encoding, encryption at verifier ay tatlong magkaibang bagay
Tinukoy ng RFC 4648 ang base encodings bilang mga representasyon ng data sa limitadong kapaligiran, at malinaw na sinasabi ng seksyon nito sa seguridad na wala silang ibinibigay na computational na pagiging lihim. Ibig sabihin, sinuman ay maaaring magbalik ng Base64 field sa bytes, na isang panganib sa pagbawi at hindi isang cryptographic na hadlang. Iba ang encryption: kung walang key material, nananatiling malabo ang bytes. Iba rin ang verifier, dahil dinisenyo ito para hindi mabaligtad. Ang pagbasa ng dokumentadong pangalan ng field ay karaniwang nagsasabi kung alin sa tatlo ang mayroon ka.
Ang pagtawag sa isang string na Base64 ay hindi nagpapatunay kung ano ang nilalaman nito. Maaari itong mag-decode sa isang key, sa isang naka-serialise na istruktura, o sa random na padding, at wala pang sinasabi ang anyo ng teksto tungkol dito.
Tukuyin ang field bago ito hawakan
Itala ang produktong nag-export at ang bersyon, ang format ng profile at ang dokumentadong pangalan ng field. Pagkatapos, ihiwalay ang mga uri ng secret na kasangkot: ang group pre-shared key ay hindi password ng indibidwal na account, hindi passphrase ng pribadong key, at hindi authentication token. May magkaibang may-ari at magkaibang pamamaraan ng pagpapalit ang mga ito, at ang paghaluin ang mga ito ay nagbabago ng maling kredensyal. Ang profile na konektado pa rin ay hindi rin pahintulot na kunin ang kredensyal na pag-aari ng ibang tao.
Ang kapaki-pakinabang na impormasyong ibibigay sa suporta ay ang produkto, ang field, ang error at ang awtorisadong layunin. Ang secret mismo ay hindi bahagi ng listahang iyon.
Ang pagbawi ay isang awtorisadong pamamaraan, hindi decoder
Kung dokumentado ng produkto ang isang nababaligtad na pag-export para sa awtorisadong pagbawi, gamitin ang sarili nitong pamamaraan sa pag-import o pagbawi sa loob ng protektadong kapaligiran. Pangalagaan ang orihinal na file, at ilayo ang na-decode na materyal sa mga log, kasaysayan ng shell at mga tiket. Kung naka-encrypt ang halaga o nakatali sa isang protektadong imbakan, ang dokumentadong paraan ng pag-unlock at ang kinakailangang awtorisasyon ay nagmumula sa may-ari, dahil walang ibinibigay ang pag-decode na key o konteksto ng access ng ibang user. Kapag may verifier ang field, sundan ang dokumentadong landas ng pagpapalit sa halip na subukan ang mga decoder.
Kapag hindi mabawi o ligtas na maipapalit ng may-ari ang halaga, ang sagot ay bagong kredensyal at na-update na mga configuration ng peer. Iyon ay isang proyekto na may paglilipat, hindi isang utos.
Ang pagpapalit ng pinagsamang secret ay isang koordinadong pagbabago
Ang pag-overwrite ng production shared secret sa isang panig lamang ay sumisira sa bawat aprubadong kliyente na may hawak pa ng dating halaga. Planuhin ang paglilipat, magpasya kung may access na dapat bawiin, at panatilihing magagamit ang landas ng pagbawi bago baguhin ang alinmang dulo. Ipahayag ang window sa mga taong makakapansin.
Kung nailantad ang orihinal na halaga, ang rotation ang tamang tugon at walang naidaragdag ang pag-decode nito. Ang nailantad na secret ay nakompromiso kahit na may nakabawi ng bytes o wala.
Itala kung saan naroroon ang bagong halaga at kanino ito pag-aari. Ang susunod na insidente ay hihingi niyon, hindi ng decoder.