کمکم کلیدهای عبور را سازوکاری میدیدم که مهاجم نمیتواند با فریب از من بگیرد. چیزی نبود که بتوان آن را در یک صفحهٔ جعلیِ ورود حدس زد، چیزی نبود که یک بستهٔ فیشینگ بتواند دوباره از آن بهرهبرداری کند، و خودِ کلید عبور هم رازِ مشترکِ قابلاستفادهٔ دوبارهای را روی سرورِ هیچ شرکتی باقی نمیگذاشت که منتظرِ رخنهٔ بعدی بماند. قرار بود کلید خصوصی فقط در سمتِ منِ ماجرا بماند و همین، این سازوکار را برایم تقریباً نفوذناپذیر جلوه میداد.
این تصویر ذهنی تا وقتی پابرجا بود که شروع کردم بفهمم با همگامشدنِ کلیدهای عبور میان دستگاهها چه چیزهایی تغییر میکند. در ذهنم، مقاومت در برابر فیشینگ و مقاومت در برابر سرقت را یکی گرفته بودم، اما معلوم شد این دو، دو وعدهٔ امنیتیِ جدا از هم هستند.
کلیدهای عبور دربارهٔ فیشینگ به من دروغ نمیگفتند
فیشینگ هنوز هم به دیوارِ سختِ رمزنگاری میخورد
بخشِ مربوط به فیشینگ در مدلِ ذهنیام همچنان درست از آب درمیآید. کلید عبور از یک جفتِ کلیدِ عمومی و خصوصی استفاده میکند. سرویس، کلیدِ عمومی را نگه میدارد و احرازگرِ شما کلیدِ خصوصی را در اختیار دارد و هر بار که وارد میشوید، با همان کلید یک چالشِ تازه را امضا میکند. وباوتن هم این اعتبارنامه را به دامنهٔ معتبرِ طرفِ اتکا گره میزند، بنابراین یک سایتِ شبیهِ واقعی نمیتواند صرفاً کلید عبور شما را جمع کند و جای دیگری دوباره از آن استفاده کند.
همین ویژگی، چند راهِ آشنای دزدیدهشدنِ اعتبارنامهها را از میان برمیدارد. گذرواژهها و کدهای یکبارمصرف هنوز هم اگر فریب بخورم و آنها را در سایتِ اشتباه تایپ کنم، ممکن است سر از همانجا درآورند؛ در حالی که نشتِ پایگاهدادهٔ یک سرویس، برای مهاجم فقط نیمهٔ عمومیِ اعتبارنامهٔ کلیدِ عبورِ من را بهجا میگذارد، نه یک رازِ مشترکِ قابلاستفادهٔ دوباره.
ماجرا وقتی پیچیدهتر میشود که ببینیم نیمهٔ خصوصی کجا نگهداری میشود. کلیدهای عبورِ وابسته به دستگاه فقط نزدِ یک احرازگر میمانند و به جای دیگری کپی نمیشوند. کلیدهای عبورِ همگامشده، بخشی از آن جداسازی را با قابلحملبودن معامله میکنند. ذخیرهکردنِ کلیدهای عبور در یک مدیرِ گذرواژه میتواند آنها را میان دستگاههای پشتیبانیشده در دسترس بگذارد، و استانداردهای تازهتر هم جابهجاییِ کلیدهای عبور میان مدیرانِ گذرواژه را ممکن کردهاند.
مدیرِ گذرواژهٔ گوگل از همان مدلِ گستردهترِ همگامسازی پیروی میکند؛ موادِ مربوط به اعتبارنامه را رمزگذاریشده نگه میدارد، اما آنها را میان دستگاههای پشتیبانیشده در دسترس میگذارد. من این چیدمان را دوست دارم، چون عوضکردنِ تلفن را به یک ماراتنِ بازیابیِ حساب تبدیل نمیکند؛ با این حال، جابهجاییِ یک اعتبارنامه میان دستگاهها ناگزیر یعنی زیرساختِ بیشتری هم درگیر میشود.
همگامسازی، مسیرهای بیشتری برای دستبردن در اختیارِ مهاجم میگذارد
وقتی پایِ بازیابی وسط میآید، قصه پیچیدهتر میشود
همین قابلحملبودن، مدیرِ اعتبارنامه، مرورگر، ثبتِ دستگاه، بازیابیِ حساب و زیرساختِ همگامسازی را هم واردِ تصویرِ امنیتی میکند. بازیابیِ کلید عبور خطرهای خودش را دارد، و به همین دلیل مؤسسهٔ ملیِ استانداردها و فناوریِ آمریکا، سامانههای پیرامونِ اعتبارنامههای همگامشده را بخشی از مدلِ تهدید میداند.
در راهنمای کنونیِ مؤسسهٔ ملیِ استانداردها و فناوریِ آمریکا هم این نکته لحاظ شده است. احرازگرهای همگامپذیر، اگر درست پیکربندی شده باشند، هنوز هم میتوانند در برابرِ فیشینگ مقاومت کنند و از سطحِ تضمینِ احرازِ هویت ۲ پشتیبانی کنند؛ اما خودِ همگامسازی ناگزیر میطلبد که کلیدهای احراز هویت قابلِ صدور باشند، و همین باعث میشود نتوانند شرطِ غیرقابلصدوربودنِ سطحِ تضمینِ احرازِ هویت ۳ را برآورده کنند.
پژوهشِ «پَس دِ پسکی» از یونیت ۴۲ در اوتِ ۲۰۲۶، تصورِ این خطرِ عملی را برایم خیلی آسانتر کرد. پژوهشگران بهطور خاص روی مدیرِ گذرواژهٔ گوگل از طریقِ کروم روی رایانههای ویندوزیِ مجهز به تیپیام تمرکز کرده بودند، و هر حملهای که نشان دادند با بدافزاری آغاز میشد که از پیش روی رایانهٔ قربانی در حال اجرا بود. این پیششرط مهم است، چون بدافزارِ هدفگرفتهشده علیه اعتبارنامههای ذخیرهشده در مرورگر میتواند به موادی دست پیدا کند که ظاهراً خوب محافظت شدهاند، تا وقتی که مرورگر فرض میکند ماشینِ زیرِ پایش قابلاعتماد است.
پَستاکی از سازوکارِ هویتِ دستگاهیِ کروم سوءاستفاده کرد تا یک گواهِ احراز هویتِ از نظرِ رمزنگاری معتبر به دست آورد، بیآنکه تعاملِ معمولِ مورد انتظار از کاربر انجام شده باشد. گیتهاب تلاشِ یونیت ۴۲ را رد کرد، چون راستیآزماییِ کاربر برآورده نشده بود؛ در حالی که ایبی پیش از اصلاحِ اعتبارسنجیِ خود آن را پذیرفت. پَستاکی نقرهای یک گام فراتر رفت و با سوءاستفاده از دوبارهپیوستنِ دستگاه، یک کلیدِ راستیآزماییِ تحت کنترلِ مهاجم را ثبت کرد که بعدتر میشد از محیطی دیگر با آن احراز هویت کرد.
آن دو حمله، بیآنکه خودِ کلیدهای خصوصیِ کلیدِ عبورِ همگامشده را بیرون بکشند، از سازوکارهای پیرامونِ احراز هویت سوءاستفاده کردند. «پَستاکی طلایی» جایی است که این پژوهش به چیزی بسیار نزدیکتر میشود که من معمولاً آن را سرقتِ اعتبارنامه میدانم.
پیادهسازی گوگل کلیدهای خصوصیِ گذرکلیدهای همگامشده را با یک رازِ دامنهٔ امنیتیِ ۳۲بایتی، یا اِسدیاِس، محافظت میکند. یونیت ۴۲ دریافت که این راز هنگام ثبتنام، در گزارشهای دستگاه فایدو در کروم بهصورت متنِ ساده دیده میشد. گوگل پس از گزارش پژوهشگران آن نشتِ ثبت را برطرف کرد، اما یونیت ۴۲ نشان داد که اِسدیاِس هنوز به کروم میرسد و هنگام راهاندازی اولیه یا بازیابی، برای مدتی در حافظهٔ فرایند ظاهر میشود. بدافزاری که دستگاه را به اجبار وارد آن فرایند کند میتواند حافظهٔ کروم را تخلیه کند، اِسدیاِس را بهدست آورد و از آن برای رمزگشاییِ کلیدهای خصوصیِ گذرکلیدهای همگامشدهای که برای آن حساب ذخیره شدهاند استفاده کند.
آنچه واقعاً نگاه من را به گذرکلیدهای همگامشده تغییر داد، بعد از دزدیدهشدن اِسدیاِس رخ داد. بهگفتهٔ یونیت ۴۲، یک اِسدیاِسِ سرقتشده میتواند هم گذرکلیدهای موجود و هم گذرکلیدهای آیندهای را که برای همان حساب ساخته میشوند رمزگشایی کند. پژوهشگران همچنین میگویند پیادهسازی کنونی گوگل هیچ راهی برای چرخاندن یا باطلکردن اِسدیاِس ندارد؛ پس پاککردن رایانهٔ آلودهٔ اولیه بهطور خودکار اِسدیاِسی را که پیشتر به دست مهاجم افتاده، بیاعتبار نمیکند.
همچنان باید بر پیشنیازِ بدافزار تأکید کرد، چون این پژوهش گذرکلیدها را به هدفهای آسانِ راهدور تبدیل نمیکند. آنچه توجهم را جلب کرد این بود که یک نقطهٔ پایانیِ آلوده تا کجا میتوانست دست دراز کند، در حالی که رمزنگاریِ زیربنایی دقیقاً همانطور که طراحی شده بود کار میکرد.
هنوز از گذرکلیدها استفاده میکنم، فقط با توهم کمتر
گذرکلیدها را نگه میدارم و هالهٔ قدسی را کنار میگذارم
اکنون مرورگر، سیستمعامل، مدیر گذرواژه و فرایند بازیابی را بخشی از سازوکار گذرکلید میدانم؛ و همین، دلیل دیگری به من میدهد تا کروم را بهروز نگه دارم، پیشگیری از بدافزار را جدی بگیرم و وصلههای امنیتی ویندوز را همیشه نصب کنم.
همچنین حواسم را به یک درخواست غیرمنتظرهٔ پینِ بازیابی در مدیر گذرواژهٔ گوگل هم جمع میکنم. یونیت ۴۲ یادآوری میکند که این درخواستها معمولاً به راهاندازی اولیه یا بازیابی حساب مربوطاند؛ بنابراین اگر در استفادهٔ عادی از گذرکلید، یکی از آنها به شکلی غیرعادی یا تکراری ظاهر شود، میتواند نشانهٔ آن باشد که آن فرایند دوباره فعال شده است. این بهخودیخود ثابت نمیکند که حملهای در جریان است، اما من هم سرسری از کنارش نمیگذرم.
برای حسابهایی که برایم مهمترند، ترجیح میدهم کلید احراز هویت به یک دستگاه گره خورده بماند تا اینکه همهجا همراهم بیاید. اگر خدمت از آن پشتیبانی کند، استفاده از کلید امنیتیِ سختافزاری را در نظر میگیرم. این انتخاب فقط وقتی همان جداسازیِ مدنظرم را فراهم میکند که واقعاً به اعتبارنامهٔ وابسته به دستگاه تکیه کنم، نه اینکه یک گذرکلیدِ همگامشده را صرفاً بهعنوان مسیر دیگری برای ورود به حساب نگه دارم؛ و البته وقتی روشهای جایگزین و بازیابیِ حساب هم به همان دقت محافظت شوند.
این یعنی باید جدیتر به احرازکنندههای پشتیبان فکر کنم و کدهای بازیابی حساب را بهطور امن نگه دارم؛ معاملهای که فقط برای حسابهایی میپذیرم که آنقدر ارزش دارند که این اصطکاکِ اضافه را توجیه کنند.
اکنون بیشتر به گذرکلیدها اعتماد دارم، چون کورکورانه به آنها اعتماد نمیکنم
من در ذهنم «مقاوم در برابر فیشینگ» را به تضمینی بسیار گستردهتر از چیزی کشانده بودم که گذرکلیدها هرگز قرار نبود ارائه دهند. هنوز هم در برابر حملههای صفحهٔ ورودِ جعلی که برای شکستدادنشان طراحی شدهاند به آنها اعتماد دارم، اما دیگر آن محافظت را دلیلی نمیدانم بر اینکه خودِ اعتبارنامه هرگز نمیتواند دزدیده شود. رمزنگاری میتواند بینقص پابرجا بماند، در حالی که سازوکار پیرامون یک گذرکلیدِ همگامشده راه دیگری پیش پای مهاجم بگذارد تا به کلید برسد.
منبع: این مطلب ترجمه و بومیسازی مقالهای از MakeUseOf به قلم Oluwademilade Afolabi است. مشاهده مقاله اصلی