Passkey یا اپ احراز هویت؛ فقط یکی در برابر فیشینگ طراحی شده است

اگر منظور از اپ احراز هویت، برنامه‌ای باشد که کد TOTP می‌سازد، گذرکلید در برابر فیشینگ امن‌تر است: پاسخ ورود آن به دامنهٔ واقعی سرویس گره می‌خورد، اما کد تایپ‌شدنی را می‌توان از صفحهٔ جعلی به ورود واقعی منتقل کرد. راهنمای NIST دربارهٔ احراز هویت ورود دستی رمز یک‌بارمصرف را به همین علت مقاوم در برابر فیشینگ نمی‌داند.

این برتری به مرحلهٔ ورود مربوط است، نه به همهٔ راه‌های دسترسی به حساب. گذرکلید همگام‌شده به حساب ارائه‌دهنده و فرایند بازیابی آن وابسته می‌شود؛ کلید سخت‌افزاری چنین مسیر همگام‌سازی‌ای ندارد، ولی گم‌شدن تنها کلید ثبت‌شده می‌تواند دسترسی را قطع کند. TOTP هم در سرویسی که گذرکلید را نمی‌پذیرد، همچنان عامل دوم مفیدی در کنار گذرواژه است.

چرا صفحهٔ جعلی کد را می‌گیرد، اما گذرکلید را نه؟

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

در ورود با گذرکلید، ابزار احراز هویت برای حساب، کلید رمزنگاری مربوط به همان سرویس را نگه می‌دارد و به درخواست ورود پاسخ امضاشده می‌دهد؛ کلید خصوصی به فرم وب تحویل داده نمی‌شود. توضیح FIDO Alliance دربارهٔ گذرکلید روشن می‌کند که این اعتبارنامه می‌تواند همگام‌شده یا وابسته به یک دستگاه، از جمله کلید امنیتی، باشد. در هر دو حالت، مرورگر یا برنامهٔ مورداعتماد دامنه را در فرایند احراز هویت وارد می‌کند؛ صفحه‌ای با دامنهٔ جعلی نمی‌تواند همان پاسخ معتبر را برای سرویس اصلی بگیرد. این ویژگی به سالم بودن مرورگر و دستگاه نیز وابسته است.

گم‌شدن دستگاه با سرقت آن چه فرقی دارد؟

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

برای TOTP، پاسخ به محل نگهداری راز اولیه بستگی دارد. اگر کدها فقط روی تلفن گم‌شده بوده‌اند و نسخهٔ دیگری از آن‌ها وجود ندارد، نصب دوبارهٔ همان اپ به‌خودی‌خود دسترسی را برنمی‌گرداند؛ کاربر به روش پشتیبان یا بازیابی هر سرویس نیاز دارد. اپی که کدها را همگام می‌کند، دسترسی پس از فقدان تلفن را آسان‌تر می‌سازد، اما حفاظت از حساب همگام‌سازی نیز اهمیت پیدا می‌کند.

سرقت دستگاه تهدید متفاوتی است: کسی که بتواند قفل ضعیف تلفن را باز کند ممکن است از گذرکلیدهای قابل‌استفاده روی آن یا کدهای اپ بهره ببرد. برای کلید سخت‌افزاری نیز باید دید استفاده از آن به PIN یا تأیید دیگری نیاز دارد یا نه. مقاومت گذرکلید در برابر صفحهٔ جعلی، جای حفاظت از خود دستگاه و امکان حذف اعتبارنامهٔ گم‌شده از حساب سرویس را نمی‌گیرد.

همگام‌سازی کدام خطر را جابه‌جا می‌کند؟

همگام‌سازی فقدان یک دستگاه را کمتر به بحران دسترسی تبدیل می‌کند، اما حساب ارائه‌دهنده را به بخشی از زنجیرهٔ امنیت بدل می‌سازد. تحلیل NCSC دربارهٔ اعتبارنامه‌های FIDO2 توضیح می‌دهد که حفاظت حساب همگام‌سازی و مسیر بازیابی آن در امنیت گذرکلید مؤثرند. اگر مهاجم بتواند از این مسیر به اعتبارنامه‌ها روی دستگاهی تازه دسترسی بگیرد، اتصال گذرکلید به دامنهٔ سایت مقصد آن تصاحب را جبران نمی‌کند؛ تحقق این سناریو به تدابیر همان ارائه‌دهنده وابسته است.

این وابستگی مخصوص گذرکلید نیست. راهنمای Google Authenticator می‌گوید کدها با ورود به حساب Google میان دستگاه‌ها همگام می‌شوند، و استفادهٔ بدون آن حساب و انتقال دستی کدها هم ممکن است. در حالت محلی، از دست رفتن تلفن بدون انتقال قبلی می‌تواند کاربر را به بازیابی تک‌تک حساب‌ها بکشاند؛ در حالت همگام‌شده، حفاظت از حساب Google نیز در امنیت کدها نقش دارد.

کلید سخت‌افزاری FIDO2 انتخاب دیگری است: اعتبارنامهٔ وابسته به آن در حساب همگام‌سازی کپی نمی‌شود و برای استفاده، خود کلید باید در دسترس باشد. این استقلال برای حساب حساس ارزش دارد، اما نگهداری فیزیکی کلید و ثبت ابزار جایگزین را مهم‌تر می‌کند. تعویض تلفن یا مهاجرت میان ارائه‌دهندگان برای گذرکلید همگام‌شده نیز به امکان دسترسی به ارائه‌دهنده یا ثبت اعتبارنامهٔ تازه در سرویس وابسته است.

مسیر بازیابی چگونه نتیجه را عوض می‌کند؟

بازگرداندن اعتبارنامه با بازگرداندن خود حساب یک کار نیست. در اولی، نسخهٔ همگام‌شدهٔ گذرکلید یا کدهای اپ روی دستگاه دیگری در دسترس قرار می‌گیرد؛ در دومی، سایت مقصد باید هویت صاحب حساب را از راه دیگری بپذیرد و ابزار تازه‌ای ثبت کند. برای اعتبارنامهٔ وابسته به کلید سخت‌افزاری، داشتن کلید پشتیبانِ ثبت‌شده می‌تواند نیاز به مسیر دوم را کاهش دهد.

راه جایگزین ممکن است امنیت ورود اصلی را دور بزند. اگر سایتی در کنار گذرکلید ورود با گذرواژه و TOTP را باز بگذارد، مهاجم می‌تواند همان مسیر قابل فیشینگ را هدف بگیرد. اگر بازیابی فقط به پیوندی در ایمیل تکیه کند، امنیت حساب ایمیل نیز برای حساب مقصد مهم می‌شود. بنابراین ارزیابی گذرکلید یا TOTP بدون دانستن اینکه سرویس چگونه ابزار تازه ثبت می‌کند و دسترسی ازدست‌رفته را برمی‌گرداند، ناقص است.

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

در هر وضعیت کدام انتخاب منطقی‌تر است؟

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

برای حسابی با حساسیت بیشتر، یا زمانی که خروج اعتبارنامه از یک ابزار قابل‌قبول نیست، کلید سخت‌افزاری FIDO2 همراه با PIN و یک کلید پشتیبانِ ثبت‌شده انتخاب سنجیده‌تری است؛ البته سرویس باید این نوع ورود را پشتیبانی کند. این آرایش همان مزیت ضد فیشینگ را دارد و مسیر تصاحب حساب همگام‌سازی را برای آن اعتبارنامه حذف می‌کند. در عوض، هزینهٔ تهیه و نگهداری ابزار و احتمال نیاز به بازیابی در صورت فقدان هر دو کلید باقی می‌ماند.

وقتی گذرکلید در دسترس نیست، گذرواژهٔ منحصربه‌فرد به‌همراه TOTP از گذرواژهٔ تنها دفاع بهتری می‌سازد، هرچند کد همچنان قابل فیشینگ است. نگهداری محلی TOTP می‌تواند برای کسی که نمی‌خواهد رازهای ورودش به حساب همگام‌سازی وابسته باشند عملی‌تر باشد، به شرط آنکه از پیش راهی برای فقدان تلفن داشته باشد. این انتخاب باید با امکانات واقعی همان سرویس سنجیده شود، نه با نام اپ یا اعتبارنامه به‌تنهایی.

بیشتر بخوانید:

• GraphRAG یا Vector RAG؛ گراف فقط در پرسش‌های چندمرحله‌ای جلو می‌افتد
• Codex یا Claude Code؛ سرعت بیشتر در برابر کنترل مجوزها
• تأیید انسانی برای عامل‌ها بسازید؛ توقف را فقط پیش از کار پرخطر بگذارید