SRP رمز را در پروتکل ارسال نمی‌کند؛ این با حذف رمز، مصونیت از فیشینگ یا بی‌خطر بودن verifier یکسان نیست.
پاس‌کی و SRP دو راه متفاوت برای احراز هویت‌اند. پاس‌کی از جفت‌کلید استفاده می‌کند و می‌تواند نیاز به رمز عبور را حذف کند. SRP همچنان مبتنی بر رمز عبور است، اما در اجرای درست پروتکل، خودِ رمز را برای اثبات دانستن آن به سرور نمی‌فرستد.
پس «ورود بدون ارسال رمز» با «ورود بدون داشتن رمز» یکی نیست. انتخاب میان این روش‌ها باید بر خطر فیشینگ، مدیریت اعتبارنامه، بازیابی و کیفیت پیاده‌سازی تکیه کند؛ نه بر برچسب کلی «صفر‌دانش».
پاس‌کی چه چیزی را تغییر می‌دهد؟
در احراز هویت مبتنی بر پاس‌کی، سرویس کلید عمومی را نگه می‌دارد و کاربر با کنترل کلید خصوصی ورود را تأیید می‌کند. اتصال اعتبارنامه به سرویس و مبدأ مربوط، بخش مهم مقاومت این روش در برابر فیشینگ است. توضیح FIDO دربارهٔ پاس‌کی.
همهٔ پاس‌کی‌ها الزاماً در ابر همگام نمی‌شوند. برخی به یک دستگاه یا کلید امنیتی وابسته‌اند؛ برخی از مسیر ارائه‌دهندهٔ اعتبارنامه بین دستگاه‌ها منتقل می‌شوند. مدل بازیابی و حفاظت همگام‌سازی را باید برای همان ارائه‌دهنده بررسی کرد. از «همگام‌سازی ابری» به‌تنهایی نمی‌توان نتیجه گرفت شرکت کلیدها را به‌صورت قابل‌خواندن نگه می‌دارد.
امنیت نشست پس از ورود نیز جداست. پاس‌کی، بدافزار روی دستگاه یا سرقت یک نشست معتبر را خودکار خنثی نمی‌کند.
SRP چه چیزی را به سرور می‌دهد؟
SRP از خانوادهٔ تبادل کلید احرازشده با رمز عبور است. سرور به‌جای نگهداری خودِ رمز، داده‌ای مانند نمک و تأییدکننده یا verifier نگه می‌دارد. دو طرف با تبادل پیام‌های پروتکل، دانستن راز و کلید مشترک را بررسی می‌کنند.
اما verifier دادهٔ بی‌خطر نیست. بخش ۳٫۳ RFC 5054 صریحاً می‌گوید مهاجمی که تأییدکننده را به‌دست آورد می‌تواند برای حدس‌زدن رمز حملهٔ فرهنگ‌لغت انجام دهد. بنابراین ادعای «سرقت پایگاه داده هیچ امکان حدس آفلاین نمی‌دهد» نادرست است.
رمز قوی، حفاظت سرور، پارامترهای مناسب، اعتبارسنجی ورودی‌ها و کنترل تلاش‌های ورود همچنان لازم‌اند. SRP همچنین تضمین نمی‌کند صفحه‌ای که رمز را در آن تایپ می‌کنید سالم باشد؛ کد مخرب می‌تواند پیش از اجرای پروتکل آن را بگیرد.
مقایسهٔ منصفانه
| پرسش | پاس‌کی | SRP |
|---|---|---|
| آیا کاربر یک رمز عبور سرویس را به یاد می‌سپارد؟ | معمولاً نه؛ کنترل اعتبارنامه لازم است | بله، روش بر دانستن رمز متکی است |
| سرویس چه چیزی برای ورود نگه می‌دارد؟ | کلید عمومی و اطلاعات مرتبط | تأییدکننده و پارامترهای مرتبط |
| مقاومت به فیشینگ چگونه حاصل می‌شود؟ | اتصال اعتبارنامه به سرویس/مبدأ در طراحی FIDO | عدم ارسال رمز در پروتکل کافی نیست تا ورودی جعلی را ایمن کند |
| آیا ابر الزامی است؟ | نه؛ گزینه‌های وابسته به دستگاه هم وجود دارد | پروتکل به ارائه‌دهندهٔ هویت ثالث نیاز ذاتی ندارد، اما به سرویس احراز هویت نیاز دارد |
| بازیابی چگونه انجام می‌شود؟ | به نوع اعتبارنامه و ارائه‌دهنده وابسته است | سیاست حساب و محصول تعیین می‌کند، نه نام SRP |
از این جدول نمی‌توان یک رتبه‌بندی مطلق برای تمام پیاده‌سازی‌ها ساخت. یک جریان بازیابی ضعیف می‌تواند مزیت روش ورود قوی را تضعیف کند.
ورود حساب با کلیدهای چت چه ارتباطی دارد؟
احراز هویت به سرویس می‌گوید چه کسی اجازهٔ فعالیت دارد. کلیدهای رمزنگاری پیام تعیین می‌کنند چه کسی محتوا را باز می‌کند. ممکن است محصول این دو را به هم مرتبط کند، اما رابطه باید مستند باشد.
در مستندات امنیت لیوارا، SRP برای ورود توصیف شده و بستهٔ بازیابی v7 برای هویت رمزنگاری‌شده جدا آمده است. آن بسته هویت را بازیابی می‌کند، نه تاریخچهٔ چت. از همین رو، «رمز ورود درست است» به معنی «همهٔ کلیدها و پیام‌های قدیمی برگشته‌اند» نیست.
این مقاله یک مقایسهٔ مفهومی است، نه آزمون عملی همهٔ روش‌های ورود لیوارا یا تأیید اجرای دقیق یک RFC در محصول.
هنگام انتخاب چه بپرسیم؟
- اگر دستگاه گم شود، راه جایگزین ورود چیست و چه کسی آن را کنترل می‌کند؟
- آیا روش بازیابی از ورود اصلی ضعیف‌تر است؟
- نشست‌های ناشناس چگونه دیده و باطل می‌شوند؟
- آیا تغییر روش ورود، کلیدهای پیام یا دستگاه‌های مرتبط را تغییر می‌دهد؟
- برای همگام‌سازی اعتبارنامه، چه حساب و چه حفاظت مستقلی لازم است؟
جمع‌بندی: پاس‌کی را ذاتاً «ناامن چون ابری» و SRP را «مصون از رخنه چون صفر‌دانش» ننامید. مرز هر روش و سیاست بازیابیِ محصول، پایهٔ مقایسهٔ قابل‌اعتماد است.
