کلید از پیش اشتراکی IPsec: بایت‌های پشت رشته‌ای که تایپ کردید
دو طرف می‌توانند رشته‌هایی داشته باشند که یکسان به نظر می‌رسند و کلیدهای متفاوتی استخراج کنند. پیش از تضعیف هر چیزی، نوع فیلد، هر کدگذاری و بایت‌های انتهایی را بررسی کنید.
دو مدیر سِر را روی صفحه مقایسه می‌کنند، توافق می‌کنند که یکسان است، و تونل باز هم در احراز هویت شکست می‌خورد. رشته‌ای که مقایسه کردند مقداری نیست که هر یک از دو طرف به استخراج کلید می‌دهد. میان نویسه‌هایی که می‌بینید و بایت‌هایی که پروتکل درهم‌سازی می‌کند، یک نوع فیلد، یک کدگذاری متن، یک ویرایشگر و یک کلیپ‌بورد وجود دارد، و هر یک از این چهار می‌تواند ورودی را بدون تغییر ظاهر آن عوض کند. بایت‌ها را مقایسه کنید و اختلاف معمولاً در چند ثانیه آشکار می‌شود.
دروازه با رشته چه می‌کند
کلید از پیش اشتراکی روی شبکه فرستاده و مقایسه نمی‌شود. هر طرف نسخه محلی خود را به استخراج کلید برای تبادل IKE می‌دهد، و بارهای مفید احراز هویت حاصل یا تأیید می‌شوند یا نمی‌شوند. این طراحی یعنی دو نسخه باید بایت‌به‌بایت یکسان باشند نه ظاهراً مشابه، و همچنین یعنی شکست در مرحله احراز هویت گزارش می‌شود نه به‌صورت پیام رمز عبور نادرست.
پس پرسش سودمند هرگز «آیا اینها یکسان به نظر می‌رسند» نیست، بلکه «هر پیاده‌سازی چه دنباله دقیقی از بایت‌ها را درهم‌سازی می‌کند» است.
بایت‌های اضافی از کجا می‌آیند
خط جدید انتهایی مقصر کلاسیک است و در دید آشکار پنهان می‌شود، چون بیشتر ویرایشگرها هنگام ذخیره فایل یکی را نامرئی اضافه می‌کنند. فاصله ابتدایی یا انتهایی که از پنجره گفتگو چسبانده شده باشد همین کار را می‌کند، و همچنین نقل‌قول تایپوگرافیکی که واژه‌پرداز آن را با نقل‌قول مستقیم جایگزین کرده باشد. هیچ‌یک از اینها مقایسه بصری‌ای را که انسان انجام می‌دهد تغییر نمی‌دهد.
با ابزاری مقایسه کنید که بایت نشان می‌دهد نه گلیف. printf '%s' "$PSK" | xxd | tail -2 انتهای مقدار را در مبنای شانزده چاپ می‌کند، جایی که یک 0a یا 20 سرگردان آشکار است. این کار را در هر دو طرف انجام دهید و دو خروجی را کنار هم مقایسه کنید. این کار را روی مواد آزمون تولیدشده انجام دهید، نه روی سِر تولیدی که بعداً در تاریخچه پوسته رهایش می‌کنید.
کدگذاری‌شده رمزگذاری‌شده نیست
خروجی‌های پیکربندی اغلب سِر را در یک کدگذاری پایه حمل می‌کنند، گاهی با شکستن خط هر شصت یا هفتاد و شش نویسه و گاهی با پرشدگی. اگر یک طرف بایت‌های رمزگشایی‌شده را انتظار داشته باشد و شما متن کدگذاری‌شده را بچسبانید، رمز عبور متفاوتی نفرستاده‌اید، رمز عبور بسیار طولانی‌تری از نویسه‌های قابل چاپ فرستاده‌اید. Base64 هیچ محرمانگی‌ای فراهم نمی‌کند، و به همین دلیل سِر کدگذاری‌شده هرگز نباید برای نظر دوم در انجمن چسبانده شود.
واژه‌نامه IPSec اپل نمونه سودمندی از اهمیت نوع است: SharedSecret را به‌عنوان داده برای روش احراز هویت با سِر مشترک در بارهای مفید L2TP و Cisco IPsec مستند می‌کند. این ویژگی مشخصی در یک بار مفید مشخص است، نه یک فیلد متنی عمومی که بتوانید برای پروتکل دیگری که تصادفاً سِر می‌خواهد دوباره به کار ببرید.
حد ادعاشده به یک ترکیب تعلق دارد
گزارش‌های قدیمی درباره سقف سی و دو نویسه در یک کلاینت اپل گزارش‌های واقعی درباره یک نسخه کلاینت، پروتکل و شکل پروفایل هستند. آن‌ها حد جهانی برای هر سکوی اپل، هر ارائه‌دهنده و هر پروتکل نیستند. نسخه، نوع بار مفید و الزام دروازه را با هم بررسی کنید، سپس روی چیدمانی تأییدشده آزمایش کنید نه اینکه از یک رشته گفتگو نتیجه بگیرید. ترکیب آزمون‌شده را در سابقه تغییر بنویسید، وگرنه نفر بعدی به همان رشته با اطمینانی بیش از آنچه سزاوار است استناد می‌کند.
اگر حدی واقعاً اعمال شود، پاسخ یک طراحی اعتبارنامه پشتیبانی‌شده است که در آن جا می‌شود، نه نسخه کوتاه‌شده یک سِر قوی. کوتاه کردن کلید تولیدی برای برآوردن یک حد حدسی، قدرت آن را برای همیشه کاهش می‌دهد و سیستمی می‌سازد که مستنداتش دیگر با امنیتش مطابقت ندارد.
بازنمایی را درست کنید، نه قدرت را
وقتی احراز هویت پس از تأیید بازنمایی شکست می‌خورد، سیاست مؤثر را در مرحله احراز هویت بخوانید: کدام روش در حال مذاکره است، چه هویت همتایی انتظار می‌رود، و آیا دروازه با اتصالی که فکر می‌کنید مطابقت دارد. حدس‌های به‌تدریج ضعیف‌تر تشخیص نیستند، یک تنزل آهسته با یک تیکت پشتیبانی پیوست هستند.
اگر اعتبارنامه لازم نمی‌تواند استاندارد سازمان را برآورده کند، طراحی را به یکی تغییر دهید که می‌تواند. یک سِر مشترک با آنتروپی کافی، یک‌بار تولیدشده، ذخیره‌شده در یک فیلد مدیریت‌شده و هرگز منتشرنشده، پاسخ کاملاً خوبی است؛ نسخه کوتاه‌ترش نه.