מפתחות כניסה: מה לעזאזל ולמה?

הדברים האלה נקראו מפתחות סיסמה בטוח עושים את הסיבוב בימים אלה. הם היו אטרקציה עיקרית ב W3C TPAC 2022, זכה לתמיכה ב ספארי 16, מוצאים את דרכם לתוך macOS ו-iOS, ומתוכננים להיות העתיד למנהלי סיסמאות כמו 1Password. הם כבר נתמך באנדרואיד, ובקרוב ימצאו את דרכם ל-Chrome OS ו-Windows במהדורות עתידיות.

שיפורי האבטחה של מערכת ההפעלה חנונית לא בדיוק עושים כותרות גדולות בקהילה הקדמית, אבל ברור שמפתחות סיסמה הולכים להיות "דבר". ובהתחשב באופן שבו סיסמאות ואפליקציות סיסמאות משפיעות על חווית המשתמש של דברים כמו אימות ועיבוד טפסים, אולי נרצה לפחות לעטוף את המוח שלנו סביבם, כדי שנדע מה צפוי.

זו הנקודה של המאמר הזה. אני לומד ומתנסה במפתחות סיסמה - וממשק ה-API של WebAuthn שעליו הם בנויים - כבר זמן מה. תן לי לחלוק את מה שלמדתי.

תוכן העניינים

טרמינולוגיה

הנה הקטע המחייב בטרמינולוגיה שתרצה לדעת כשאנחנו מתעמקים. כמו רוב הטכנולוגיה, מפתחות סיסמה מיוצרים עם מילים אזוטריים וראשי תיבות שלעיתים קרובות הם מחסומים להבנה. אני אנסה לבטל את המיסטיציה עבורך כאן.

• מסיבת הסתמכות: השרת מולו תבצע אימות. נשתמש ב"שרת" כדי לרמוז על הצד המסתמך במאמר זה.
• לקוח: במקרה שלנו, דפדפן האינטרנט או מערכת ההפעלה.
• מאמת: התקני תוכנה ו/או חומרה המאפשרים יצירה ואחסון עבור צמדי מפתחות ציבוריים.
• FIDO: גוף תקנים פתוח שיוצר גם מפרטים סביב אישורי FIDO.
• WebAuthn: הפרוטוקול הבסיסי עבור מפתחות סיסמה, הידוע גם בשם a FIDO2 אישורים או אישורי FIDO במכשיר יחיד.
• מפתחות סיסמה: WebAuthn, אך עם סנכרון ענן (נקרא גם אישורי FIDO מרובי-מכשירים, אישורים ניתנים לגילוי או אישורי תושב).
• קריפטוגרפיה של מפתח ציבורי: זוג מפתחות שנוצר הכולל מפתח פרטי וציבורי. בהתאם לאלגוריתם, יש להשתמש בו עבור חתימה ואימות או הצפנה ופענוח. זה ידוע גם בשם קריפטוגרפיה אסימטרית.
• RSA: ראשי תיבות של שמות היוצרים, ריבסט שמיר ואדל. RSA היא משפחה ישנה יותר, אך עדיין שימושית, של קריפטוגרפיה של מפתחות ציבוריים המבוססת על פריטים של פקטורינג.
• קריפטוגרפיה אליפטית עקומה (ECC): משפחה חדשה יותר של קריפטוגרפיה מבוסס על עקומות אליפטיות.
• ES256: מפתח ציבורי עקומה אליפטית המשתמש באלגוריתם חתימה של ECDSA (PDF) עם SHA256 עבור hashing.
• RS256: כמו ES256, אבל הוא משתמש ב-RSA עם RSASSA-PKCS1-v1.5 ו-SHA256.

מה הם מפתחות סיסמה?

לפני שנוכל לדבר ספציפית על מפתחות סיסמה, עלינו לדבר על פרוטוקול אחר שנקרא WebAuthn (ידוע גם בשם FIDO2). מפתחות סיסמה הם מפרט שבנוי על גבי WebAuthn. WebAuthn מאפשר הצפנת מפתח ציבורי כדי להחליף סיסמאות. אנו משתמשים בהתקן אבטחה כלשהו, ​​כגון מפתח חומרה או מסוג Trusted Platform Module (TPM), ליצירת מפתחות פרטיים וציבוריים.

המפתח הציבורי מיועד לשימוש של כל אחד. עם זאת, לא ניתן להסיר את המפתח הפרטי מהמכשיר שיצר אותו. זו הייתה אחת הבעיות עם WebAuthn; אם אתה מאבד את המכשיר, אתה מאבד את הגישה.

Keys פותר זאת על ידי מתן סנכרון בענן של האישורים שלך. במילים אחרות, מה שאתה מייצר במחשב שלך יכול לשמש כעת גם בטלפון שלך (אם כי באופן מבלבל, יש גם אישורים של מכשיר בודד).

נכון לעכשיו, בזמן כתיבת שורות אלה, רק iOS, macOS ו-Android מספקים תמיכה מלאה במפתחות סיסמה מסונכרנים בענן, וגם אז הם מוגבלים על ידי הדפדפן בשימוש. גוגל ואפל מספקות ממשק לסנכרון באמצעותן מנהל הסיסמאות של גוגל ו מחזיק מפתחות אפל iCloud שירותים, בהתאמה.

כיצד מפתחות סיסמה מחליפים סיסמאות?

בהצפנת מפתח ציבורי, אתה יכול לבצע מה שמכונה חתימה. החתימה לוקחת פיסת נתונים ואז מפעילה אותו דרך אלגוריתם חתימה עם המפתח הפרטי, שם ניתן לאמת אותו עם המפתח הציבורי.

כל אחד יכול ליצור צמד מפתחות ציבוריים, וזה לא ניתן לייחס לאף אדם שכן כל אדם יכול היה ליצור אותו מלכתחילה. מה שעושה את זה שימושי הוא שרק נתונים חתומים עם המפתח הפרטי יכולים להיות מאומתים עם המפתח הציבורי. זה החלק שמחליף סיסמה - שרת מאחסן את המפתח הציבורי, ואנחנו נכנסים על ידי אימות שיש לנו את החצי השני (למשל מפתח פרטי), על ידי חתימה על אתגר אקראי.

בתור יתרון נוסף, מכיוון שאנו מאחסנים את המפתחות הציבוריים של המשתמש בתוך מסד נתונים, אין עוד דאגה להפרות סיסמאות המשפיעות על מיליוני משתמשים. זה מפחית דיוג, הפרות ושלל בעיות אבטחה אחרות שהעולם שלנו תלוי-סיסמה מתמודד כעת. אם מסד נתונים נפרץ, כל זה מאוחסן במפתחות הציבוריים של המשתמש, מה שהופך אותו למעשה חסר תועלת לתוקף.

גם לא נשכחו עוד מיילים והסיסמאות המשויכות להם! הדפדפן יזכור באילו אישורים השתמשת עבור איזה אתר - כל מה שאתה צריך לעשות הוא לבצע כמה קליקים, ואתה מחובר. אתה יכול לספק אמצעי אימות משני כדי להשתמש במפתח, כגון ביומטריה או סיכה , אבל אלה עדיין הרבה יותר מהירות מהסיסמאות של פעם.

עוד על קריפטוגרפיה

קריפטוגרפיה של מפתחות ציבוריים כוללת מפתח פרטי ומפתח ציבורי (המכונה צמד מפתחות). המפתחות נוצרים יחד ויש להם שימושים נפרדים. לדוגמה, המפתח הפרטי מיועד להישמר בסוד, והמפתח הציבורי מיועד למי שרוצים להחליף הודעות איתו.

כאשר מדובר בהצפנה ופענוח של הודעה, המפתח הציבורי של הנמען משמש להצפנת הודעה כך שרק המפתח הפרטי של הנמען יכול לפענח את ההודעה. בעגה הביטחונית, זה מכונה "מתן סודיות". עם זאת, זה לא מספק הוכחה לכך שהשולח הוא מי שהוא אומר שהוא, מכיוון שכל אחד יכול להשתמש במפתח ציבורי כדי לשלוח למישהו הודעה מוצפנת.

ישנם מקרים בהם אנו צריכים לוודא שהודעה אכן הגיעה מהשולח שלה. במקרים אלה, אנו משתמשים בחתימה ובאימות חתימה כדי להבטיח שהשולח הוא מי שהוא אומר שהוא (ידוע גם בשם אותנטיות). במפתח ציבורי (נקרא גם א-סימטרי) קריפטוגרפיה, זה נעשה בדרך כלל על ידי חתימה על ה-hash של הודעה, כך שרק המפתח הציבורי יכול לאמת אותה בצורה נכונה. ה-hash והמפתח הפרטי של השולח מייצרים חתימה לאחר הפעלתו באמצעות אלגוריתם, ואז כל אחד יכול לאמת שההודעה הגיעה מהשולח עם המפתח הציבורי של השולח.

כיצד אנו ניגשים למפתחות סיסמה?

כדי לגשת למפתחות, עלינו תחילה ליצור ולאחסן אותם במקום כלשהו. ניתן לספק חלק מהפונקציונליות הזו עם מאמת. א מאמת הוא כל מכשיר מגוב חומרה או תוכנה המספק את היכולת ליצור מפתחות קריפטוגרפיים. תחשוב על הסיסמאות החד פעמיות שאתה מקבל מהן מאמת Google, 1Password, או LastPass, בין היתר.

לדוגמה, מאמת תוכנה יכול להשתמש במודול הפלטפורמה המהימנה (TPM) או במובלעת מאובטחת של התקן כדי ליצור אישורים. לאחר מכן ניתן לאחסן את האישורים מרחוק ולסנכרן בין מכשירים, למשל מפתחות סיסמה. מאמת חומרה יהיה משהו כמו א יובי, שיכול ליצור ולאחסן מפתחות במכשיר עצמו.

כדי לגשת למאמת, לדפדפן צריכה להיות גישה לחומרה, ולשם כך אנחנו צריכים ממשק. הממשק בו אנו משתמשים כאן הוא פרוטוקול Client to Authenticator (CTAP). זה מאפשר גישה למאמתים שונים על פני מנגנונים שונים. לדוגמה, אנו יכולים לגשת למאמת באמצעות NFC, USB ו-Bluetooth על ידי שימוש ב-CTAP.

אחת הדרכים המעניינות יותר להשתמש במפתחות היא על ידי חיבור הטלפון שלך באמצעות Bluetooth למכשיר אחר שאולי אינו תומך במפתחות. כאשר המכשירים מותאמים באמצעות Bluetooth, אני יכול להיכנס לדפדפן במחשב שלי באמצעות הטלפון שלי כמתווך!

ההבדל בין מפתחות סיסמה ל-WebAuthn

מפתחות סיסמה ומפתחות WebAuthn שונים בכמה דרכים. ראשית, מפתחות סיסמה נחשבים לאישורי ריבוי מכשירים וניתן לסנכרן אותם בין מכשירים. לעומת זאת, מפתחות WebAuthn הם אישורים של מכשיר יחיד - דרך מפוארת לומר שאתה קשור למכשיר אחד לצורך אימות.

שנית, כדי לבצע אימות לשרת, מפתחות WebAuthn צריכים לספק את ידית המשתמש לכניסה, ולאחר מכן allowCredentials רשימה מוחזרת ללקוח מהשרת, מה שמודיע באילו אישורים ניתן להשתמש כדי להיכנס. מפתחות סיסמה מדלגים על שלב זה ומשתמשים בשם הדומיין של השרת כדי להראות אילו מפתחות כבר קשורים לאתר זה. אתה יכול לבחור את מפתח הסיסמה המשויך לאותו שרת, כפי שהוא כבר ידוע על ידי המערכת שלך.

אחרת, המפתחות זהים מבחינה קריפטוגרפית; הם שונים רק באופן מאחסנתם ובאיזה מידע הם משתמשים כדי להתחיל את תהליך ההתחברות.

התהליך... בקיצור

התהליך ליצירת WebAuthn או סיסמה דומה מאוד: קבל אתגר מהשרת ולאחר מכן השתמש ב- navigator.credentials.create אינטרנט API ליצירת זוג מפתחות ציבוריים. לאחר מכן, שלח את האתגר ואת המפתח הציבורי בחזרה לשרת לאחסון.

עם קבלת המפתח הציבורי והאתגר, השרת מאמת את האתגר ואת ההפעלה שממנה הוא נוצר. אם זה יוצא, המפתח הציבורי מאוחסן, כמו גם כל מידע רלוונטי אחר כמו מזהה המשתמש או נתוני אישור, במסד הנתונים.

למשתמש יש עוד שלב אחד - אחזר אתגר נוסף מהשרת והשתמש ב- navigator.credentials.get API לחתום על האתגר. אנחנו שולחים בחזרה את האתגר החתום לשרת, והשרת מאמת את האתגר, ואז מתחבר לנו אם החתימה עוברת.

יש, כמובן, לא מעט יותר בכל שלב. אבל בדרך כלל כך היינו נכנסים לאתר באמצעות WebAuthn או מפתחות סיסמה.

הבשר ותפוחי האדמה

מפתחות סיסמה משמשים בשני שלבים נפרדים: ה עֵדוּת ו טענה שלבים.

ניתן לחשוב על שלב האישור גם כשלב הרישום. תירשם עם דוא"ל וסיסמה לאתר חדש, עם זאת, במקרה זה, נשתמש במפתח הסיסמה שלנו.

שלב ההצהרה דומה לאופן שבו תיכנס לאתר לאחר ההרשמה.

תעודה

השמיים 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, על מנת לאמת בקלות את כל האתגרים החתומים בשלב הטענה.

טַעֲנָה

השמיים 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 כדי לוודא שזה נחתם עם המפתח הפרטי.

השמיים authenticatorData כולל כמה מאפיינים שכדאי לעקוב אחריהם. ראשית הוא ה-hash SHA256 של המקור שבו אתה משתמש, הממוקם בתוך 32 הבתים הראשונים, וזה שימושי לאימות שהבקשה מגיעה מאותו שרת מקור. השני הוא ה signCount, שהוא מבייט 33 עד 37. זה נוצר מהמאמת ויש להשוות אותו לערך הקודם שלו כדי להבטיח ששום דבר דגי לא קורה עם המפתח. הערך צריך תמיד להיות 0 כאשר מדובר במפתח רב-התקנים ועליו להיות גדול באקראי מה-signCount הקודם כאשר מדובר במפתח של מכשיר יחיד.

לאחר שהצהרת על הכניסה שלך, אתה אמור להיות מחובר - מזל טוב! Keys הוא פרוטוקול די נהדר, אבל הוא מגיע עם כמה אזהרות.

כמה חסרונות

יש הרבה צדדים חיוביים ל-Passkeys, עם זאת, יש כמה בעיות עם זה בזמן כתיבת שורות אלה. ראשית, מפתחות סיסמה הם עדיין מעט מוקדמים מבחינת תמיכה, עם רק אישורים של מכשיר בודד מותרים ב-Windows ומעט מאוד תמיכה במערכות לינוקס. Passkeys.dev מספק שולחן נחמד שדומה ל-Caniuse של הפרוטוקול הזה.

כמו כן, פלטפורמות המפתחות של גוגל ואפל אינן מתקשרות זו עם זו. אם אתה רוצה להעביר את האישורים שלך מטלפון האנדרואיד שלך לאייפון שלך... ובכן, אין לך מזל לעת עתה. זה לא אומר שאין יכולת פעולה הדדית! אתה יכול להיכנס למחשב שלך באמצעות הטלפון שלך כמאמת. אבל זה יהיה הרבה יותר נקי רק שזה יהיה מובנה במערכת ההפעלה ויסונכרן מבלי שזה יינעל ברמת הספק.

לאן הדברים הולכים?

איך נראה פרוטוקול המפתחות של העתיד? זה נראה די טוב! ברגע שהוא יקבל תמיכה מיותר מערכות הפעלה, אמורה להיות קליטה בשימוש, ותתחילו לראות אותו בשימוש יותר ויותר בטבע. כמה מנהלי סיסמאות הם אפילו מתכוונים לתמוך בהם ממקור ראשון.

מפתחות סיסמה אינם נתמכים בשום אופן רק באינטרנט. אנדרואיד ו iOS שניהם יתמכו במפתחי סיסמה מקומיים כאזרחים מהשורה הראשונה. אנחנו עדיין בימים הראשונים של כל זה, אבל מצפים לראות את זה מוזכר יותר ויותר.

אחרי הכל, אנחנו מבטלים את הצורך בסיסמאות, ועל ידי כך, הופכים את העולם לבטוח יותר עבורו!

משאבים

הנה כמה משאבים נוספים אם ברצונך ללמוד עוד על מפתחות סיסמה. יש גם מאגר והדגמה שהרכבתי עבור מאמר זה.

• הפצת תוכן ויחסי ציבור מופעל על ידי SEO. קבל הגברה היום.
• Platoblockchain. Web3 Metaverse Intelligence. ידע מוגבר. גישה כאן.
• מקור: https://css-tricks.com/passkeys-what-the-heck-and-why/