بازیابی حساب، هویت و تاریخچهٔ گفتگو عملیات متفاوتی هستند؛ بررسی کنید محصول واقعاً از کدام‌یک پشتیبانی می‌کند.
بازیابی هویت رمزنگاری‌شده، مواد کلیدی مرتبط با هویت شما در پیام‌رسان را برمی‌گرداند. این کار لزوماً همان ورود دوباره به حساب، بازگرداندن همهٔ گفتگوها یا اثبات امن‌بودن دستگاه جایگزین نیست.
پشتیبان رمز‌شدهٔ کلید می‌تواند به سرور اجازه دهد بسته‌ای قابل بازیابی را نگه دارد، بدون آنکه راز لازم برای بازکردنش را در اختیار داشته باشد. اینکه این طراحی از کاربر محافظت می‌کند یا نه، به تولید کلید، احراز هویت، نگهداری راز بازیابی و نحوهٔ برخورد کلاینت با هویت بازیابی‌شده بستگی دارد.
سه چیزی که مردم «بازیابی» می‌نامند
| هدف بازیابی | چه چیزی باید بازگردانده یا مجاز شود |
|---|---|
| دسترسی به حساب | اجازهٔ ورود و استفاده از سرویس |
| هویت رمزنگاری‌شده | کلیدهای خصوصی مناسب یا یک هویت جدیدِ احرازشده |
| تاریخچهٔ چت | داده‌های پیام و هر کلید یا وضعیت لازم برای خواندن آن‌ها |
ورود موفق هیچ‌یک از دو مورد دیگر را ثابت نمی‌کند. به همین ترتیب، کلید هویت لزوماً کلیدهای پیام قدیمی را که عمداً پاک شده‌اند یا فایل تاریخچه‌ای را که دیگر وجود ندارد، دوباره ایجاد نمی‌کند.
پیش از اتکا به قابلیت بازیابی یک محصول، بنویسید این قابلیت واقعاً کدام هدف را وعده می‌دهد.
پشتیبان رمز‌شدهٔ هویت چگونه می‌تواند کار کند
در یک طراحی متداول، مواد هویت روی دستگاهی قابل اعتماد تولید می‌شود، پشتیبان با رازی جداگانه برای بازیابی رمز می‌شود و فقط بستهٔ محافظت‌شده نزد سرویس نگهداری می‌شود. دستگاه جایگزین بسته را دریافت می‌کند و راز بازیابی را به‌صورت محلی به کار می‌گیرد.
سرور همچنان ممکن است دسترسی به بسته را کنترل کند، درخواست‌ها را ببیند، داده را در اختیار نگذارد یا نسخه‌ای قدیمی‌تر برگرداند. رمزنگاری اصالت‌سنجی‌شده و پیوند دادن نسخه و هویت، به مقابله با برخی خطرهای دست‌کاری کمک می‌کنند؛ دسترس‌پذیری و رسیدگی به بازگردانی نسخهٔ قدیمی به طراحی مستقل نیاز دارند. «رمز‌شده روی سرور» پاسخ کاملی برای همهٔ سناریوهای نفوذ به سرور نیست.
کلید بازیابی تصادفی با آنتروپی بالا و گذرواژه‌ای که انسان انتخاب کرده نیز ورودی‌های متفاوتی هستند. HKDF را روشی معرفی نکنید که هر عبارت عبور ضعیفی را به رازی قوی تبدیل می‌کند. RFC 5869 دربارهٔ نقش HKDF بحث می‌کند و آن را از کش‌دادن گذرواژه متمایز می‌سازد.
مستندات v7 لیوارا چه می‌گوید
صفحهٔ امنیت لیوارا می‌گوید کلیدهای توافق و امضای P-256 و بذر ML-KEM پیش از بارگذاری، روی دستگاه و با یک کلید بازیابی تصادفی ۲۵۶ بیتی رمز می‌شوند. قالب v7 اطلاعاتی از جمله مجموعهٔ الگوریتم‌ها، دورهٔ هویت و نسل را اصالت‌سنجی می‌کند.
همان صفحه صریح است: هویت را بازیابی می‌کند، نه تاریخچهٔ چت را. همچنین می‌گوید گذرواژهٔ درست ورود به‌تنهایی برای بازکردن پشتیبان رمز‌شدهٔ کلید کافی نیست؛ کلید بازیابی که عبارت بازیابی نمایندهٔ آن است، لازم است.
این‌ها ادعاهای منتشرشدهٔ محصول هستند، نه ممیزی تازه‌ای از قالب پشتیبان یا تک‌تک مسیرهای بازیابی. مدل تهدید عمومی‌تر را باید در کنار این توضیح محدودتر دربارهٔ بازیابی خواند.
جایگاه SRP کجاست
مدل احراز هویت SRP به ورود مبتنی بر گذرواژه مربوط است. این مدل می‌تواند در تبادل موردنظر پروتکل از ارسال خود گذرواژه جلوگیری کند، اما محتوای پشتیبان کلید را تعریف نمی‌کند و همهٔ کلیدهای بازیابی را به‌طور خودکار مشتق نمی‌کند.
راستی‌آزمای سمت سرور آن همچنان به محافظت نیاز دارد. بخش ۳٫۳ از RFC 5054 خطر حدس‌زدن گذرواژه پس از سرقت راستی‌آزما را شرح می‌دهد. «سرور در این تبادل گذرواژه را دریافت نمی‌کند» را به «نفوذ به سرور هیچ اطلاعات مفیدی را افشا نمی‌کند» تبدیل نکنید.
نشست‌های حساب، بسته‌های بازیابی، فرادادهٔ عملیاتی و نرم‌افزار کلاینت دارایی‌های جداگانه‌ای هستند و هرکدام شیوه‌های خرابی متفاوتی دارند.
چک‌لیست آمادگی برای بازیابی امن
- دقیقاً مشخص کنید این قابلیت چه داده‌هایی را بازیابی می‌کند و چه داده‌هایی را نه.
- راز بازیابی را جایی نگه دارید که گم‌شدن تلفن به‌معنای ازدست‌رفتن تنها نسخهٔ آن نباشد.
- راز را در پیام، تیکت پشتیبانی یا تصویر صفحهٔ عمومی قرار ندهید.
- از محل نگهداری راز محافظت کنید؛ هرکس آن را به دست آورد، اگر پشتیبان مرتبط و دسترسی لازم را هم داشته باشد، ممکن است توانایی‌های مهمی به دست بیاورد.
- پیش از پاک‌کردن یا تعویض تنها دستگاه سالم، دستورالعمل رسمی بازیابی را مرور کنید.
- فقط از مسیرهای پشتیبانی‌شده آزمایش کنید، بدون اینکه تنها نسخهٔ داده‌های مهم را از بین ببرید.
پس از بازیابی، دستگاه‌های پیوندشده و نشست‌ها را جداگانه بررسی کنید. بازیابی مواد هویت خودبه‌خود دسترسی دستگاه قدیمی را لغو نمی‌کند. اگر هویت رمزنگاری‌شده تغییر کرده است، مخاطبانِ گفتگوهای حساس باید کلید جدید را از مسیری مستقل و قابل اعتماد تأیید کنند.
اگر عبارت بازیابی گم شود
فرض نکنید پشتیبانی می‌تواند رازی را دوباره ایجاد کند که سیستم از ابتدا برای نگهداری‌نکردنش طراحی شده است. به همان اندازه، فرض نکنید هر بار فراموش‌کردن گذرواژهٔ حساب یعنی همهٔ پیام‌های محلی از قبل از بین رفته‌اند. نتیجه به دستگاه‌های باقی‌مانده، پشتیبان‌های موجود و قواعد مستند محصول بستگی دارد.
پرسش مفید مشخص است: «کدام راز یا نسخه گم شده و کدام هدف بازیابی هنوز ممکن است؟» این پرسش پاسخ امن‌تری می‌دهد تا وعده‌ای کلی که بازیابی را یا بی‌دردسر می‌داند یا ناممکن.
