Passkeyها به پذیرش گسترده رسیدند — پایان رمزهای عبور چه شکلی است؟

Passkey دیگر یک ویژگی آزمایشی در تنظیمات توسعهدهندگان نیست. از سال ۲۰۲۵، بیش از ۱۵ میلیارد حساب کاربری در پلتفرمهای اپل، گوگل و مایکروسافت مجهز به Passkey شدهاند و سرویسهای بزرگ مصرفکننده — از PayPal گرفته تا GitHub و Amazon — احراز هویت مبتنی بر WebAuthn را به کار گرفتهاند. صنعت از مرحله پذیرش اولیه به زیرساخت جریان اصلی عبور کرده است.
چرا رمزهای عبور شکست خوردند
مخالفت با رمزهای عبور نظری نیست. گزارش تحقیقات نقض داده Verizon در سال ۲۰۲۴ نشان داد که ۷۷٪ از نقضهای برنامههای وب به دلیل اعتبارنامههای دزدیدهشده یا ضعیف بوده است. وبسایت Have I Been Pwned بیش از ۱۴ میلیارد حساب در معرض خطر را از نقضهای شناختهشده فهرست کرده است. مدیران رمز عبور کمک میکنند — اما آنها در برابر رمزهای عبور ضعیف محافظت میکنند، نه فیشینگ. یک صفحه ورود جعلی قانعکننده همچنان هر چیزی را که کاربر تایپ میکند ضبط میکند، صرفنظر از اینکه رمز عبور چقدر قوی باشد.
Credential stuffing — گرفتن جفتهای نام کاربری/رمز عبور از نقضها و امتحان آنها در سایر سرویسها — دقیقاً به این دلیل کار میکند که کاربران رمزهای عبور را تکرار میکنند. فیشینگ کار میکند زیرا کاربران نمیتوانند با اطمینان صفحات ورود واقعی را از صفحات جعلی تشخیص دهند. اینها مشکلات ساختاری در احراز هویت با رمز مشترک هستند، نه مشکلاتی که با آموزش بهتر کاربر قابل رفع باشند.
Passkey واقعاً چگونه کار میکند
یک Passkey یک جفت کلید رمزنگاری است که روی دستگاه شما تولید میشود. کلید خصوصی هرگز دستگاه را ترک نمیکند — در Secure Enclave دستگاه، TPM یا یک عنصر امنیتی سختافزاری ذخیره میشود. کلید عمومی در سرویس ثبت میشود و روی سرورهای آنها ذخیره میشود. این تفاوت اساسی با رمزهای عبور است: سرور هرگز یک راز را نگهداری نمیکند.
ثبت
زمانی که برای یک سایت Passkey ایجاد میکنید، دستگاه شما یک جفت کلید منحصربهفرد برای آن سایت تولید میکند. کلید عمومی به سرور ارسال و با حساب شما مرتبط میشود. کلید خصوصی با روش احراز هویت دستگاه شما — بیومتریک (Face ID، Touch ID، Windows Hello)، PIN یا الگو — محافظت و در فضای ذخیرهسازی امن پشتیبانیشده با سختافزار ذخیره میشود.
احراز هویت
هنگام ورود، سرور یک چالش رمزنگاری — یک nonce تصادفی — ارسال میکند. Authenticator شما (Secure Enclave یا TPM دستگاه) آن چالش را با کلید خصوصی امضا میکند، پس از تأیید حضور شما از طریق بیومتریک یا PIN. سرور امضا را در برابر کلید عمومی ذخیرهشده تأیید میکند. هیچ رمز عبوری از طریق شبکه ارسال نمیشود. هیچ راز مشترکی قابل فیشینگ نیست. حتی اگر یک مهاجم چالش امضا شده را رهگیری کند، قابل استفاده مجدد نیست — nonce یکبار مصرف است و به آن دامنه مبدأ خاص محدود میشود که حملات تکرار و فیشینگ جاعل دامنه را خنثی میکند.
اتصال به دامنه مبدأ دقیق همان چیزی است که Passkey را به طور ذاتی در برابر فیشینگ مقاوم میکند. یک صفحه جعلی paypa1.com نمیتواند احراز هویت معتبر Passkey برای paypal.com دریافت کند. مرورگر این را در سطح پروتکل از طریق استاندارد WebAuthn که توسط FIDO Alliance به عنوان FIDO2 رسمیت یافته، اعمال میکند.
Passkey امروز در کجا مستقر شده است
پشتیبانی در سطح پلتفرم اکنون جامع است:
- Apple: iCloud Keychain از طریق همگامسازی iCloud رمزگذاریشده سرتاسر، Passkey را در iPhone، iPad و Mac همگام میکند. پشتیبانی در iOS 16+ و macOS Ventura+.
- Google: Google Password Manager Passkey را در دستگاههای Android و Chrome در Windows/macOS همگام میکند. حسابهای Google خود از ورود با Passkey پشتیبانی میکنند — بیش از ۸۰۰ میلیون حساب Google تا سال ۲۰۲۴ از Passkey استفاده کردهاند.
- Microsoft: Windows Hello (PIN مبتنی بر TPM، اثر انگشت یا تشخیص چهره) Passkey را در Windows 11 مدیریت میکند. حسابهای Microsoft از احراز هویت Passkey پشتیبانی میکنند.
- مدیران شخص ثالث: 1Password، Dashlane و Bitwarden همگی از ذخیرهسازی Passkey پشتیبانی میکنند و قابلیت حمل Passkey را در میان پلتفرمهای خارج از اکوسیستمهای بومی فراهم میکنند.
در سمت سرویس، استقرارهای عمده عبارتند از:
- Google — ورود با Passkey برای تمام حسابهای Google Workspace و مصرفکننده
- Apple — پشتیبانی از Passkey برای Apple ID در تمام سرویسهای Apple
- GitHub — Passkey به عنوان روش احراز هویت اصلی از سال ۲۰۲۳
- PayPal — عرضه Passkey برای کاربران ایالات متحده، گسترش بینالمللی
- Amazon — پشتیبانی از Passkey برای حسابهای مصرفکننده
- Best Buy, Target, CVS, Shopify — پذیرش Passkey در خردهفروشی مصرفکننده شتاب گرفته است
- DocuSign, Kayak, Robinhood, Zoho — پذیرندگان SaaS و فینتک با استقرار فعال
FIDO Alliance گزارش داد که بیش از ۱۲ میلیارد حساب آنلاین تا اواخر ۲۰۲۴ آماده Passkey هستند و این تعداد با تکمیل عرضه توسط سرویسهای بیشتر در حال رشد است.
نقاط اصطکاک باقیمانده
پذیرش واقعی است، اما انتقال بدون اصطکاک نیست.
همگامسازی بینپلتفرمی
بزرگترین محدودیت عملی، قفل شدن در اکوسیستم است. یک Passkey ایجاد شده در Apple Keychain به طور خودکار در Google Password Manager ظاهر نمیشود. کاربری که از iPhone به Android تغییر میدهد باید Passkey را در هر سرویس دوباره ثبت کند. مشخصات Cross-Device Authentication (CDA) از FIDO Alliance و کار در دست اجرا روی واردات/صادرات Passkey — که در اصل در سال ۲۰۲۴ تصویب شد — باید این موضوع را حل کند، اما پیادهسازیها تا اواسط ۲۰۲۵ هنوز در حال عرضه هستند.
استقرار MDM سازمانی
در محیطهای سازمانی، Passkeyهای متصل به دستگاههای شخصی چالشهای خطمشی ایجاد میکنند. اگر iPhone شخصی یک کارمند حاوی Passkey یک سرویس شرکتی باشد، وقتی آن کارمند شرکت را ترک میکند چه میشود؟ استقرار Passkey در سطح سازمانی نیازمند یکپارچهسازی MDM، کلیدهای امنیتی سختافزاری (YubiKey، Google Titan) برای ایستگاههای کاری اشتراکی و پشتیبانی از تأمینکننده هویت (IdP) است — Okta، Microsoft Entra ID و Ping Identity اکنون پشتیبانی از Passkey را ارائه میدهند، اما استقرارهای سازمانی پیچیده هستند. جایگزینی کامل جریانهای رمز عبور LDAP/Active Directory نیازمند برنامهریزی چندساله است.
بازیابی حساب
Passkey مشکل بازیابی را تغییر میدهد تا اینکه آن را حذف کند. اگر کاربر همه دستگاههای ثبتشده را از دست بدهد و یک Passkey پشتیبان ثبت نکرده باشد، بازیابی حساب به تأیید ایمیل، تیکتهای پشتیبانی یا کدهای پشتیبان بازمیگردد — همه حلقههای ضعیفتر. سرویسها در حال پیادهسازی ثبت چندگانه Passkey (ثبت در هر دو تلفن و لپتاپ) و گزینههای پشتیبانگیری بینپلتفرمی هستند، اما آموزش کاربران برای ثبت چندین authenticator از استقرار عقبتر است.
مهاجرت سیستمهای قدیمی
شرکتهایی که روی سیستمهای داخلی (On-Premises) اجرا میشوند — VPNهای قدیمی، سیستمهای ERP، احراز هویت mainframe — با جدول زمانی مهاجرت چندساله روبرو هستند. احراز هویت مبتنی بر رمز عبور عمیقاً در پیکربندیهای SSO و ابزارهای داخلی ریشه دارد. به طور واقعبینانه، محیطهای ترکیبی (Passkey برای سرویسهای جدید، رمز عبور + MFA برای سیستمهای قدیمی) تا سالهای ۲۰۲۷-۲۰۲۸ هنجار خواهند بود.
اکنون چه باید کرد
برای افراد
- Passkey را در هر سرویسی که از آنها پشتیبانی میکند فعال کنید — با حساب Google، Apple ID و GitHub خود شروع کنید. اینها باارزشترین اهداف شما برای مهاجمان هستند.
- یک Passkey را در حداقل دو دستگاه برای هر سرویس حیاتی ثبت کنید (تلفن + لپتاپ) تا از سناریوهای قفل شدن جلوگیری کنید.
- اگر مدیر رمز عبور شما از Passkey پشتیبانی میکند (1Password، Bitwarden)، آنها را برای قابلیت حمل بینپلتفرمی در آنجا ذخیره کنید.
- برای سرویسهایی که هنوز از Passkey پشتیبانی نمیکنند، از 2FA با یک برنامه Authenticator استفاده کنید — نه SMS.
برای تیمهای سازمانی و امنیت IT
- هماکنون پشتیبانی IdP خود را از Passkey حسابرسی کنید. Okta، Microsoft Entra، Duo و Ping همگی قابلیتهای Passkey دارند — تأیید کنید که پیکربندی فعلی شما آنها را در اختیار کاربران قرار میدهد.
- در سال ۲۰۲۵، Passkey را برای MFA مقاوم به فیشینگ آزمایش کنید. با نقشهای پرخطر شروع کنید: مدیران IT، امور مالی، مدیران ارشد. این حسابها در کمپینهای فیشینگ اولین اهداف هستند.
- برای دستگاههای اشتراکی یا مدیریتنشده، خطمشی کلید امنیتی سختافزاری تعیین کنید. سری YubiKey 5 و کلیدهای Google Titan از FIDO2 پشتیبانی میکنند و قابلیت Passkey را بدون نیاز به دستگاه شخصی فراهم میکنند.
- نقشه راه مهاجرت سیستمهای قدیمی خود را برای ۲۰۲۶-۲۰۲۷ تهیه کنید. فهرست کنید کدام سیستمهای داخلی از SAML/OIDC پشتیبانی میکنند — آنها میتوانند از طریق IdP برای پشتیبانی از Passkey بهروز شوند — و کدام یک نیاز به ارتقاء سطح پروتکل یا جایگزینی دارند.
- راهنمای واکنش به حادثه خود را بهروز کنید. Passkey بردارهای Password-Spray و فیشینگ را حذف میکند، اما به خطر افتادن دستگاه به سطح حمله جدید تبدیل میشود. اطمینان حاصل کنید که MDM میتواند دستگاههای قابلیت Passkey را از راه دور ابطال کند.
رمز عبور هنوز نمرده است — برای سالها در استقرارهای ترکیبی در کنار Passkey وجود خواهد داشت. اما زیرساخت احراز هویت زیربنای سرویسهای مصرفکننده اینترنت واقعاً تغییر کرده است. سوال برای تیمهای امنیتی دیگر این نیست که آیا Passkey را بپذیرند یا نه، بلکه این است که مهاجرت با چه سرعتی میتواند بدون شکستن سیستمهای قدیمی یا قفل کردن کاربران پیش برود. ابزارها آماده هستند. جدول زمانی اکنون است.