چگونه واتس‌اپ برای ورود امن و یکپارچه برای ۱ میلیارد کاربر با رمز عبور ارتقا یافت؟

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

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

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

تصمیم برای پذیرش رمزهای عبور

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

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

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

ادغام سمت کلاینت

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

اگرچه مسیر شاد از همان ابتدا جواب داد، اما پیمایش در میان کاربران متنوع در میان تولیدکنندگان اصلی تجهیزات (OEM)، نسخه‌های مختلف اندروید و پیکربندی‌های متنوع دستگاه (مانند فقط پین در مقابل بیومتریک، یا اندروید ۱۳ در مقابل ۱۴+) موارد حاشیه‌ای بی‌سابقه‌ای را آشکار کرد. این موارد شامل کاربرانی بدون قفل صفحه، انواع استثنائات غیرمنتظره، سرویس‌های پلی منسوخ‌شده و رفتار متناقض ارائه‌دهنده اعتبارنامه بود.

برای غلبه بر این موانع، تیم‌های واتس‌اپ و گوگل عمیقاً با هم همکاری کردند و چندین چالش را برطرف کردند:

• بهینه‌سازی جریان جستجوی اعتبارنامه : جریان جستجوی اولیه، به‌ویژه برای کاربرانی که هنوز رمز عبور ایجاد نکرده بودند، تأخیر کمی را نشان داد. از آنجایی که اکثر کاربران واتس‌اپ در مراحل اولیه در این دسته قرار می‌گیرند، این امر تأخیر قابل توجهی را تقریباً به هر ورود به سیستم اضافه می‌کرد. واتس‌اپ با تجهیز مسیر تماس و شناسایی گلوگاه‌ها، این فرآیند را به طور قابل توجهی تسریع کرد و به افزایش عملکرد دست یافت که در نهایت به نفع کل اکوسیستم اندروید بود.
• مدیریت حالت‌های گذرا : واتس‌اپ یک لایه جامع مدیریت خطا ایجاد کرده است تا موانع خاص دستگاه مانند در دسترس بودن مدیر رمز عبور، عدم پیکربندی قفل صفحه، مشکلات اتصال متناوب، سخت‌افزار ناسازگار، سرویس‌های بازی قدیمی و دسته‌بندی استثنائات به حالت‌های قابل بازیابی و ترمینال را مدیریت کند. این امر امکان تخریب تدریجی را فراهم می‌کرد، اگر جریان کلید عبور نمی‌توانست کامل شود، سیستم با خیال راحت به احراز هویت سنتی برمی‌گشت بدون اینکه کاربر را در حالت خرابی قرار دهد.
• پیمایش استثنائات خاص سیستم عامل: هنگامی که تله‌متری موانع خاص دستگاه مانند GetPublicKeyCredentialDomException (شکست در رمزگشایی اعتبارنامه) را در برخی از دستگاه‌های اندروید ۱۳ و CreatePublicKeyCredentialDomException (عدم امکان دریافت حساب همگام‌سازی) را در حین ایجاد کلید عبور در اندروید ۱۴ نشان داد، گوگل و تیم واتس‌اپ علل اصلی را بررسی کرده و بهبودهایی را در سطح پلتفرم اعمال کردند تا جریان‌های ایجاد روان‌تر تضمین شود. می‌توانید راهنمای جامع خطا را در اینجا بیابید که کدهای خطای رایج و توضیحات مربوط به Credential Manager را فهرست می‌کند و اطلاعاتی در مورد علل آنها ارائه می‌دهد.

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

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

معماری سمت سرور و موانع بین پلتفرمی

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

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

۱. ثبت رمز عبور

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

ارلانگ: شروع ثبت نام

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) ذخیره می‌کند و گزینه‌ها را به دستگاه کلاینت ارسال می‌کند.

ارلانگ: پایان ثبت نام

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.

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

۲. احراز هویت مبتنی بر اعتبار

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

ارلانگ: شروع احراز هویت

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.

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

ارلانگ: اتمام احراز هویت

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 نیاز به اسکن یک کد QR در یک دستگاه و تأیید اعتبار از طریق بلوتوث در دستگاه دیگر دارد. با این حال، واتس‌اپ وابستگی به بلوتوث را غیرقابل اعتماد دانست و کاربران اغلب کدهای QR جدید را با فرآیند پیوند وب واتس‌اپ موجود اشتباه می‌گرفتند.

واتس‌اپ به جای تحمیل یک مکانیسم انتقال شکننده بین دستگاه‌های مختلف، به کاربران اجازه می‌دهد تا کلیدهای عبور را به صورت بومی در چندین اکوسیستم مانند Google Password Manager در اندروید و iCloud Keychain در iOS نگه دارند. وقتی کاربران به یک پلتفرم جدید مهاجرت می‌کنند، به سادگی در ورود بعدی خود یک کلید عبور جدید ایجاد می‌کنند. این رویکرد برای کاربر کاملاً بدون مشکل است و به طور یکپارچه بر روی زیرساخت سرور چند رمز عبور جدید عمل می‌کند.

نگاه به آینده

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

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

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

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

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

شروع کار با کلیدهای عبور و مدیریت اعتبارنامه‌ها

با استفاده از راهنمای یکپارچه‌سازی و نمونه کد عمومی ما، با کلیدهای عبور و مدیریت اعتبارنامه در اندروید آشنا شوید.

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