چگونه واتساپ با گذرکلیدها به ورود به سیستم ایمن و یکپارچه برای ۱ میلیارد کاربر ارتقا یافت

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

«آنچه بیش‌از همه من را هیجان‌زده می‌کند، مقیاس عظیم تأثیر واتساپ است. مایانک مانوجا، مهندس Android در تیم «ثبت‌نام و دسترسی واتساپ» که طراحی و پیاده‌سازی اصالت‌سنجی مبتنی بر گذرکلید را برای «واتساپ» رهبری کرده است، می‌گوید: «حتی یک بهبود کوچک در واتساپ بر میلیاردها کاربر در سراسر جهان تأثیر می‌گذارد.» 

ساختن برای مخاطبانی با این وسعت مستلزم پیمایش طیف وسیعی از شرایط شبکه، قابلیت‌های دستگاه، و سطوح سواد دیجیتال است. «واتساپ» با تشخیص زودهنگام این پتانسیل، متعهد شد که در سال ۲۰۲۳ گذرکلید را بپذیرد و به یکی از اولین برنامه‌های مصرف‌کننده اصلی تبدیل شد که این فناوری را ادغام کرد. هدف «واتساپ» از پیاده‌سازی گذرکلیدها ارائه گزینه‌ای سریع و مقاوم دربرابر رمزگیری بود که اصطکاک کاربر را به‌طور قابل‌توجهی کاهش دهد و درعین‌حال محافظت قوی دربرابر تصاحب حساب و سرقت اطلاعات کاربری ارائه دهد.   

تصمیم به استفاده از گذرکلید

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

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

داشتن روش‌های دسترسی به حساب قوی و متنوع تضمین می‌کند که کاربران هرگز از آنچه برایشان مهم است محروم نمی‌شوند.

یکپارچه‌سازی سمت کارخواه

از دیدگاه توسعه‌دهنده «واتساپ»، Credential Manager API میانای تمیز و یکپارچه‌ای ارائه می‌دهد که پیچیدگی ارائه‌دهندگان اطلاعات کاربری زیربنایی را پنهان می‌کند. پس‌از ترسیم جریان‌های یکپارچه‌سازی اولیه، سطح میانای برنامه‌سازی کاربردی ساده شد و ایجاد و بازیابی اطلاعات اعتباری از الگوهای درخواست و پاسخ به‌خوبی تعریف‌شده پیروی کرد. راهنمای پیاده‌سازی را در اسناد توسعه‌دهنده Android پیدا کنید. 

درحالی‌که مسیر شاد از ابتدا کار می‌کرد، پیمایش پایگاه کاربر متنوع در OEMها، نسخه‌های متعدد Android، و پیکربندی‌های مختلف دستگاه (مانند فقط پین درمقابل زیست‌سنجشی، یا Android 13 درمقابل 14+) موارد حاشیه‌ای بی‌سابقه‌ای را آشکار کرد. این موارد شامل کاربران بدون قفل صفحه، انواع استثناهای غیرمنتظره، «خدمات Play» قدیمی، و رفتار ناسازگار ارائه‌دهنده اطلاعات کاربری بود.

برای غلبه بر این موانع، تیم‌های «واتساپ» و Google همکاری عمیقی داشتند و با چندین چالش مقابله کردند:

• بهینه‌سازی جریان جستجوی اطلاعات کاربری: جریان جستجوی اولیه تأخیر زیادی داشت، به‌ویژه برای کاربرانی که هنوز گذرکلید ایجاد نکرده بودند. ازآنجایی‌که اکثر کاربران «واتساپ» در مراحل اولیه در این دسته قرار می‌گیرند، این امر باعث تأخیر قابل‌توجهی در تقریباً هر ورود به سیستم می‌شود. با ابزارسازی مسیر تماس و شناسایی گلوگاه‌ها با یکدیگر، «واتساپ» فرایند را به‌طور قابل‌توجهی تسریع کرد و به بهبود عملکردی دست یافت که درنهایت به نفع کل بوم‌سازگان Android بود.
• مدیریت حالت‌های گذرا: «واتساپ» یک لایه مدیریت خطای جامع برای پیمایش موانع خاص دستگاه مانند دردسترس بودن مدیر گذرواژه، پیکربندی نشدن قفل صفحه، مشکلات اتصال متناوب، سخت‌افزار ناسازگار، خدمات Play قدیمی، و دسته‌بندی استثناها به حالت‌های قابل‌بازیابی و نهایی ایجاد کرد. این امر امکان تنزل متین را فراهم کرد، اگر جریان گذرکلید نمی‌توانست تکمیل شود، سیستم به‌طور ایمن به اصالت‌سنجی سنتی بازمی‌گشت بدون اینکه کاربر را در وضعیت خرابی رها کند.
• پیمایش استثناهای مختص سیستم‌عامل: وقتی دورسنجی موانع مختص دستگاه را آشکار کرد، مثل GetPublicKeyCredentialDomException (رمزگشایی اطلاعات کاربری ناموفق بود) در برخی‌از دستگاه‌های Android 13، و CreatePublicKeyCredentialDomException (امکان دریافت حساب همگام‌سازی وجود ندارد) درطول ایجاد گذرکلید در Android 14،‏ Google و تیم WhatsApp علل ریشه‌ای را بررسی کردند و بهبودهایی در سطح پلاتفرم اعمال کردند تا از روان‌تر شدن جریان‌های ایجاد اطمینان حاصل کنند. می‌توانید راهنمای جامع خطا را در اینجا پیدا کنید که کدهای خطا و توضیحات رایج مربوط به Credential Manager را فهرست می‌کند و اطلاعاتی درباره دلایل آن‌ها ارائه می‌دهد. 

بهبود تجربه کاربری

چون گذرکلیدها در اوایل سال ۲۰۲۳ مفهومی کاملاً جدید بودند، هیچ الگوی ثابتی برای درخواست ایجاد آن‌ها وجود نداشت. ‫WhatsApp ازطریق آزمایش A/B گسترده، چارچوبی زمینه‌ای را توسعه داد که کاربرانی را که بیشترین بهره را می‌برند هدف قرار می‌دهد. این استراتژی به‌طور مداوم تکامل یافت: با تکامل جریان‌های سیستم‌عامل Android به یک تجربه ساده و تک‌صفحه‌ای، WhatsApp پیام‌واره‌های خود را ساده کرد تا از میانای کاربر تکراری یا گیج‌کننده جلوگیری کند.

معماری سمت سرور و موانع چندسکویی

در پس‌زمینه، سرور «واتساپ» تشریفات استاندارد WebAuthn/FIDO2 را اجرا می‌کند. بخش پشتیبان به زبان Erlang نوشته شده است و کتابخانه Rust webauthn-rs را ازطریق یک میانای بومی فراخوانی می‌کند. این کتابخانه Rust درستی‌سنجی امضا و تجزیه اطلاعات کاربری را انجام می‌دهد و به کد داخلی اجازه می‌دهد تا بر هماهنگ‌سازی، ذخیره‌سازی، و قوانین محصول مانند واجدشرایط بودن، محدودیت نرخ، و چرخه حیات اطلاعات کاربری متمرکز بماند.

معماری سرور این مراسم‌های اصلی را ازطریق چهار نقطه ورودی اصلی هماهنگ می‌کند که به‌صورت جفت در توالی‌های شروع و پایان برای «ثبت‌نام» و «اصالت‌سنجی» قرار گرفته‌اند:

۱. ثبت گذرکلید

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

Erlang: Begin Registration

begin_registration(UserId) ->
    Existing = list_credentials(UserId),
    %% reuse the existing user handle, or mint a new one
    {UserHandle, IsNew} = user_handle(Existing),
    %% returns the client creation options and the server-side challenge state
    #{client_safe := CreationOptions, server_only := ChallengeState} =
        webauthn:start_registration(UserId, UserHandle, rp_config()),
    %% excludeCredentials: the user's existing credential IDs, so the device won't re-enroll one
    Options = with_exclude_credentials(CreationOptions, credential_ids(Existing)),
    store_challenge(UserId, ChallengeState),          %% short TTL
    IsNew andalso reserve_user_handle(UserId, UserHandle),
    Options.

• شناسایی کاربر: سرور ابتدا وجود اعتبارنامه‌های موجود را بررسی می‌کند تا از نام کاربری موجود دوباره استفاده کند یا نام کاربری جدیدی تولید کند.
• تولید گزینه‌ها و چالش: کتابخانه WebAuthn را برای تولید گزینه‌های ایجاد برای کارخواه و حالت چالش امن برای سرور فراخوانی می‌کند.
• جلوگیری از تکرار: این گزینه به‌طور صریح شناسه‌های اطلاعات کاربری موجود کاربر را مستثنی می‌کند تا دستگاه به‌طور تصادفی گذرکلیدی را که قبلاً ثبت شده است دوباره ثبت نکند.
• ذخیره چالش: سرور به‌طور موقت چالش را با «زمان بقای» (TTL) کوتاه ذخیره می‌کند و گزینه‌ها را به دستگاه مشتری برمی‌گرداند.

Erlang: Finish Registration

finish_registration(UserId, Attestation) ->
    ChallengeState = get_challenge(UserId),          %% must exist and be unexpired
    #{credential_id := CredId, public_key := PubKey} =
        webauthn:finish_registration(Attestation, ChallengeState, rp_config()),
    ok = index_credential(CredId, UserId),            %% map credential_id -> account
    case multi_passkey_enabled(UserId) of
        true  -> add_credential(UserId, CredId, PubKey);      %% append (oldest evicted past the cap)
        false -> replace_credential(UserId, CredId, PubKey)   %% single-passkey mode
    end,
    notify_client(UserId, {passkey_created, CredId}),
    ok.

• بازیابی چالش: سرور چالش ذخیره‌شده را بازیابی می‌کند و مطمئن می‌شود که هنوز وجود دارد و منقضی نشده است.
• درستی‌سنجی گواهی: پاسخ کارخواه (گواهی) و چالش را به کتابخانه WebAuthn ارسال می‌کند تا درخواست را درستی‌سنجی کند و شناسه اطلاعات اعتباری و کلید عمومی جدید را استخراج کند.
• نمایه‌سازی اطلاعات کاربری: شناسه اطلاعات کاربری جدید مستقیماً به حساب کاربر نگاشت می‌شود تا بعداً به‌سرعت جستجو شود.
• ذخیره و مدیریت محدودیت‌ها: بسته به اینکه ویژگی چندگذرکلیدی فعال باشد یا نه، سرور یا اطلاعات کاربری جدید را به فهرست کاربر اضافه می‌کند (اگر به سقف رسیده باشد، قدیمی‌ترین را حذف می‌کند) یا اطلاعات کاربری موجود را در حالت تک‌گذرکلیدی جایگزین می‌کند.

۲. اصالت‌سنجی اعتبارنامه

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

Erlang: Begin Authentication

begin_authentication(UserId) ->
    Credentials = list_valid_credentials(UserId),
    #{client_safe := RequestOptions, server_only := ChallengeState} =
        webauthn:start_authentication(Credentials, rp_config()),
    store_challenge(UserId, ChallengeState),          %% short TTL
    RequestOptions.

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

Erlang: Finish Authentication

finish_authentication(UserId, Assertion) ->
    ChallengeState = get_challenge(UserId),
    Credentials = list_valid_credentials(UserId),
    case webauthn:finish_authentication(Credentials, Assertion, ChallengeState) of
        #{user_verified := true, credential_id := CredId, needs_update := NeedsUpdate} = Result ->
            %% webauthn tells us when the stored credential should be refreshed
            NeedsUpdate andalso refresh_credential(UserId, CredId, Result),
            mark_credential_used(UserId, CredId),
            {ok, CredId};
        _ ->
            {error, not_allowed}
    end.

• درستی‌سنجی ادعا: سرور چالش ذخیره‌شده و اعتبارنامه معتبر را بازیابی می‌کند، سپس از کتابخانه WebAuthn می‌خواهد «ادعای» کارخواه را درستی‌سنجی کند.
• بازآوری درصورت نیاز: اگر کاربر باموفقیت درستی‌سنجی شود، سرور پرچم needs_update را بررسی می‌کند. کتابخانه WebAuthn از این پرچم برای نشان دادن اینکه آیا وضعیت اطلاعات اعتباری ذخیره‌شده باید در سرور بازآوری شود یا نه استفاده می‌کند.
• نهایی‌سازی: سرور اعتبارنامه را به‌عنوان استفاده‌شده علامت‌گذاری می‌کند و فرایند ورود به سیستم را با موفقیت تکمیل می‌کند.

برای کسب اطلاعات بیشتر درباره ثبت سرور، راهنمای ادغام را در اینجا دنبال کنید. 

ملاحظات معماری پیشرفته 

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

1. انتقال به چند گذرکلید برای هر حساب: منطق سرور قدیمی واتساپ عمیقاً با فرض وجود یک اعتبارنامه برای هر کاربر درهم‌تنیده بود. برای پشتیبانی از واقعیت‌های مدرن چنددستگاهی، آن‌ها یک سیستم فهرست محدود طراحی کردند که به‌طور هوشمندانه قدیمی‌ترین اعتبارنامه را پس‌از رسیدن به حد مجاز حذف می‌کند. برای اطمینان از پایداری مطلق، این تغییر ساختاری عمده به‌تدریج ازطریق آزمایش‌های دقیق عرضه شد.
2. ایجاد تعادل در چرخه حیات اطلاعات اعتباری: مدیریت اعتبار اطلاعات اعتباری نیازمند دقت و ظرافت بود. باطل کردن بیش‌ازحد اعتبارنامه‌ها باعث ثبت‌نام‌های مجدد غیرضروری می‌شود، درحالی‌که سهل‌انگاری بیش‌ازحد باعث انباشته شدن اعتبارنامه‌های قدیمی می‌شود. «واتساپ» این مشکل را با پیاده‌سازی حالت‌های چرخه حیات متعادل حل کرد تا امنیت بالایی را بدون ایجاد نارضایتی برای کاربران حفظ کند، و این کار را با پاک‌سازی خودکار پس‌زمینه برای گذرکلیدهای غیرفعال تکمیل کرد.

بازاندیشی درباره همگام‌سازی بین‌دستگاهی

این معماری چندگذرکلیدی قدرتمند همچنین به واتساپ اجازه داد تا قابلیت استفاده چندسکویی را کاملاً بازنگری کند. جریان استاندارد WebAuthn بین‌دستگاهی مستلزم اسکن کردن رمزینه پاسخ‌سریع در یک دستگاه و اصالت‌سنجی ازطریق بلوتوث در دستگاه دیگر است. بااین‌حال، «واتساپ» متوجه شد که وابستگی به بلوتوث غیرقابل‌اعتماد است و کاربران اغلب رمزینه‌های پاسخ‌سریع جدید را با فرایند پیونددهی موجود در «واتساپ تحت وب» اشتباه می‌گرفتند.

به‌جای تحمیل کردن سازوکار انتقال بین‌دستگاهی شکننده، «واتساپ» به کاربران اجازه می‌دهد گذرکلیدها را به‌طور بومی در چندین بوم‌سازگان مثل «مدیر گذرواژه Google» در Android و «دسته کلید iCloud» در iOS نگه دارند. وقتی کاربران به پلاتفرم جدیدی مهاجرت می‌کنند، به‌راحتی در ورود به سیستم بعدی‌شان گذرکلید جدیدی تولید می‌کنند. این رویکرد کاملاً بدون اصطکاک برای کاربر است و به‌طور یکپارچه در بالای زیرساخت سرور چندگذرکلید جدید عمل می‌کند.

نگاهی به آینده

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

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

توصیه برای توسعه‌دهندگانی که در مقیاس بزرگ می‌سازند

برای توسعه‌دهندگانی که برای ادغام گذرکلیدها در مقیاس بزرگ آماده می‌شوند، تیم «واتساپ» این توصیه‌های مهم را ارائه می‌دهد:

• از همان ابتدا روی طبقه‌بندی خطاها سرمایه‌گذاری کنید: طیف گسترده استثناهای Credential Manager را به حالت‌های قابل‌بازیابی و نهایی دسته‌بندی کنید و برای هر سناریو مسیرهای جایگزین واضح و مناسبی تعریف کنید.
• قیف واجدشرایط بودن خود را درک کنید: بررسی‌های قابلیت دستگاه مانند وجود قفل صفحه، سخت‌افزار زیست‌سنجشی، و نسخه‌های «خدمات Play» و جریان‌های طراحی را ابزارسازی کنید تا به‌جای شکست در میان جریان، کاربران واجدشرایط را به‌طور فعال حذف کنید.
• برنامه‌تان را برای روش جایگزین آماده کنید: از گذرکلیدها به‌عنوان روش اصالت‌سنجی اصلی بهینه برای دستگاه‌های سازگار استفاده کنید، اما همیشه روش‌های سنتی را به‌عنوان روش جایگزین قابل‌اعتماد و جهانی حفظ کنید.
• برنامه‌ریزی برای تکه‌تکه‌سازی نسخه سیستم‌عامل: رفتار گذرکلید می‌تواند در سیستم‌عامل‌های مختلف متفاوت باشد. در Android نسخه ۱۳، ۱۴، و ۱۵+ به‌طور کامل آزمایش کنید و تفاوت‌های خاص سازنده اصلی را در واسط کاربر انتخاب اطلاعات کاربری درنظر بگیرید.
• فروش جانبی بافتاری و آموزش: ایجاد گذرکلید را به‌طور طبیعی درطول کنش‌های مرتبط با امنیت ارائه دهید. بااستفاده از زبان قابل‌فهم، گزاره ارزش (سرعت و امنیت) را به‌وضوح برجسته کنید تا کاربران را به پذیرش آن ترغیب کنید.
• نظارت پیش‌گیرانه: بوم‌سازگان با هر به‌روزرسانی سیستم‌عامل تکامل می‌یابد. به‌طور مداوم الگوهای تأخیر و خطا را ردیابی کنید تا از تغییرات چشم‌انداز دستگاه‌ها جلوتر باشید.

شروع به کار با گذرکلیدها و Credential Manager

بااستفاده از راهنمای ادغام و کد نمونه عمومی ما، با گذرکلیدها و Credential Manager در Android آشنا شوید.

اگر سؤال یا مشکلی دارید، می‌توانید ازطریق ردیاب مشکلات «اطلاعات کاربری Android» با ما درمیان بگذارید.