Det finns ingen ”dekryptering” av en kodad VPN-hemlighet

Uttrycket dekryptera den kodade nyckeln förutsätter en enda operation som inte finns. En lagrad VPN-hemlighet kan vara baskodade byte, en krypterad blob knuten till ett nyckellager, eller en envägsverifierare som inte alls kan vändas, och var och en kräver ett annat svar. Baskodning tillför ingen sekretess enligt sin konstruktion, så avkodning kan återvinna en användbar hemlighet i stället för att avslöja en skyddad. Att börja vid fältet och vid produkten som skrev det är den enda tillförlitliga identifieringen.

Håll värdet borta från både webbavkodare och offentliga foruminlägg, eftersom en kodad hemlighet fortfarande är en hemlighet.

Kodning, kryptering och en verifierare är tre olika saker

RFC 4648 definierar baskodningar som representationer av data i begränsade miljöer, och dess säkerhetsavsnitt säger klart att de inte ger någon beräkningsmässig sekretess. Det betyder att ett Base64-fält kan göras om till byte av vem som helst, vilket är en återvinningsrisk och inte en kryptografisk barriär. Kryptering är annorlunda: utan nyckelmaterialet förblir byten ogenomträngliga. En verifierare är åter annorlunda, eftersom den är konstruerad för att inte kunna vändas. Att läsa det dokumenterade fältnamnet brukar säga vilken av de tre du har.

Att kalla en sträng Base64 fastställer inte vad den innehåller. Den kan avkodas till en nyckel, till en serialiserad struktur eller till slumpmässig utfyllnad, och textens utseende säger ingenting om vilken.

Identifiera fältet innan du rör det

Notera den exporterande produkten och versionen, profilformatet och det dokumenterade fältnamnet. Dela sedan upp de typer av hemlighet som är inblandade: en gruppvis fördelad nyckel är inte ett individuellt kontolösenord, en lösenfras för en privat nyckel eller en autentiseringstoken. De har olika ägare och olika ersättningsrutiner, och att blanda ihop dem ändrar fel inloggningsuppgifter. En profil som fortfarande ansluter är inte heller tillstånd att extrahera inloggningsuppgifter som tillhör någon annan.

Den användbara informationen att ge supporten är produkten, fältet, felet och det godkända målet. Själva hemligheten ingår inte i den listan.

Återställning är en auktoriserad procedur, inte en avkodare

Om produkten dokumenterar en reversibel export för auktoriserad återställning, använd dess egen import- eller återställningsprocedur i en skyddad miljö. Bevara originalfilen och håll avkodat material borta från loggar, skallhistorik och ärenden. Om värdet är krypterat eller knutet till ett skyddat lager kommer den dokumenterade upplåsningsmetoden och det nödvändiga tillståndet från ägaren, eftersom avkodning varken ger en nyckel eller en annan användares åtkomstkontext. När fältet innehåller en verifierare följer du den dokumenterade ersättningsvägen i stället för att prova avkodare.

När ägaren inte kan återställa eller säkert utfärda värdet på nytt är svaret nya inloggningsuppgifter och uppdaterade peer-konfigurationer. Det är ett projekt med en övergång, inte ett kommando.

Att ersätta en delad hemlighet är en samordnad ändring

Att skriva över en delad produktionshemlighet bara på ena sidan bryter varje godkänd klient som fortfarande har det föregående värdet. Planera övergången, avgör om någon åtkomst måste återkallas och håll en återställningsväg tillgänglig innan du ändrar någon av ändpunkterna. Meddela tidsfönstret till dem som kommer att märka det.

Om det ursprungliga värdet exponerades är rotation rätt svar, och att avkoda det tillför ingenting. En exponerad hemlighet är komprometterad oavsett om någon återställde byten.

Notera var det nya värdet finns och vem som äger det. Nästa incident kommer att fråga efter det, inte efter en avkodare.