Для закодованого секрету VPN немає «розшифрування»

Фраза розшифрувати закодований ключ припускає одну операцію, якої не існує. Збережений секрет VPN може бути байтами в базовому кодуванні, зашифрованим блоком, прив'язаним до сховища ключів, або однобічним верифікатором, який взагалі не можна обернути, і кожен із них потребує іншої реакції. Базове кодування за своєю природою не додає конфіденційності, тому його декодування може повернути придатний до використання секрет, а не розкрити захищений. Починати з поля й продукту, який його записав, — єдина надійна ідентифікація.

Тримайте значення далі і від веб-декодерів, і від публічних дописів на форумах, бо закодований секрет залишається секретом.

Кодування, шифрування й верифікатор — три різні речі

RFC 4648 визначає базові кодування як подання даних в обмежених середовищах, і його розділ про безпеку прямо заявляє, що вони не дають жодної обчислювальної конфіденційності. Це означає, що поле Base64 може перетворити назад у байти будь-хто, і це ризик відновлення, а не криптографічний бар'єр. Шифрування інше: без ключового матеріалу байти залишаються непрозорими. Верифікатор знову інший, бо він створений так, щоб його не можна було обернути. Читання задокументованої назви поля зазвичай підказує, який із трьох випадків у вас.

Назвати рядок Base64 не означає встановити, що в ньому лежить. Він може декодуватися в ключ, у серіалізовану структуру або у випадкове заповнення, і вигляд тексту нічого про це не говорить.

Визначте поле, перш ніж до нього торкатися

Запишіть продукт-експортер і його версію, формат профілю та задокументовану назву поля. Далі розділіть види секрету: груповий попередньо спільний ключ — це не пароль окремого облікового запису, не парольна фраза закритого ключа і не токен автентифікації. У них різні власники й різні процедури заміни, і їхнє плутання змінює не ті облікові дані. Профіль, який ще підключається, теж не дозвіл видобувати облікові дані, що належать комусь іншому.

Корисна інформація для підтримки — це продукт, поле, помилка й дозволена мета. Сам секрет до цього списку не входить.

Відновлення — це дозволена процедура, а не декодер

Якщо продукт документує оборотний експорт для дозволеного відновлення, використовуйте його власну процедуру імпорту або відновлення в захищеному середовищі. Збережіть початковий файл і тримайте декодований матеріал поза журналами, історією оболонки та заявками. Якщо значення зашифроване або прив'язане до захищеного сховища, задокументований спосіб розблокування й потрібний дозвіл походять від власника, бо декодування не дає ні ключа, ні контексту доступу іншого користувача. Коли поле містить верифікатор, дотримуйтеся задокументованого шляху заміни, а не пробуйте декодери.

Коли власник не може відновити або безпечно перевипустити значення, відповідь — нові облікові дані й оновлені конфігурації партнерів. Це проєкт із переходом, а не команда.

Заміна спільного секрету — це узгоджена зміна

Перезапис виробничого спільного секрету лише з одного боку ламає кожного схваленого клієнта, який ще має попереднє значення. Сплануйте перехід, вирішіть, чи треба відкликати якийсь доступ, і тримайте шлях відновлення доступним, перш ніж змінювати будь-який із кінців. Оголосіть вікно тим людям, які це помітять.

Якщо початкове значення було розкрите, ротація — правильна відповідь, і його декодування нічого не додає. Розкритий секрет скомпрометований незалежно від того, чи хтось відновив байти.

Запишіть, де живе нове значення і кому воно належить. Наступний інцидент запитає про це, а не про декодер.