هک سرور پیام‌رسان الزاماً به معنی خوانده‌شدن همه پیام‌ها نیست. نتیجه به داده‌های ذخیره‌شده، محل کلیدها و سطح دسترسی مهاجم بستگی دارد. حتی وقتی متن چت به‌درستی سرتاسری رمز شده باشد، اطلاعات حساب، زمان‌ها، عضویت گروه و مسیر تحویل می‌توانند حساس باشند.
برای ارزیابی یک حادثه، نخست بپرسید چه چیزی در اختیار مهاجم قرار گرفته: یک نسخه پایگاه داده، کلیدهای زیرساخت، سرور فعال یا سامانه انتشار نرم‌افزار؟ این سناریوها پیامد یکسان ندارند.
پایگاه داده سرقت‌شده با سرور تحت کنترل فرق دارد
مهاجمی که فقط یک نسخه قدیمی از پایگاه داده دارد، به همان داده‌های ثبت‌شده محدود است. کنترل سرویس زنده می‌تواند امکان ثبت داده تازه، سرقت نشست، تغییر پاسخ‌ها یا تلاش برای جایگزینی کلید مخاطب را فراهم کند. دسترسی به زنجیره انتشار نرم‌افزار خطر دیگری است: کد مخرب روی endpoint ممکن است متن را پیش از رمزنگاری یا پس از رمزگشایی ببیند.
بنابراین ادعای «پایگاه داده فاقد کلید متن پیام است» مهم است، اما پاسخ کامل به همه انواع نفوذ نیست.
مقایسه پنج الگوی معماری
این‌ها الگوهای آموزشی‌اند، نه رتبه‌بندی پنج محصول. یک سرویس ممکن است برای قابلیت‌های مختلف چند الگو داشته باشد.
| الگو | داده در دسترس از پایگاه داده | مرز مهم |
|---|---|---|
| پیام و گذرواژه آشکار | محتوا و اعتبارنامه‌ها مستقیماً خواندنی‌اند | نبود حفاظت مناسب برای هر دو نوع داده |
| گذرواژه هش‌شده، پیام آشکار | محتوا خواندنی است؛ حدس گذرواژه ممکن است قابل آزمایش باشد | کیفیت روش ذخیره گذرواژه، متن چت را محافظت نمی‌کند |
| محتوا با کلید سرور رمز شده | متن رمز؛ خواندن به دسترسی به کلید بستگی دارد | جداسازی واقعی کلید و داده اهمیت دارد |
| چت E2EE با نسخه پشتیبان قابل‌دسترسی برای ارائه‌دهنده | چت زنده ممکن است محافظت شود، ولی نسخه تاریخچه مسیر افشای جدا دارد | سیاست و کلید پشتیبان باید بررسی شود |
| چت E2EE با بازیابی رمزنگاری‌شده و کلید مستقل | متن رمز و داده‌های عملیاتی؛ حفاظت محتوا به طراحی و حفاظت کلید وابسته است | دستگاه، عبارت بازیابی و احراز هویت مخاطب همچنان مهم‌اند |
رمزنگاری دیسک سرور در برابر سرقت یک دیسک خام مفید است. وقتی سرویس فعال یا کلید رمزگشایی نیز در اختیار مهاجم باشد، نباید همان حفاظت را مفروض گرفت. در E2EE هدف این است که سرویس واسطه کلید لازم برای خواندن محتوای محافظت‌شده را نداشته باشد.
فراداده چه چیزی را نشان می‌دهد؟
فراداده ممکن است نشان دهد چه حساب‌هایی ارتباط داشته‌اند، چه زمانی فعال بوده‌اند، عضو کدام گروه‌اند و چه مقدار داده جابه‌جا شده است. این اطلاعات متن پیام نیست، ولی برای شناخت شبکه ارتباطی یا الگوهای فعالیت ارزش دارد.
صفحه امنیت لیوارا صریحاً ذخیره و پردازش داده‌های عملیاتی، از جمله مسیریابی، عضویت، زمان‌ها، اندازه متن رمز و وضعیت تحویل را توضیح می‌دهد. نباید محرمانگی محتوای خصوصی را به ناشناس‌بودن کامل یا نبود هرگونه داده روی سرور تعبیر کرد.
SRP داده حساب را از خطر حدس‌زدن معاف نمی‌کند
SRP روشی برای اثبات دانستن گذرواژه بدون فرستادن مستقیم خود آن است. سرور همچنان داده تأییدکننده یا verifier نگه می‌دارد. بخش امنیت RFC 5054 توضیح می‌دهد که سرقت verifier می‌تواند حمله واژه‌نامه‌ای برای حدس گذرواژه را ممکن کند.
پس «گذرواژه روی شبکه فرستاده نمی‌شود» با «هیچ داده مرتبط با گذرواژه برای سرقت وجود ندارد» فرق دارد. گذرواژه یکتا و قوی، حفاظت دستگاه و پاسخ مناسب به حادثه همچنان لازم‌اند. SRP نیز جای رمزنگاری محتوا یا حفاظت نشست ورود را نمی‌گیرد.
در مورد لیوارا چه مرزهایی اعلام شده است؟
سند امنیت لیوارا برای پیام‌های مستقیم LVR1 و برای گروه‌های محافظت‌شده LGS1 را توصیف می‌کند. حفاظت گروه به وضعیت واقعی آن بستگی دارد؛ گروه ناسازگار قدیمی نباید برچسب E2EE بگیرد. کانال‌های عمومی خارج از این مرز محرمانگی‌اند.
همان سند، بازیابی v7 را بسته رمزنگاری‌شده هویت معرفی می‌کند که پیش از بارگذاری محافظت می‌شود. این فرایند هویت رمزنگاری را برمی‌گرداند، نه تاریخچه چت را. افشای عبارت بازیابی یا دستگاهی که کلیدها را در اختیار دارد، سناریویی متفاوت از سرقت صرف پایگاه داده است.
این‌ها توضیحات منتشرشده محصول‌اند، نه نتیجه ممیزی مستقل این مقاله. نام‌بردن از AES یا ML-KEM نیز به‌تنهایی درستی مدیریت کلید و اجرای برنامه را ثابت نمی‌کند.
هنگام اعلام حادثه چه سؤال‌هایی بپرسیم؟
۱. چه بازه زمانی و کدام سامانه‌ها درگیر بوده‌اند؟ عبارت مبهم «اطلاعات کاربران» کافی نیست.
۲. آیا متن آشکار، فایل، کلید، verifier، نشست ورود یا فقط متن رمز در دسترس بوده است؟
۳. آیا مهاجم امکان تغییر سرویس یا نرم‌افزار تحویلی به کاربران را داشته است؟
۴. چه اقدام‌هایی از مسیر رسمی لازم است: خروج نشست‌ها، تغییر گذرواژه، به‌روزرسانی یا بررسی هویت مخاطب؟
۵. آیا توصیه بازیابی ممکن است تاریخچه محلی را از بین ببرد؟ پیش از حذف برنامه، محدودیت‌ها را بخوانید.
از لینک پیام ناشناس برای «تأیید فوری حساب» استفاده نکنید. اطلاعیه را از نشانی رسمی مستقلاً باز کنید. مدل تهدید لیوارا برای فهم مرزهای عمومی مفید است؛ دامنه یک حادثه واقعی باید با شواهد همان حادثه مشخص شود.
