Nie ma „odszyfrowania“ zakodowanego sekretu VPN

Sformułowanie odszyfrować zakodowany klucz zakłada jedną operację, która nie istnieje. Zapisany sekret VPN może być bajtami zakodowanymi w base, zaszyfrowanym blobem powiązanym z magazynem kluczy albo jednokierunkowym weryfikatorem, którego nie da się w ogóle odwrócić, i każdy z nich wymaga innej reakcji. Kodowanie base z założenia nie dodaje poufności, więc jego zdekodowanie może odzyskać użyteczny sekret, a nie ujawnić chroniony. Zaczęcie od pola i od produktu, który je zapisał, to jedyna wiarygodna identyfikacja.

Trzymaj wartość z dala zarówno od dekoderów internetowych, jak i od publicznych postów na forach, bo zakodowany sekret nadal jest sekretem.

Kodowanie, szyfrowanie i weryfikator to trzy różne rzeczy

RFC 4648 definiuje kodowania base jako reprezentacje danych w ograniczonych środowiskach, a jego sekcja bezpieczeństwa wprost stwierdza, że nie zapewniają one żadnej poufności obliczeniowej. To znaczy, że pole Base64 może zamienić z powrotem na bajty każdy, co jest ryzykiem odzyskania, a nie barierą kryptograficzną. Szyfrowanie jest inne: bez materiału klucza bajty pozostają nieprzejrzyste. Weryfikator jest jeszcze inny, bo zaprojektowano go tak, aby nie dało się go odwrócić. Odczytanie udokumentowanej nazwy pola zwykle mówi, który z trzech przypadków masz.

Nazwanie ciągu Base64 nie ustala, co zawiera. Może dekodować się do klucza, do struktury zserializowanej lub do losowego wypełnienia, a wygląd tekstu nie mówi nic o tym, który to.

Zidentyfikuj pole, zanim go dotkniesz

Zapisz produkt eksportujący i wersję, format profilu oraz udokumentowaną nazwę pola. Następnie rozdziel rodzaje sekretu: grupowy klucz wstępnie współdzielony to nie hasło pojedynczego konta, nie hasło klucza prywatnego ani token uwierzytelniający. Mają różnych właścicieli i różne procedury wymiany, a ich pomylenie zmienia niewłaściwe dane logowania. Profil, który nadal się łączy, też nie jest pozwoleniem na wyciągnięcie danych logowania należących do kogoś innego.

Przydatna informacja dla wsparcia to produkt, pole, błąd i autoryzowany cel. Sam sekret nie jest częścią tej listy.

Odzyskiwanie to autoryzowana procedura, a nie dekoder

Jeśli produkt dokumentuje odwracalny eksport do autoryzowanego odzyskania, użyj jego własnej procedury importu lub odzyskiwania w chronionym środowisku. Zachowaj oryginalny plik i trzymaj zdekodowany materiał poza logami, historią powłoki i zgłoszeniami. Jeśli wartość jest zaszyfrowana lub powiązana z chronionym magazynem, udokumentowana metoda odblokowania i wymagana autoryzacja pochodzą od właściciela, bo dekodowanie nie daje ani klucza, ani kontekstu dostępu innego użytkownika. Gdy pole zawiera weryfikator, podążaj udokumentowaną ścieżką wymiany zamiast próbować dekoderów.

Gdy właściciel nie może odzyskać lub bezpiecznie ponownie wydać wartości, odpowiedzią są nowe dane logowania i zaktualizowane konfiguracje partnerów. To projekt z przejściem, a nie polecenie.

Wymiana współdzielonego sekretu to skoordynowana zmiana

Nadpisanie produkcyjnego współdzielonego sekretu tylko po jednej stronie psuje każdego zatwierdzonego klienta, który nadal ma poprzednią wartość. Zaplanuj przejście, zdecyduj, czy trzeba odebrać jakiś dostęp, i utrzymuj dostępną ścieżkę odzyskiwania, zanim zmienisz którykolwiek koniec. Ogłoś okno czasowe ludziom, którzy to zauważą.

Jeśli pierwotna wartość została ujawniona, rotacja jest właściwą odpowiedzią, a jej dekodowanie niczego nie dodaje. Ujawniony sekret jest skompromitowany niezależnie od tego, czy ktoś odzyskał bajty.

Zapisz, gdzie mieszka nowa wartość i do kogo należy. Następny incydent zapyta o to, a nie o dekoder.