مربع های خاکستری در جایی که باید لوگوی یک برند باشد هشداردهنده به نظر می رسند، و با این حال همان چیز اشتباهی هستند که نباید بر اساس آن اقدام کرد. تصویری که یک تأییدکننده می کشد جزئیاتی نمایشی است که از برچسب های موجود در ورودی گرفته شده، در حالی که پرسش امنیتی این است که آیا راز درون آن ورودی به حساب شما تعلق دارد. جدا نگه داشتن این دو، همان چیزی است که یک تعمیر ظاهری را از یک حادثه اعتبارنامه جدا می کند. همچنین مانع تعمیری می شود که اوضاع را بدتر می کند.

آیکون و راز به پرسش های متفاوتی پاسخ می دهند

یک ورودی تأییدکننده از یک URI کلید ساخته می شود که رازی مشترک را همراه با برچسب حساب و نام صادرکننده حمل می کند. برنامه از صادرکننده ای که می شناسد لوگو می سازد، و صادرکننده ناشناخته یا تغییرکرده صرفاً یک تصویر عمومی تولید می کند. هیچ چیز در آن نمایش به شما نمی گوید چه کس دیگری نسخه ای از راز دارد، و هیچ چیز در یک لوگوی درست به شما نمی گوید که ورودی فقط از آن شماست. نمایش را نشانه ای درباره یک برچسب بخوانید، نه بیانیه ای درباره نگهداری.

عکس آن هم درست است، و آن جهت خطرناک تر است. یک لوگوی قانع کننده حتی کمتر از یک لوگوی غایب اثبات می کند.

ObservationWhat it supportsWhat it cannot support
Logo missing or wrongThe issuer string was not recognisedAny conclusion about secret disclosure
Logo correctThe issuer string matched a known nameAny conclusion about who else enrolled
Codes rejected by the serviceA real mismatch between entry and accountWhich of the two changed

هرگز برای درست کردن یک تصویر دوباره ثبت نام نکنید

تعمیری که در اینترنت می چرخد بازتولید کد QR است، یعنی صادر کردن راز و عبور دادن آن از ابزار دیگر. این کار یک مشکل نمایشی را به افشا تبدیل می کند، زیرا فایل صادرشده دقیقاً همان موادی را دارد که مهاجم برای ساختن کدهای معتبر لازم دارد. بارگذاری آن در یک مولد وب، عامل دوم را در ازای یک آیکون قشنگ تر به شخص ثالث می سپارد.

اگر حساب همچنان کدها را تأیید می کند، ثبت نام سالم است و نمایش ظاهری است. مستندات خود تأییدکننده را درباره برچسب های صادرکننده و جست وجوی آیکون ببینید و ورودی را به حال خود بگذارید. ویرایش برچسب برای تحمیل یک لوگو تغییری در ورودی است به دلیلی که هیچ ارتباطی با احراز هویت ندارد.

تصویر اصلی QR، URI خام کلید و هر راز دستی را از تیکت ها، رشته های گفتگو، تصاویر صفحه و ردیاب های عمومی مشکلات دور نگه دارید. تصویر یک صفحه راه اندازی اغلب بیش از آنچه عکاس قصد داشته در خود دارد.

وقتی راز واقعاً افشا شد

افشا را حادثه ای جداگانه با پاسخ خودش بدانید. از فرایند جایگزینی پشتیبانی شده سرویس برای ثبت یک تأییدکننده جدید استفاده کنید، تأیید کنید که ورودی جدید کدهای پذیرفته شده تولید می کند و ثبت قدیمی را روی سرور بازنشسته کنید. حذف ورودی به صورت محلی ثبت سمت سرور را برنمی دارد، بنابراین راز افشاشده می تواند تا زمانی که به سرویس اطلاع داده نشود به کار خود ادامه دهد. بیشتر ریسک در همین شکاف میان حذف محلی و وضعیت سرور است.

ترتیب اینجا مهم است. ابتدا جایگزین را ثبت کنید، آن را بررسی کنید و تنها پس از آن قدیمی را بردارید، زیرا بیشتر سرویس ها اگر آخرین عامل ناپدید شود شما را قفل می کنند. کدهای بازیابی هم به همین ترتیب تعلق دارند، چون وقتی تلفن در دسترس نیست آن ها مسیر جایگزین اند.

بررسی کنید آیا همان راز جای دیگری استفاده شده است. URI کلیدی که در یک مولد چسبانده شده از کنترل شما خارج شده است و حساب پشت آن باید تا جایگزینی ثبت، مشترک تلقی شود.

درخواست های پشتیبانی باید مشکل بصری را بدون کد یا مواد راه اندازی توصیف کنند. هر چیزی که به حساب مربوط است جای آن در کانال تأییدشده ارائه دهنده است، نه در یک رشته عمومی.

پیش از حذف یک مسیر بازیابی نگه دارید

پیش از برداشتن هر ورودی کارآمد، تأیید کنید که مسیر بازیابی تأییدشده ای وجود دارد و می توانید از آن استفاده کنید. تعمیر ظاهری که به قفل شدن ختم شود نتیجه ای بدتر از لوگوی اشتباه است، و قفل شدن زمانی رایج است که تنها دستگاه ثبت شده همان دستگاهی باشد که ویرایش می شود.

شرط پذیرش باریک است: رابطه ای تأییدشده میان حساب و تأییدکننده، با نگه داشتن خصوصی مواد ثبت نام. یک نشان آشنا بخشی از آن شرط نیست، و نبودش دلیلی بر نفوذ نیست.

قالب URI کلید خود در مشخصات URI کلید Google Authenticator مستند شده است، که همچنین یادآوری می کند محتوا راز دارد نه لوگو. پیش از صادر کردن چیزی از ورودی ای که توان از دست دادنش را ندارید، آن را بخوانید.

مقالات مرتبط