Passkeys: چه هک و چرا؟

این چیزها نامیده می شود کلمات کلیدی مطمئناً این روزها در حال چرخش هستند. آنها یک جاذبه اصلی در بودند W3C TPAC 2022، حمایت را در صفری 16، راه خود را پیدا می کنند macOS و iOS، و قرار است باشند آینده مدیران رمز عبور مانند 1Password. آن ها هستند قبلاً پشتیبانی شده در اندروید، و به زودی در نسخه های بعدی به سیستم عامل کروم و ویندوز راه خواهند یافت.

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

نکته این مقاله همین است. من مدتی است که در حال مطالعه و آزمایش کلیدهای عبور - و WebAuthn API که آنها بر روی آن ساخته شده اند - هستم. اجازه دهید آنچه را که یاد گرفته ام به اشتراک بگذارم.

جدول محتوا

واژگان

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

• طرف متکی: سروری که با آن احراز هویت خواهید کرد. ما از "سرور" برای اشاره به طرف متکی در این مقاله استفاده خواهیم کرد.
• کارفرما: در مورد ما، مرورگر وب یا سیستم عامل.
• احراز هویت: نرم‌افزار و/یا دستگاه‌های سخت‌افزاری که امکان تولید و ذخیره‌سازی جفت‌های کلید عمومی را فراهم می‌کنند.
• فیدو: یک بدنه استاندارد باز که همچنین مشخصاتی را پیرامون اعتبارنامه های FIDO ایجاد می کند.
• وب آوتن: پروتکل زیربنایی برای کلیدهای عبور که به نام a نیز شناخته می شود FIDO2 اعتبارنامه یا اعتبار FIDO تک دستگاهی.
• کلیدهای عبور: WebAuthn، اما با همگام‌سازی ابری (همچنین به آن اعتبار FIDO چند دستگاهی، اعتبارنامه قابل کشف یا اعتبار مقیم نیز گفته می‌شود).
• رمزنگاری کلید عمومی: یک جفت کلید تولید شده که شامل یک کلید خصوصی و عمومی است. بسته به الگوریتم، باید از آن برای امضا و تأیید یا رمزگذاری و رمزگشایی استفاده شود. این نیز به عنوان شناخته شده است رمزنگاری نامتقارن.
• RSA: مخفف نام سازندگان، Rivest Shamir و Adel. RSA یک خانواده قدیمی‌تر، اما هنوز مفید، از رمزنگاری کلید عمومی بر اساس فاکتورهای اول است.
• رمزنگاری منحنی بیضوی (ECC): خانواده جدیدتر رمزنگاری بر اساس منحنی های بیضوی.
• ES256: یک کلید عمومی منحنی بیضوی که از الگوریتم امضای ECDSA استفاده می کند (PDF) با SHA256 برای هش کردن
• RS256: مانند ES256، اما از RSA با استفاده می کند RSASSA-PKCS1-v1.5 و SHA256.

کلیدهای عبور چیست؟

قبل از اینکه بخواهیم به طور خاص در مورد کلیدهای عبور صحبت کنیم، باید در مورد پروتکل دیگری به نام صحبت کنیم وب آوتن (همچنین به عنوان FIDO2 شناخته می شود). Passkey ها مشخصاتی هستند که بر روی WebAuthn ساخته شده اند. WebAuthn به رمزنگاری کلید عمومی اجازه می دهد تا رمزهای عبور را جایگزین کند. ما از نوعی دستگاه امنیتی مانند کلید سخت افزاری یا ماژول پلت فرم اعتماد (TPM)، برای ایجاد کلیدهای خصوصی و عمومی.

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

Passkeys این مشکل را با ارائه یک همگام سازی ابری از اعتبارنامه های شما حل می کند. به عبارت دیگر، آنچه در رایانه خود تولید می کنید اکنون می تواند در تلفن شما نیز استفاده شود (اگرچه به طرز گیج کننده ای، اعتبار تک دستگاهی نیز وجود دارد).

در حال حاضر، در زمان نگارش این مقاله، تنها iOS، macOS و Android از کلیدهای عبور همگام‌سازی ابری پشتیبانی کامل می‌کنند، و حتی در آن زمان، آنها توسط مرورگر مورد استفاده محدود می‌شوند. گوگل و اپل یک رابط برای همگام سازی از طریق خود ارائه می دهند Google Password Manager و Apple iCloud Keychain خدمات، به ترتیب.

چگونه رمز عبور جایگزین رمز عبور می شود؟

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

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

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

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

اطلاعات بیشتر در مورد رمزنگاری

رمزنگاری کلید عمومی شامل داشتن یک کلید خصوصی و یک کلید عمومی (معروف به جفت کلید) است. کلیدها با هم تولید می شوند و کاربردهای جداگانه ای دارند. به عنوان مثال، کلید خصوصی برای مخفی نگه داشتن در نظر گرفته شده است و کلید عمومی برای هر کسی که می خواهید با او پیام رد و بدل کنید در نظر گرفته شده است.

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

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

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

برای دسترسی به کلیدهای عبور، ابتدا باید آنها را در جایی تولید و ذخیره کنیم. برخی از این قابلیت ها را می توان با احراز هویت ارائه کرد. یک احراز هویت هر دستگاه سخت افزاری یا نرم افزاری است که توانایی تولید کلید رمزنگاری را فراهم می کند. به گذرواژه های یکبار مصرفی که از آنها دریافت می کنید فکر کنید Google Authenticator را, 1Password، یا برنامه LastPass، در میان دیگران است.

به عنوان مثال، یک تأیید کننده نرم افزار می تواند از ماژول پلتفرم قابل اعتماد (TPM) یا محصور امن یک دستگاه برای ایجاد اعتبار استفاده کند. سپس اعتبارنامه ها را می توان از راه دور ذخیره کرد و در دستگاه ها مانند کلیدهای عبور همگام سازی کرد. یک تصدیق کننده سخت افزار چیزی شبیه به یک خواهد بود یوبی کی، که می تواند کلیدها را روی خود دستگاه تولید و ذخیره کند.

برای دسترسی به Authenticator، مرورگر باید به سخت افزار دسترسی داشته باشد و برای آن، ما به یک رابط نیاز داریم. رابطی که ما در اینجا استفاده می کنیم پروتکل Client to Authenticator (CTAP) است. این امکان دسترسی به احراز هویت های مختلف را از طریق مکانیسم های مختلف فراهم می کند. به عنوان مثال، ما می‌توانیم با استفاده از CTAP از طریق NFC، USB و بلوتوث به یک احراز هویت دسترسی پیدا کنیم.

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

تفاوت بین رمز عبور و WebAuthn

کلیدهای عبور و کلیدهای WebAuthn از چند جهت با هم متفاوت هستند. اول، کلیدهای عبور اعتبار چند دستگاهی در نظر گرفته می شوند و می توانند بین دستگاه ها همگام شوند. در مقابل، کلیدهای WebAuthn اعتبارنامه‌های تک دستگاهی هستند - روشی جالب برای گفتن اینکه برای تأیید به یک دستگاه متصل هستید.

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

در غیر این صورت، کلیدها از نظر رمزنگاری یکسان هستند. آنها فقط در نحوه ذخیره و اطلاعاتی که برای شروع فرآیند ورود استفاده می کنند متفاوت هستند.

روند ... به طور خلاصه

فرآیند تولید WebAuthn یا رمز عبور بسیار مشابه است: یک چالش از سرور دریافت کنید و سپس از navigator.credentials.create web API برای ایجاد یک جفت کلید عمومی. سپس چالش و کلید عمومی را به سرور ارسال کنید تا ذخیره شود.

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

کاربر یک مرحله دیگر دارد - چالش دیگری را از سرور بازیابی کرده و از آن استفاده کنید navigator.credentials.get API برای امضای چالش. چالش امضا شده را به سرور برمی‌گردانیم و سرور چالش را تأیید می‌کند، سپس در صورت عبور امضا، ما را وارد می‌کند.

البته در هر مرحله کمی بیشتر وجود دارد. اما به طور کلی ما با استفاده از WebAuthn یا کلیدهای عبور وارد یک وب سایت می شویم.

گوشت و سیب زمینی

کلیدهای عبور در دو مرحله مجزا استفاده می شوند: تصدیق و ادعا فاز.

مرحله تصدیق را می توان مرحله ثبت نام نیز در نظر گرفت. شما باید با یک ایمیل و رمز عبور برای یک وب سایت جدید ثبت نام کنید، اما در این مورد، ما از کلید عبور خود استفاده می کنیم.

مرحله ادعا شبیه به نحوه ورود به وب سایت پس از ثبت نام است.

گواهی

La navigator.credentials.create API تمرکز مرحله تأیید ما است. ما به عنوان یک کاربر جدید در سیستم ثبت شده ایم و باید یک جفت کلید عمومی جدید ایجاد کنیم. با این حال، باید مشخص کنیم که چه نوع جفت کلیدی را می خواهیم تولید کنیم. این بدان معناست که ما باید گزینه هایی را ارائه دهیم navigator.credentials.create.

// The `challenge` is random and has to come from the server
const publicKey: PublicKeyCredentialCreationOptions = { challenge: safeEncode(challenge), rp: { id: window.location.host, name: document.title, }, user: { id: new TextEncoder().encode(crypto.randomUUID()), // Why not make it random? name: 'Your username', displayName: 'Display name in browser', }, pubKeyCredParams: [ { type: 'public-key', alg: -7, // ES256 }, { type: 'public-key', alg: -256, // RS256 }, ], authenticatorSelection: { userVerification: 'preferred', // Do you want to use biometrics or a pin? residentKey: 'required', // Create a resident key e.g. passkey }, attestation: 'indirect', // indirect, direct, or none timeout: 60_000,
};

const pubKeyCredential: PublicKeyCredential = await navigator.credentials.create({ publicKey
});
const { id // the key id a.k.a. kid
} = pubKeyCredential;
const pubKey = pubKeyCredential.response.getPublicKey();
const { clientDataJSON, attestationObject } = pubKeyCredential.response;
const { type, challenge, origin } = JSON.parse(new TextDecoder().decode(clientDataJSON));
// Send data off to the server for registration

میگیریمش PublicKeyCredential که حاوی یک AuthenticatorAttestationResponse که پس از خلقت برمی گردد. اعتبار شناسه جفت کلید تولید شده را دارد.

پاسخ چند بیت از اطلاعات مفید را ارائه می دهد. اول، ما کلید عمومی خود را در این پاسخ داریم و باید آن را به سرور ارسال کنیم تا ذخیره شود. دوم، ما نیز به عقب برمی گردیم clientDataJSON ویژگی هایی که می توانیم رمزگشایی کنیم و از آنجا، آن را برگردانیم type, challengeو origin از کلید عبور

برای تأیید، می خواهیم اعتبار را تأیید کنیم type, challengeو origin بر روی سرور، و همچنین ذخیره کلید عمومی با شناسه آن، به عنوان مثال kid. ما همچنین می توانیم به صورت اختیاری ذخیره کنیم attestationObject اگر بخواهیم یکی دیگر از ویژگی های مفید برای ذخیره سازی این است COSE الگوریتم، که در بالا در ما تعریف شده است  PublicKeyCredentialCreationOptions با alg: -7 or alg: -256، به منظور بررسی آسان هر گونه چالش امضا شده در مرحله ادعا.

ادعا

La navigator.credentials.get API تمرکز مرحله ادعا خواهد بود. از نظر مفهومی، این جایی است که کاربر پس از ثبت نام به برنامه وب وارد می شود.

// The `challenge` is random and has to come from the server
const publicKey: PublicKeyCredentialRequestOptions = { challenge: new TextEncoder().encode(challenge), rpId: window.location.host, timeout: 60_000,
};

const publicKeyCredential: PublicKeyCredential = await navigator.credentials.get({ publicKey, mediation: 'optional',
});
const { id // the key id, aka kid
} = pubKeyCredential;
const { clientDataJSON, attestationObject, signature, userHandle } = pubKeyCredential.response;
const { type, challenge, origin } = JSON.parse(new TextDecoder().decode(clientDataJSON));
// Send data off to the server for verification

ما دوباره یک را دریافت خواهیم کرد PublicKeyCredential با AuthenticatorAssertionResponse این بار. اعتبار دوباره شامل شناسه کلید است.

ما نیز دریافت می کنیم type, challengeو origin از clientDataJSON از نو.  signature در حال حاضر در پاسخ گنجانده شده است، و همچنین authenticatorData. ما به آنها و آنها نیاز خواهیم داشت clientDataJSON برای بررسی اینکه آیا این با کلید خصوصی امضا شده است.

La authenticatorData شامل برخی از خصوصیات است که ارزش ردیابی را دارند ابتدا هش SHA256 مبدأ مورد استفاده شما است که در 32 بایت اول قرار دارد، که برای تأیید اینکه درخواست از همان سرور مبدا ارسال شده است مفید است. دوم این است signCount، که از بایت 33 تا 37 است. این از احراز هویت ایجاد می شود و باید با مقدار قبلی آن مقایسه شود تا اطمینان حاصل شود که هیچ مشکلی با کلید انجام نمی شود. زمانی که یک کلید عبور چند دستگاهی است، مقدار باید همیشه 0 باشد و زمانی که کلید عبور تک دستگاهی است باید به طور تصادفی بزرگتر از signCount قبلی باشد.

هنگامی که ورود خود را تأیید کردید، باید وارد شوید - تبریک! Passkeys یک پروتکل بسیار عالی است، اما با برخی هشدارها همراه است.

برخی از جنبه های منفی

Passkeys نکات مثبت زیادی دارد، با این حال، در زمان نگارش این مقاله مشکلاتی با آن وجود دارد. برای یک چیز، کلیدهای عبور از نظر پشتیبانی هنوز در مراحل اولیه قرار دارند، تنها مجوزهای تک دستگاهی در ویندوز مجاز است و پشتیبانی بسیار کمی از سیستم های لینوکس. Passkeys.dev فراهم می کند میز زیبا که به نوعی شبیه Caniuse این پروتکل است.

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

کارها به کجا می رود؟

پروتکل کلیدهای عبور آینده چگونه است؟ خیلی خوب به نظر می رسد! هنگامی که از سیستم عامل های بیشتری پشتیبانی می کند، استفاده از آن افزایش می یابد و شما شاهد استفاده بیشتر و بیشتر از آن در طبیعت خواهید بود. مقداری مدیران رمز عبور حتی از آنها حمایت می کنند.

رمز عبور به هیچ وجه فقط در وب پشتیبانی نمی شود. آندروید و IOS هر دو از کلیدهای عبور بومی به عنوان شهروندان درجه یک پشتیبانی می کنند. ما هنوز در روزهای اولیه همه اینها هستیم، اما انتظار داریم که بیشتر و بیشتر به آن اشاره کنیم.

بالاخره ما نیاز به رمز عبور را از بین می بریم و با این کار دنیا را برای آن امن تر می کنیم!

منابع

اگر می خواهید در مورد Passkeys بیشتر بدانید، در اینجا منابع بیشتری وجود دارد. همچنین یک مخزن و نسخه ی نمایشی وجود دارد که من برای این مقاله آماده کرده ام.

• محتوای مبتنی بر SEO و توزیع روابط عمومی. امروز تقویت شوید.
• پلاتوبلاک چین. Web3 Metaverse Intelligence. دانش تقویت شده دسترسی به اینجا.
• منبع: https://css-tricks.com/passkeys-what-the-heck-and-why/