SRP از ارسال گذرواژه در تبادل ورود جلوگیری می‌کند؛ اما اعتبارسنج سرقت‌شده را بی‌ضرر نمی‌کند.
پروتکل Secure Remote Password یا SRP به کلاینت و سرور امکان می‌دهد با استفاده از گذرواژه احراز هویت کنند، بدون آنکه خود گذرواژه در تبادل معمول پروتکل ارسال شود. این روش می‌تواند افشای گذرواژه نزد سروری را کاهش دهد که در غیر این صورت هنگام ورود آن را دریافت می‌کرد.
اما همهٔ اسرار مرتبط با گذرواژه را از سرور حذف نمی‌کند. سرور یک مقدار اعتبارسنج نگه می‌دارد و اعتبارسنجِ سرقت‌شده می‌تواند برای حدس‌زدن آفلاین گذرواژه به کار رود. این تمایز در ارزیابی ادعاهای «ورود با دانش صفر» ضروری است.
در مقایسه با ورود متعارف با گذرواژه چه چیزی تغییر می‌کند؟
در طراحی متعارف، کلاینت گذرواژه را از طریق اتصال TLS با اصالت تأییدشده می‌فرستد. سروری با طراحی مناسب، یک هشِ نمک‌دارِ مناسب از گذرواژه را مقایسه می‌کند، اطلاعات ورود را در لاگ ثبت نمی‌کند و در برابر حدس‌زدن محافظت اعمال می‌کند. TLS از اتصال محافظت می‌کند؛ هش گذرواژه به شیوه‌ای دیگر از اطلاعات ورودِ ذخیره‌شده محافظت می‌کند.
SRP تبادل را تغییر می‌دهد. هنگام ثبت‌نام، سامانه نمک و مواد اعتبارسنج را ایجاد می‌کند. هنگام ورود، دو طرف با مقادیر تازهٔ پروتکل و اسرار مختص خود، مواد کلیدیِ مشترک را برقرار و تأیید می‌کنند. کلاینت از گذرواژه و سرور از اعتبارسنج خود استفاده می‌کند. کلاینتی که درست رفتار می‌کند، خود گذرواژه را به‌عنوان محتوای درخواست ورود ارسال نمی‌کند.
مشخصات SRP در RFC 2945 مبنای پروتکل را توضیح می‌دهد. پروفایل‌ها و پیاده‌سازی‌های بعدی نیازمند بررسی پارامترهای دقیق و کنترل‌های پیام خود هستند؛ نامیدن یک طراحی به‌عنوان «SRP» ثابت نمی‌کند که همهٔ انتخاب‌های پیاده‌سازی صحیح‌اند.
| پرسش | ورود متعارف با گذرواژه روی TLS | تبادل SRP با پیاده‌سازی صحیح |
|---|---|---|
| آیا سرور برنامه هنگام ورود گذرواژهٔ واردشده را دریافت می‌کند؟ | معمولاً بله | نه به‌عنوان بخشی از تبادل پروتکل |
| چه مواد حساس احراز هویتی ذخیره می‌شوند؟ | معمولاً هش نمک‌دارِ گذرواژه | نمک و اعتبارسنجِ مشتق‌شده از گذرواژه |
| آیا پایگاه دادهٔ سرقت‌شده امکان حدس‌زدن آفلاین می‌دهد؟ | بله، بسته به مواد ذخیره‌شده | بله، مواد اعتبارسنج SRP سرقت‌شده می‌توانند برای حدس‌زدن استفاده شوند |
| آیا در برابر کی‌لاگر محافظت می‌کند؟ | خیر | خیر |
| آیا تاریخچهٔ پیام‌ها را خودکار رمزگذاری می‌کند؟ | خیر | خیر |
چرا اعتبارسنج سرقت‌شده همچنان مهم است
بخش ۳٫۳ از RFC 5054 صریحاً دربارهٔ اعتبارسنج‌های سرقت‌شده صحبت می‌کند. این بخش توضیح می‌دهد که اعتبارسنج می‌تواند به مهاجم امکان دهد خود را جای سرور جا بزند و برای بازیابی گذرواژه حملهٔ واژه‌نامه‌ای انجام دهد.
تمایز مهم این است که اعتبارسنج صرفاً یک توکن ورودِ قابل‌استفادهٔ مجدد برای کلاینت نیست. اما این به معنی بی‌ضرربودن آن نیست. مهاجم می‌تواند گذرواژه‌های احتمالی را با مواد سرقت‌شده بیازماید، به‌جای آنکه برای هر راز احتمالی مسئلهٔ لگاریتم گسسته را حل کند. گذرواژهٔ ضعیف یا تکراری همچنان خطری جدی است.
محدودیت نرخ آنلاین می‌تواند تلاش‌ها علیه سرویس زنده را کند کند، اما بر محاسباتی که روی پایگاه دادهٔ سرقت‌شده انجام می‌شوند حاکم نیست. حفاظت از پایگاه داده، پردازش دقیق گذرواژه و گذرواژه‌های قوی و منحصربه‌فرد همچنان اهمیت دارند.
SRP از چه چیزهایی محافظت نمی‌کند
نقطهٔ پایانیِ به‌خطر‌افتاده: بدافزار می‌تواند پیش از آغاز پروتکل گذرواژه را ضبط کند یا پس از آن یک نشست احرازشده را بدزدد.
صفحهٔ ورود مخرب: اگر خود صفحه‌ای که گذرواژه می‌خواهد خصمانه باشد، می‌تواند متن واردشده را به جای دیگری بفرستد. برنامهٔ وب همچنان به مسیر تحویل قابل اعتماد نیاز دارد.
تمام مسیرهای بازیابی: فرایند ایمیل، پیامک یا پشتیبانی که دسترسی به حساب می‌دهد، الزامات خاص خود را دارد. حتی قوی‌ترین روش معمول ورود می‌تواند با یک مسیر جایگزین ضعیف‌تر تضعیف شود.
هر حملهٔ فعال شبکه: پارامترهای پروتکل، اعتبارسنجی ورودی، تأیید متقابل و اتصال احرازشدهٔ پیرامونی اهمیت دارند. حفاظت‌های TLS تجویزشده برای یک استقرار را با شعار «گذرواژه هرگز جابه‌جا نمی‌شود» جایگزین نکنید.
فراداده یا رمزگذاری چت: احراز هویت پاسخ می‌دهد که آیا باید به یک نشست اجازهٔ ورود داد یا نه. تعیین نمی‌کند چه سوابق گفت‌وگویی وجود دارند یا چه کسی کلیدهای رمزگشایی پیام را در اختیار دارد.
لیوارا چگونه ورود را از بازیابی هویت جدا می‌کند
مرور امنیتی لیوارا احراز هویت SRP را جدا از پروتکل پیام‌رسانی LVR1 توضیح می‌دهد. همچنین یک پشتیبان رمزگذاری‌شدهٔ هویت در نسخهٔ ۷ را مستند می‌کند که با کلید بازیابیِ تصادفیِ ۲۵۶ بیتی و جداگانه محافظت می‌شود.
این پشتیبان پیش از بارگذاری رمزگذاری و مهروموم می‌شود و هویت رمزنگاری را بازیابی می‌کند، نه تاریخچهٔ چت را. دانستن گذرواژهٔ حساب به‌تنهایی آن کلیدهای رمزگذاری را برنمی‌گرداند. از سوی دیگر، اینکه پشتیبانی نمی‌تواند راز رمزگذاری را بازسازی کند، ثابت نمی‌کند که هیچ عملیات مدیریت حساب یا فرایند تغییر گذرواژه‌ای نمی‌تواند وجود داشته باشد.
مدل تهدید نیز به‌خطر‌افتادن دستگاه و فرادادهٔ ارتباطیِ قابل مشاهده را در محدودهٔ بررسی نگه می‌دارد. نباید با تکیه بر SRP، کل سرویس را نسبت به تمام جنبه‌های فعالیت کاربر «دانش صفر» نام‌گذاری کرد.
چک‌لیست عملی ارزیابی
به‌عنوان کاربر، گذرواژه‌ای قوی و منحصربه‌فرد انتخاب کنید، از دستگاه محافظت کنید، مواد بازیابی را در محل جداگانهٔ مناسبی نگه دارید و روش لغو نشست‌ها را بشناسید. صرفاً چون سایتی نامطمئن ادعا می‌کند از SRP استفاده می‌کند، راز خود را در آن وارد نکنید.
به‌عنوان بازبین فنی، پروفایل دقیق پروتکل، پردازش گذرواژه به اعتبارسنج، اعتبارسنجی ورودی، مدیریت شکست، جریان ثبت‌نام و طراحی بازنشانی را بخواهید. کلاینت و سرور را با هم بررسی کنید. به‌جای اتکا صرف به آزمون ورود موفق، آزمون مقادیر عمومی نامعتبر، بازپخش و نشست‌های قطع‌شده را نیز در نظر بگیرید.
SRP ابزار مفیدی برای محدودکردن افشای گذرواژه هنگام احراز هویت است. ارزش آن وقتی روشن‌تر می‌شود که مزایای واقعی‌اش در کنار خطر سرقت اعتبارسنج، به‌خطر‌افتادن نقطهٔ پایانی و بازیابی توضیح داده شود، نه اینکه پایان مشکلات امنیت گذرواژه معرفی شود.
