اول روش EAP: کدام هش گذرواژه را VPN می‌تواند به کار ببرد
VPN خود راز را بررسی می‌کند، نه هش وب را. روش را بخوانید و سپس پیش از وعده دادن به ادامه کار همان گذرواژه‌ها، ببینید مخزن چه چیزی نگه می‌دارد.
بسیاری از تیم‌ها ورود وب کارآمدی دارند و VPNای که هر گذرواژه‌ای از همان جدول را رد می‌کند. برنامه وب هشی را که خودش محاسبه کرده مقایسه می‌کند، در حالی که تونل از کارخواه می‌خواهد مالکیت یک راز را به گونه‌ای اثبات کند که کارساز بتواند بررسی‌اش کند. این‌ها خواسته‌های متفاوتی از ماده ذخیره‌شده هستند. بیشتر این پروژه‌ها درست در همین شکاف متوقف می‌شوند.
نخست روش را بخوانید، سپس طرح‌واره را
پیش از نگاه کردن به هر طرح‌واره‌ای بنویسید که روش برگزیده چه اثباتی می‌خواهد. روش چالش-پاسخ ماده‌ای لازم دارد که کارساز بتواند پاسخ مورد انتظار را از آن محاسبه کند، که در عمل یعنی خود گذرواژه یا شکلی مشتق‌شده و سازگار. روشی که گذرواژه را درون تونلی محافظت‌شده حمل می‌کند خود گذرواژه را نزد بررسی‌کننده می‌خواهد. مستندات روش را برای خواسته بررسی‌کننده بخوانید، نه برای پیکربندی کارخواه، چون خواسته‌های کارخواه معمولاً بخش آسان ماجراست.
هش نمک‌دار تولیدشده توسط یک چارچوب وب مدرن هیچ‌یک از این دو را فراهم نمی‌کند. تنها یک مقایسه مشخص را بررسی می‌کند و بازگرداندنش به رازی که از آن آمده ممکن نیست.
چالش-پاسخ نمی‌تواند از هش نمک‌دار استفاده کند
MSCHAPv2 یک تبادل چالش-پاسخ است، پس کارساز هرگز گذرواژه را دریافت نمی‌کند و نمی‌تواند رشته ذخیره‌شده‌ای را مقایسه کند. باید پاسخ مورد انتظار را از ماده‌ای که از پیش دارد استخراج کند، و به همین دلیل شکل‌های ذخیره‌شده سازگار چنین تنگ‌اند. مقدار bcrypt یا Argon2 با نمک جداگانه برای هر کاربر چنان یک‌طرفه است که آن تبادل را کاملاً کنار می‌گذارد. جدول زیر از شکل ذخیره‌سازی آغاز می‌شود نه از نام روش، چون شکل ذخیره‌سازی است که پاسخ را تعیین می‌کند.
| What the store holds | What that material can verify | What has to change |
|---|---|---|
| A bcrypt or Argon2 value with a per-user salt | nothing challenge-response can use, and not the password either | re-enrol the users, or place a verifying service in front |
| An unsalted NT-hash | MSCHAPv2, and inner PAP through a TLS tunnel | nothing, as long as that store is the verifier |
| A client certificate with a revocation list | EAP-TLS only | move enrolment and revocation to the PKI owner |
مستندات افزونه SQL برای strongSwan طرح‌واره‌ای از خود برای پیکربندی و اعتبارنامه‌ها تعریف می‌کند و پروژه هنوز آن افزونه را آزمایشی می‌داند. هیچ چیز در آن با جدول کاربران یک برنامه سازگار نمی‌شود یا حدس نمی‌زند کدام طرح هش‌سازی یک مقدار ذخیره‌شده را ساخته است. بنابراین گزینه‌های واقع‌بینانه مهاجرت به مخزنی است که دروازه می‌تواند به کار ببرد، یا سرویس احراز هویتی در برابر مخزن موجود که بتواند تبادل را انجام دهد. هر چیز دیگری اتصال‌دهنده‌ای است با فرضی پنهان در درونش.
RADIUS کار را جابه‌جا می‌کند، نه خواسته را
سپردن EAP به کارساز RADIUS جای بررسی را عوض می‌کند و معمولاً رد حسابرسی را بهتر می‌کند. گذرواژه را از هش یک‌طرفه بازنمی‌گرداند، پس سرویس احراز هویت هنوز ماده‌ای سازگار با روشی که پایانش می‌دهد لازم دارد. تیم‌ها این را پس از ساختن مسیر RADIUS و برخوردن به همان دیوار در سر دیگر می‌فهمند.
جایی که کارساز RADIUS می‌تواند دایرکتوری دارای اعتبارنامه سازگار را بخواند، طراحی کار می‌کند و دروازه VPN ساده می‌ماند. جایی که نمی‌تواند، پاسخ صادقانه تغییر ثبت‌نام است نه اتصال‌دهنده‌ای دیگر. تأمین و لغو از آنِ کسی است که هویت را در اختیار دارد، پس جدولی کپی‌شده بدون فرایند همگام‌سازی پشتیبانی‌شده یک چرخه عمر دوم برای اعتبارنامه است نه ورود یکپارچه. نخستین بار که کسی گذرواژه را فقط در یک جا بازنشانی کند از هم می‌گسلد، و این گسست خاموش می‌ماند تا وقتی حسابی که در هر دو سامانه هست در هر یک رفتار متفاوتی نشان دهد.
حسابی را که دایرکتوری را می‌خواند به همان خواندن محدود کنید و آن را از حسابی که دروازه برای پیکربندی خودش به کار می‌برد جدا نگه دارید. حساب مدیریتی مشترک طراحی فقط‌خواندنی را به شعاع آسیب بسیار گسترده‌تری تبدیل می‌کند.
حساب کجا باید زندگی کند
وقتی مسئله ماده حل شود، دو معماری می‌ماند. دروازه می‌تواند مخزن کوچکی از اعتبارنامه‌ها داشته باشد که فقط خودش می‌خواند، یا کار را به سرویس احراز هویتی بسپارد که در برابر دایرکتوری سازمانی می‌ایستد.
اولی ساده‌تر برای اندیشیدن و بدتر برای کاربر است، که در پایان گذرواژه دومی برای نگهداری دارد. دومی یک هویت را نگه می‌دارد و وابستگی به سرویسی را می‌افزاید که اکنون باید پیش از اتصال هر کس برپا باشد. هیچ‌کدام غلط نیست، اما انتخاب باید کنار پیکربندی دروازه ثبت شود، چون وگرنه مهندس بعدی گمان می‌کند آن یکی برگزیده شده است. هر چه برگزینید، دو فرمان زیر همان‌هایی هستند که وضعیت کنونی را پیش از تغییر نشان می‌دهند.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsاحراز هویت حساب مجوزدهی را هم روشن نمی‌کند. عضویت گروهی، وضعیت دستگاه و اجازه شبکه هنوز به نگاشت صریح نیاز دارند، پس از آنکه کاربر هویت لازم را اثبات کرد. اتصالی که بی‌نقص احراز هویت می‌شود و هیچ مجوزی نمی‌دهد نتیجه سیاست است، نه اشکال روش.