Cheie IPsec partajată în prealabil: octeții din spatele șirului tastat
Două capete pot avea șiruri care par identice și pot deriva chei diferite. Verificați tipul câmpului, orice codificare și octeții finali înainte de a slăbi ceva.
Doi administratori compară secretul pe ecran, cad de acord că se potrivește, iar tunelul tot nu trece autentificarea. Șirul pe care l-au comparat nu este valoarea pe care o introduce oricare capăt în derivarea cheii. Între caracterele pe care le vedeți și octeții pe care protocolul îi aplică funcției hash există un tip de câmp, o codificare de text, un editor și un clipboard, iar oricare dintre cele patru poate schimba intrarea fără a schimba aspectul. Comparați octeții și nepotrivirea apare de obicei în câteva secunde.
Ce face poarta de acces cu șirul
O cheie partajată în prealabil nu este trimisă prin rețea și comparată. Fiecare capăt introduce copia locală în derivarea cheii pentru schimbul IKE, iar sarcinile utile de autentificare rezultate fie sunt verificate, fie nu. Această proiectare înseamnă că cele două copii trebuie să fie identice octet cu octet, nu doar asemănătoare vizual, și înseamnă de asemenea că eșecul este raportat în etapa de autentificare, nu ca mesaj de parolă greșită.
Așadar, întrebarea utilă nu este niciodată «ar arată acestea la fel», ci «ce secvență exactă de octeți aplică funcției hash fiecare implementare».
De unde provin octeții în plus
O linie nouă la final este vinovatul clasic și se ascunde la vedere pentru că majoritatea editoarelor adaugă una invizibil la salvarea unui fișier. Un spațiu la început sau la final lipit dintr-o fereastră de chat face același lucru, la fel și un ghilim tipografic înlocuit cu unul drept de un procesor de text. Niciuna dintre acestea nu schimbă comparația vizuală pe care o face un om.
Comparați cu un instrument care arată octeți, nu glife. printf '%s' "$PSK" | xxd | tail -2 tipărește coada valorii în hexazecimal, unde un 0a sau un 20 rătăcit este evident. Faceți acest lucru la ambele capete și comparați cele două descărcări una lângă alta. Faceți acest lucru pe material de test generat, nu pe un secret de producție pe care apoi îl lăsați în istoricul shell-ului.
Codificat nu înseamnă criptat
Exporturile de configurare poartă adesea secretul într-o codificare de bază, uneori cu întreruperi de rând la fiecare șaizeci sau șaptezeci și șase de caractere și uneori cu umplutură. Dacă un capăt așteaptă octeții decodați și lipiți textul codificat, nu ați trimis o parolă diferită, ați trimis una mult mai lungă făcută din caractere imprimabile. Base64 nu oferă nicio confidențialitate, motiv pentru care un secret codificat nu trebuie lipit niciodată pe un forum pentru a cere o a doua opinie.
Dicționarul IPSec al Apple este un exemplu util că tipul contează: documentează SharedSecret ca date pentru metoda de autentificare cu secret partajat în sarcinile utile L2TP și Cisco IPsec. Aceasta este o proprietate specifică într-o sarcină utilă specifică, nu un câmp de text general pe care îl puteți reutiliza pentru alt protocol care cere din întâmplare un secret.
O limită pretinsă aparține unei singure combinații
Rapoartele vechi despre un plafon de treizeci și doi de caractere la un client Apple sunt rapoarte reale despre o versiune de client, un protocol și o formă de profil. Ele nu sunt o limită universală pentru fiecare platformă Apple, fiecare furnizor și fiecare protocol. Verificați versiunea, tipul sarcinii utile și cerința porții de acces împreună, apoi testați pe o configurație aprobată în loc să deduceți dintr-un fir. Scrieți combinația testată în registrul de modificări, altfel următoarea persoană va cita același fir cu mai multă încredere decât merită.
Dacă o limită se aplică cu adevărat, răspunsul este o proiectare de acreditări acceptată care se încadrează în ea, nu o versiune scurtată a unui secret puternic. Trunchierea unei chei de producție pentru a satisface o limită presupusă reduce puterea acesteia definitiv și produce un sistem a cărui documentație nu mai corespunde securității sale.
Corectați reprezentarea, nu puterea
Când autentificarea eșuează după confirmarea reprezentării, citiți politica efectivă în etapa de autentificare: ce metodă se negociază, ce identitate de partener se așteaptă și dacă poarta de acces corespunde conexiunii la care vă gândiți. Presupunerile din ce în ce mai slabe nu sunt diagnostic, ci o degradare lentă cu un tichet de asistență atașat.
Dacă acreditările necesare nu pot îndeplini standardul organizației, schimbați proiectarea cu una care poate. Un secret partajat cu suficientă entropie, generat o dată, păstrat într-un câmp administrat și niciodată publicat este un răspuns perfect bun; o versiune mai scurtă a acestuia nu este.