userVerification شیرجه عمیق

Eiji Kitamura

این سند در مورد اینکه userVerification در WebAuthn چیست و رفتارهای مرورگر که هنگام تعیین userVerification در حین ایجاد یا احراز هویت رمز عبور مشخص می‌شود، بحث می‌کند.

"تأیید کاربر" در WebAuthn چیست؟

کلیدهای عبور بر اساس رمزنگاری کلید عمومی ساخته می شوند. با ایجاد یک رمز عبور، یک جفت کلید عمومی-خصوصی ایجاد می‌شود، کلید خصوصی توسط ارائه‌دهنده کلید عبور ذخیره می‌شود و کلید عمومی برای ذخیره به سرور طرف متکی (RP) بازگردانده می‌شود. سرور می تواند یک کاربر را با تأیید امضای امضا شده توسط همان رمز عبور با استفاده از کلید عمومی جفت شده احراز هویت کند. پرچم "کاربر حاضر" (UP) روی اعتبار کلید عمومی ثابت می کند که شخصی در طول احراز هویت با دستگاه تعامل داشته است.

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

گفتگوی تأیید کاربر در iCloud Keychain در macOS.

گفتگوی تأیید کاربر در Android Chrome.

چگونه UP و UV روی سرور تایید می شوند

پرچم‌های بولی حضور کاربر (UP) و تایید شده توسط کاربر (UV) در قسمت داده‌های احراز هویت به سرور علامت داده می‌شوند. در طول احراز هویت، محتویات فیلد داده احراز هویت را می توان با تأیید امضا با استفاده از کلید عمومی ذخیره شده تأیید کرد. تا زمانی که امضا معتبر است، سرور می تواند پرچم ها را واقعی در نظر بگیرد.

فیلدهای داده Authenticator در یک اعتبار کلید عمومی.

هنگام ثبت نام و احراز هویت، سرور باید بررسی کند که پرچم UP true است یا اینکه آیا پرچم UV، بسته به نیاز، true یا false است.

تعیین پارامتر userVerification

طبق مشخصات WebAuthn ، RP می‌تواند یک تأیید کاربر با پارامتر userVerification را هم در ایجاد اعتبار و هم در تأیید درخواست کند. 'preferred' ، 'required' یا 'discouraged' را می پذیرد که به ترتیب به این معنی است:

• 'preferred' (پیش‌فرض): استفاده از روش تأیید کاربر در دستگاه ترجیح داده می‌شود ، اما اگر در دسترس نباشد، می‌توان از آن صرفنظر کرد. اعتبار پاسخ حاوی یک مقدار پرچم UV با true در صورتی که تأیید کاربر انجام شده باشد، و اگر UV انجام نشده باشد false .
• 'required' : فراخوانی روش تأیید کاربر موجود در دستگاه مورد نیاز است. اگر یکی در دسترس نباشد، درخواست به صورت محلی انجام نمی شود. این بدان معنی است که اعتبار پاسخ همیشه با پرچم UV تنظیم شده بر روی true برمی گردد.
• 'discouraged' : استفاده از روش تأیید کاربر ممنوع است. با این حال، بسته به دستگاه، تأیید کاربر ممکن است به هر حال انجام شود و پرچم UV می تواند حاوی true یا false باشد.

کد نمونه برای ایجاد رمز عبور:

const publicKeyCredentialCreationOptions = {
  // ...
  authenticatorSelection: {
    authenticatorAttachment: 'platform',
    residentKey: 'required',
    requireResidentKey: true,
    userVerification: 'preferred'
  }
};

const credential = await navigator.credentials.create({
  publicKey: publicKeyCredentialCreationOptions
});

کد نمونه برای احراز هویت رمز عبور:

const publicKeyCredentialRequestOptions = {
  challenge: /* Omitted challenge data... */,
  rpId: 'example.com',
  userVerification: 'preferred'
};

const credential = await navigator.credentials.get({
  publicKey: publicKeyCredentialRequestOptions
});

کدام گزینه را باید برای userVerification انتخاب کنید؟

مقدار userVerification که باید استفاده کنید به نیازهای برنامه شما و همچنین نیازهای تجربه کاربری شما بستگی دارد.

زمان استفاده از userVerification='preferred'

اگر تجربه کاربری را بر حفاظت اولویت دارید، از userVerification='preferred' استفاده کنید.

محیط‌هایی وجود دارند که در آن تأیید کاربر بیشتر اصطکاک است تا محافظت. برای مثال، در macOS که Touch ID در دسترس نیست (به دلیل اینکه دستگاه از آن پشتیبانی نمی‌کند، غیرفعال است یا دستگاه در حالت تاشو است)، از کاربر خواسته می‌شود رمز عبور سیستم خود را وارد کند. این باعث اصطکاک می شود و کاربر ممکن است به طور کامل احراز هویت را رها کند. اگر حذف اصطکاک برای شما مهمتر است، از userVerification='preferred' استفاده کنید.

هنگامی که Touch ID در دسترس نیست، یک گفتگوی کلید عبور در macOS نمایش داده می شود.

با userVerification='preferred' ، اگر تأیید کاربر با موفقیت انجام شود، پرچم UV true است و اگر تأیید کاربر نادیده گرفته شود، false . برای مثال، در macOS که Touch ID در دسترس نیست، از کاربر می‌خواهد روی دکمه‌ای کلیک کند تا تأیید کاربر را رد کند و اعتبار کلید عمومی شامل یک پرچم false UV است.

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

توجه: احراز هویت در google.com در حال حاضر از userVerification='preferred' استفاده می‌کند.

زمان استفاده از userVerification='required'

اگر فکر می کنید UP و UV کاملا ضروری هستند، از userVerification='required' استفاده کنید.

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

با userVerification='required' ، می توانید اطمینان حاصل کنید که تأیید کاربر در دستگاه انجام می شود. مطمئن شوید که سرور تأیید می کند که پرچم UV true است.

نتیجه گیری

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