למה מפתחות גישה בטוחים — מדריך מאויר לאימות שלא שולח סוד

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

מפתחות גישה (passkeys), שהתפשטו במהירות בשנים האחרונות, הם שיטת אימות ש-Apple, Google ו-Microsoft מקדמים יחד כמענה למצב הזה.¹ לעיתים קרובות מציגים אותם כ«נוח — אפשר להיכנס עם טביעת אצבע או פנים» — אבל זה לא באמת העניין. הערך האמיתי של מפתח גישה הוא שהוא מעביר את בסיס האבטחה מ«ערנות אנושית» ל«מבנה הפרוטוקול».

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

המאמר הזה עובר בתרשימים על למה מפתחות גישה בטוחים, מתוך מה ששבור בסיסמאות. אחר כך הוא עונה חזיתית לשאלות המובנות — «האם מפתחות גישה מסונכרנים באמת בטוחים?» ו«יש להם חולשות?» — ומסיים בסידור עיקרי הפריסה המעשית ליישומי Web ולסביבות Windows.

1. השורה התחתונה קודם

הסיבות שמפתחות גישה בטוחים מתכנסות לשלוש נקודות.

1. אין סוד בשרת. כל מה שהשרת שומר הוא המפתח הציבורי, שזה מידע שאי אפשר לנצל לרעה גם אם דלף. גם אם כל מסד הנתונים נשאב, אין «חומר להתחזות» שהתוקף יכול לקחת הביתה.²
2. הסוד אינו נע ברשת. כל מה שנשלח בכניסה הוא חתימה על ערך אקראי חד-פעמי (האתגר). מכיוון שהמפתח הפרטי אינו יוצא מהמאמת של המכשיר, האזנה או ממסור בכל מקום בנתיב אינם מניבים סוד.²
3. חתימה אינה יכולה להתקיים באתר מזויף. מפתח גישה קשור לדומיין של האתר, והדפדפן כופה את התאמת הדומיין. גם אם משתמש מרומה באתר מזויף, מפתח הגישה של האתר האמיתי פשוט אינו מופיע כמועמד, וגם אם חתימה הייתה ממסרת איכשהו, האימות היה דוחה אותה.³

שלושת אלה אינם תחבולות נפרדות אלא כולם מסקנות משינוי תכנון אחד: מאימות של «חולקים סוד ושולחים אותו» לאימות של «מוכיחים בחתימה שמחזיקים בסוד». נעבור עליהם לפי הסדר.

הקשר בין המונחים — מפתח גישה, WebAuthn, FIDO2, CTAP

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

טבלה 1: מפתח גישה הוא שם על בסיס FIDO2, לא שם תקן

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

מפת הידע של המאמר

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

flowchart LR
    accTitle: מפת הידע של הסיבה שמפתחות גישה בטוחים
    accDescr: תרשים שמראה שמפתח גישה נשען על WebAuthn, ‏FIDO2, ‏CTAP והצפנת מפתח ציבורי; שהקישור לדומיין באמצעות RP ID מונע פישינג באופן מבני; את ההבדל בין סוג מסונכרן לסוג הקשור למכשיר ואת נקודות הכשל הבודדות של כל אחד; את מיקומו כ-MFA עמיד לפישינג; ואת הקשרים של הסיכונים שנותרים (אמצעי חלופי, שחזור חשבון, גניבת הפעלה)
    passkey["מפתח גישה"]
    webauthn["WebAuthn"]
    fido2["FIDO2"]
    public_key_cryptography["הצפנת מפתח ציבורי"]
    ctap["CTAP"]
    authenticator["מאמת"]
    tpm["TPM"]
    windows_hello["Windows Hello"]
    fido2_security_key["מפתח אבטחה"]
    device_bound_passkey["מפתח גישה קשור למכשיר"]
    webauthn_secure_context["דרישת הקשר מאובטח (HTTPS)"]
    webauthn_challenge["אתגר (מספר אקראי חד-פעמי)"]
    rp_id["RP ID (מזהה Relying Party)"]
    phishing["פישינג"]
    aitm_phishing["פישינג מסוג AiTM (אדם-בתווך)"]
    credential_database_breach["דליפת מסד נתוני אישורים"]
    password_authentication["אימות בסיסמה"]
    password_reuse["שימוש חוזר בסיסמה (התקפת רשימות)"]
    account_takeover["השתלטות על חשבון"]
    session_cookie_theft["גניבת עוגיית הפעלה"]
    totp["סיסמה חד-פעמית (TOTP)"]
    phishing_resistant_mfa["MFA עמיד לפישינג"]
    entra_id["Microsoft Entra ID"]
    synced_passkey["מפתח גישה מסונכרן"]
    platform_credential_vault["כספת האישורים של הפלטפורמה"]
    nist_aal3["NIST AAL3 (רמת הבטחת מאמת 3)"]
    platform_account_hardening["חיזוק ההגנה על חשבון הפלטפורמה"]
    account_recovery_abuse["ניצול לרעה של תהליך שחזור החשבון"]
    account_recovery_hardening["חיזוק אימות הזהות בתהליך השחזור"]
    fallback_credential["אמצעי אימות חלופי המתקיים במקביל"]
    fallback_retirement["צמצום מתוכנן של אמצעים חלופיים"]
    passkey -->|"משתמש ב"| webauthn
    passkey -->|"משתמש ב"| fido2
    passkey -->|"משתמש ב"| public_key_cryptography
    fido2 -->|"משתמש ב"| webauthn
    fido2 -->|"משתמש ב"| ctap
    passkey -->|"משתמש ב"| authenticator
    authenticator -.->|"משתמש ב"| tpm
    windows_hello -.->|"משתמש ב"| tpm
    passkey -.->|"משתמש ב"| windows_hello
    passkey -.->|"משתמש ב"| fido2_security_key
    device_bound_passkey -->|"משתמש ב"| authenticator
    webauthn -->|"מחייב"| webauthn_secure_context
    webauthn -->|"משתמש ב"| webauthn_challenge
    passkey -->|"מחייב"| rp_id
    rp_id -->|"מונע"| phishing
    passkey -->|"מונע"| phishing
    passkey -->|"מונע"| aitm_phishing
    public_key_cryptography -->|"מצמצם"| credential_database_breach
    password_authentication -.->|"עלול לגרום ל"| credential_database_breach
    password_authentication -.->|"עלול לגרום ל"| phishing
    password_authentication -.->|"עלול לגרום ל"| password_reuse
    password_reuse -.->|"עלול לגרום ל"| account_takeover
    aitm_phishing -.->|"עלול לגרום ל"| session_cookie_theft
    totp -->|"שימוש לא מומלץ ל"| phishing_resistant_mfa
    passkey -->|"מענה מומלץ ל"| phishing_resistant_mfa
    entra_id -.->|"משתמש ב"| passkey
    passkey -.->|"מוגדר באמצעות"| entra_id
    synced_passkey -->|"נשמר ב"| platform_credential_vault
    synced_passkey -->|"אינו מתיישב עם"| nist_aal3
    device_bound_passkey -.->|"מענה מומלץ ל"| nist_aal3
    platform_credential_vault -.->|"עלול לגרום ל"| account_takeover
    platform_account_hardening -->|"מענה מומלץ ל"| account_takeover
    account_recovery_abuse -.->|"עלול לגרום ל"| account_takeover
    account_recovery_hardening -->|"מענה מומלץ ל"| account_recovery_abuse
    fallback_credential -.->|"עלול לגרום ל"| account_takeover
    fallback_retirement -->|"מענה מומלץ ל"| fallback_credential
    session_cookie_theft -->|"עלול לגרום ל"| account_takeover
    passkey -->|"שימוש לא מומלץ ל"| session_cookie_theft

בתרשים, קו מלא מציין קשר שמתקיים תמיד וקו מקווקו מציין קשר מותנה (תנאי ההתקיימות מפורטים בהסבר של כל קשר בעמוד המפורט). רשימת כל הקשרים (סך הכול 38, עם אסמכתה ורמת ודאות) והגדרות המושגים המרכזיים מרוכזות בעמוד המפורט של מפת הידע (ביפנית). נתונים: JSON-LD / Turtle

2. מה שבור באימות בסיסמה

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

sequenceDiagram
    participant U as משתמש
    participant B as דפדפן
    participant S as שרת
    Note over U: מחזיק את הסוד（סיסמה）בראש<br/>【חולשה ①】ניתן לניחוש / נעשה בו שימוש חוזר
    U->>B: מזין סיסמה
    Note over B: 【חולשה ②】אפשר להזין באותו אופן<br/>גם באתר מזויף（אי אפשר להבחין במראה）
    B->>S: שולח את הסיסמה עצמה
    Note over B,S: 【חולשה ③】הסוד זורם בנתיב<br/>מוגן ב-TLS אבל בקצה חוזר לטקסט גלוי
    S->>S: משווה לגיבוב השמור
    Note over S: 【חולשה ④】סודות（גיבובים）של כל המשתמשים מצטברים<br/>דליפה הופכת ליעד לכוח גס לא מקוון

איור 1: באימות בסיסמה, הסוד עצמו קיים בכל הקטעים

מנקודת מבט של תוקף, זה מבנה עם הרבה מטרות שקל לפגוע בהן.

• חולשה ① (המשתמש): חוזק שניתן לזכור בלבד, ושימוש חוזר בכמה אתרים. דליפה במקום אחד מתפשטת לכל החשבונות (התקפת רשימת סיסמאות).
• חולשה ② (רגע ההזנה): אם מכינים אתר מזויף שאי אפשר להבדיל מהאמיתי, המשתמש מוסר את הסוד בעצמו (פישינג).
• חולשה ③ (הנתיב): יש TLS ולכן האזנה לנתיב עצמו קשה, אבל אם משחילים «נקודת ממסור במראה לגיטימי» זה לא עוזר (AiTM בהמשך).
• חולשה ④ (השרת): גם אם שומרים בגיבוב, אם מסד הנתונים דולף אפשר להריץ כוח גס לא מקוון. סיסמאות חלשות נשברות לפי הסדר.

«אז נוסיף קוד חד-פעמי (SMS או TOTP)» זו האימות הרב-גורמי המסורתי, אבל גם כאן מבנה שליחת סוד משותף אינו משתנה. ב-TOTP השרת ואפליקציית האימות חולקים את אותו זרע (סוד), ואת הקוד בן 6 הספרות שנוצר המשתמש יכול בסוף להזין גם באתר מזויף. בפועל, פישינג מסוג AiTM (Adversary-in-the-Middle) שממסר בזמן אמת לאתר האמיתי פורץ את צמד הסיסמה+קוד חד-פעמי כפי שהוא. CISA (סוכנות הסייבר של ארה”ב) מונה כ«MFA עמיד לפישינג» רק שניים: שיטת FIDO/WebAuthn, ואימות מבוסס PKI כמו כרטיס חכם (PIV/CAC), וממקמת את FIDO כסטנדרט הזהב — מסיבה זו.⁴

כלומר הבעיה אינה «חוזק» הסיסמה אלא עצם המבנה של «חולקים סוד ושולחים אותו בכל אימות».

3. מהות מפתח הגישה — לא שולחים סוד, מוכיחים שמחזיקים בו

מפתח גישה הוא אישור מבוסס הצפנת מפתח ציבורי שעומד על שני תקנים: WebAuthn של W3C ו-CTAP של ברית FIDO (יחד FIDO2).²¹ זה נשמע קשה, אבל המבנה פשוט.

flowchart LR
    subgraph DEV["המכשיר של המשתמש"]
        AUTH["מאמת（כספת）<br/>Windows Hello / Face ID /<br/>נעילת מסך ב-Android / מפתח אבטחה"]
        SK["מפתח פרטי<br/>אינו יוצא מכאן כלל"]
        BIO["טביעת אצבע / פנים / PIN<br/>= רק לפתוח את דלת הכספת<br/>גם זה אינו יוצא החוצה"]
        AUTH --- SK
        BIO -->|"התאמה מקומית"| AUTH
    end
    subgraph SRV["שרת"]
        PK["מפתח ציבורי<br/>שאי אפשר לנצל לרעה גם אם דלף<br/>מידע «לאימות בלבד»"]
    end
    SK -.->|"זוג מתמטי<br/>（צד שיוצר חתימה）"| PK

איור 2: מהות מפתח הגישה היא זוג מפתחות לכל אתר. צד הסוד אינו יוצא מהמכשיר, והשרת מחזיק רק מפתח ציבורי לאימות

• המפתח הפרטי הוא המפתח בצד שיכול ליצור חתימה, נשמר במאמת במכשיר (Windows Hello, Face ID/Touch ID ב-iPhone, נעילת מסך ב-Android, או מפתח אבטחה כמו YubiKey), ואינו יוצא החוצה.
• המפתח הציבורי הוא המפתח בצד שיכול רק לאמת חתימה, ואותו מפקידים בשרת. חישוב לאחור מהמפתח הציבורי למפתח הפרטי אינו אפשרי חישובית, ולכן זה מידע שבטוח גם אם ידלוף.
• נתונים ביומטריים כמו טביעת אצבע או פנים משמשים רק לפתיחה מקומית של דלת הכספת, וגם הם אינם יוצאים מהמכשיר. נתונים ביומטריים אינם נשלחים לשרת.¹

רישום: מוסרים «רק» את המפתח הציבורי

הזרימה ברישום מפתח גישה באתר.

sequenceDiagram
    participant S as שרת（example.com）
    participant B as דפדפן
    participant A as מאמת
    S->>B: בקשת רישום（אתגר אקראי + מידע אתר）
    B->>A: צור מפתח לאתר הזה（example.com）
    A->>A: אימות זהות בטביעת אצבע / פנים / PIN（מקומי）
    A->>A: יוצר זוג מפתחות חדש<br/>המפתח הפרטי נשמר בפנים
    A->>B: מפתח ציבורי + credential ID（תווית המפתח）
    B->>S: שולח מפתח ציבורי + credential ID
    S->>S: שומר כמפתח הציבורי של החשבון הזה
    Note over S: כל מה שהשרת קיבל הוא<br/>«מידע שאי אפשר לנצל לרעה גם אם דלף» בלבד

איור 3: ברישום, מה שזורם ברשת ונשמר בשרת הוא המפתח הציבורי בלבד

החשוב הוא שבשלב הזה זוג המפתחות נוצר קשור לדומיין של האתר (RP ID). מפתח גישה שנוצר ל-example.com עובד רק באתר example.com (RP ID הוא לפי דומיין, ולכן מדפי תת-דומיין באותו דומיין כמו login.example.com אפשר להשתמש, אבל מדומיין לא קשור אי אפשר). הקישור הזה הוא הבסיס לעמידות לפישינג בהמשך.³

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

אימות: מחזירים חתימה חד-פעמית

הזרימה בכניסה. השוו לאימות בסיסמה (איור 1).

sequenceDiagram
    participant S as שרת（example.com）
    participant B as דפדפן
    participant A as מאמת
    S->>B: בקשת כניסה（אתגר אקראי חד-פעמי）
    B->>A: בקשת חתימה ל-example.com
    A->>A: אימות זהות בטביעת אצבע / פנים / PIN（מקומי）
    A->>A: יוצר חתימה במפתח הפרטי<br/>משלב אתגר + מקור + גיבוב RP ID
    A->>B: חתימה（לא המפתח הפרטי עצמו）
    B->>S: שולח את החתימה
    S->>S: מאמת את החתימה במפתח הציבורי השמור<br/>וגם מאשר אתגר, מקור ו-RP ID
    Note over B,S: בנתיב זורמת רק חתימה חד-פעמית<br/>גם אם גונבים, אי אפשר להשתמש באתגר הבא

איור 4: גם באימות הסוד אינו זז. מה שזורם הוא רק «מסמך הוכחה חד-פעמי»

השרת מציג בכל פעם מספר אקראי חדש (אתגר), והמאמת חותם על «האתגר הזה + המקור שהדפדפן רואה כעת + גיבוב ה-RP ID». השרת מאמת את החתימה במפתח הציבורי השמור, ומוודא שהאתגר הוא זה שהוא הציג, ושהמקור וה-RP ID הם של האתר שלו.⁵

כמסקנה מהתכנון הזה, שתיים משלוש הסיבות שבתחילה כבר מתקיימות.

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

האחת שנותרה, «חתימה אינה יכולה להתקיים באתר מזויף», היא נקודת המכירה הגדולה ביותר של מפתחות גישה. נפריד לפרק.

4. למה פישינג «מבנית» אינו יכול להצליח

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

במפתחות גישה, את ההתאמה הזו עושה הדפדפן באופן מכני, לא האדם. לפי מפרט WebAuthn, הדפדפן יכול לקרוא למאמת רק כש«הדומיין של המקור שמוצג כעת» ו«ה-RP ID של מפתח הגישה» תואמים.³ נצייר מה קורה ברגע שניגשים לאתר מזויף.

sequenceDiagram
    participant U as משתמש
    participant B as דפדפן
    participant P as אתר מזויף（examp1e.com）<br/>פרוקסי AiTM שממסר לאמיתי
    participant S as השרת האמיתי（example.com）
    U->>P: ניגש למסך כניסה זהה במראה
    P->>S: （מאחורי הקלעים）מתחיל את תהליך הכניסה האמיתי
    S->>P: אתגר
    P->>B: ממסר את האתגר ודורש חתימה
    B->>B: המקור הנוכחי הוא examp1e.com<br/>אי אפשר להציע מפתח גישה של example.com
    B--xP: חתימה אינה נוצרת（המשתמש אינו יכול להיות מרומה）
    Note over B,S: גם אם חתימה הייתה נוצרת בדרך כלשהי,<br/>examp1e.com משולב בחתימה ולכן<br/>האימות בשרת האמיתי בהכרח נופל

איור 5: פישינג מסוג AiTM פורץ סיסמה+קוד חד-פעמי, אבל במפתח גישה זה אינו מתקיים כבר בשלב החתימה

שימו לב שההגנה כפולה.

1. אינו מופיע כמועמד: הדפדפן מונה רק מפתחות גישה של RP ID שתואם למקור. בדומיין מזויף מפתח הגישה של האתר האמיתי אינו מופיע כאפשרות, כך שהמשתמש אינו יכול אפילו «להשתמש בטעות».
2. החתימה אינה עוברת: ביעד החתימה כלולים המקור שהדפדפן אישר וגיבוב ה-RP ID. השרת האמיתי מצליב את זה באימות, ולכן חתימה שנוצרה במקור אחר נדחית בהכרח.⁵

ההגנה מפישינג של סיסמאות הסתמכה על מאמץ אנושי של «המשתמש מסתכל טוב ב-URL». במפתחות גישה המשתמש אינו צריך לזהות אתר מזויף מלכתחילה. זה המשמעות המדויקת של «עמיד לפישינג (phishing-resistant)», והסיבה ש-CISA ו-NIST (המכון הלאומי לתקנים וטכנולוגיה בארה”ב) מתייחסים לשיטת FIDO/WebAuthn כמיוחדת.⁴⁶

נסדר את התוכן עד כאן לפי שיטת התקפה.

טבלה 2: השוואת עמידות לפי שיטת התקפה. כל «○» של מפתח גישה נובע ממבנה, לא מתפעול או תשומת לב

5. האם «מפתח גישה מסונכרן» בטוח

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

קודם טבלת סיכום. הפרק הזה והבא מסבירים למה כל שורה בטבלה היא כפי שהיא.

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

flowchart TB
    subgraph SYNC["מפתח גישה מסונכרן（ברירת מחדל לצרכן）"]
        S1["iCloud Keychain /<br/>Google Password Manager /<br/>מנהלי סיסמאות כמו 1Password"]
        S2["סנכרון מוצפן מקצה לקצה<br/>בין מכשירי אותו חשבון<br/>גם הספק אינו יכול לקרוא"]
        S3["יתרון: חזק בהחלפת דגם / אובדן<br/>זהירות: נדרשת הגנה על חשבון הענן עצמו"]
        S1 --> S2 --> S3
    end
    subgraph BOUND["מפתח גישה קשור-מכשיר"]
        B1["מפתח אבטחה（YubiKey וכו'） /<br/>Windows Hello /<br/>Microsoft Authenticator（Entra ID）"]
        B2["המפתח הפרטי אינו יוצא<br/>פיזית מהחומרה הזו（מוגן ב-TPM וכו'）"]
        B3["יתרון: מיקום המפתח ברור במקום אחד<br/>זהירות: רישום מרובה חובה מול אובדן"]
        B1 --> B2 --> B3
    end
    SYNC ~~~ BOUND

איור 6: מסונכרן מול קשור-מכשיר. בשניהם «לא שולחים מפתח פרטי לשרת» זהה, ומרכז הכובד של ההגנה שונה

מפתח גישה מסונכרן הוא כזה שבו iCloud Keychain או Google Password Manager מסנכרנים את המפתח הפרטי בין מכשירי אותו חשבון. החשוב כאן הוא שהסנכרון מוצפן מקצה לקצה. גם Apple וגם Google מצהירות במפורש שמפתחות גישה מוצפנים במכשיר לפני הסנכרון, והספק עצמו אינו יכול לקרוא את התוכן.⁷⁸ כלומר העיקרון «המפתח הפרטי אינו יוצא מהמכשיר» מרוכך בדיוק ל«המפתח הפרטי אינו יוצא מהמכשיר בטקסט גלוי», ובתמורה מקבלים עמידות להחלפת דגם ולאובדן.

איך הריכוך הזה משנה את מודל האיום צריך לומר במפורש. המקום שצריך להגן עליו מתכנס מ«השרת של כל אתר» ל«חשבון ענן אחד». מול דליפת DB של כל אתר ומול פישינג נשארים חזקים כרגיל, ועכשיו השתלטות על Apple ID/חשבון Google עצמו הופכת לנקודת כשל יחידה. לכן בדיוק, לחשבון הפלטפורמה שמפקידים בו מפתחות גישה שמים את ההגנה החזקה ביותר (נעילת מסך חזקה, סידור אמצעי שחזור, ואם אפשר מפתח אבטחה פיזי) כהנחה. גם NIST הוציא באפריל 2024 נספח ל-NIST SP 800-63B (Supplement 1: Incorporating Syncable Authenticators Into NIST SP 800-63B), ומיקם רשמית שמפתח גישה מסונכרן (syncable authenticator) יכול לעמוד בAAL2 (Authenticator Assurance Level 2, רמת הבטחת מאמת 2) של התקן הממשלתי אם עומד בדרישות. עם זאת, מכיוון שהמפתח הפרטי ניתן לייצוא, נקבע שלא להשתמש בסוג המסונכרן ל-AAL3 שדורש סביבה מבודדת בחומרה.⁶

מפתח גישה קשור-מכשיר הוא הסוג שבו המפתח הפרטי אינו יוצא מהחומרה. מפתח אבטחה כמו YubiKey הוא הטיפוסי, ובצד הארגוני גם מפתח גישה של Microsoft Entra ID (זה שנוצר בתוך Microsoft Authenticator) הוא קשור-מכשיר.⁹ גם Windows Hello ב-Windows, אם יש TPM, מגן על המפתח הפרטי תחת ה-TPM. מנגנון «כספת החומרה שלא מוציאה מפתחות» עצמו עומד על אותו בסיס שפורט במאמר על TPM.

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

6. אין כדור כסף — החולשה אינה «נעלמת» אלא «זזה»

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

flowchart LR
    A["תוקף"]
    G["האימות עצמו<br/>חתימה על אתגר<br/>【קשה】"]
    R["זרימת שחזור חשבון<br/>מדווחים «איבדתי את מפתח הגישה»<br/>ומגדירים מחדש ב-SMS או בדוא״ל,<br/>ואז רושמים מפתח גישה של התוקף"]
    F["נפילה במקביל<br/>אם נשארו סיסמה / כניסת SMS<br/>החוליה החלשה ביותר היא שם"]
    C["חשבון ענן<br/>במסונכרן Apple ID /<br/>חשבון Google הם נקודת כשל יחידה"]
    SS["סשן<br/>אם גונבים עוגייה אחרי כניסה<br/>שיטת האימות אינה רלוונטית"]
    A --x G
    A --> R
    A --> F
    A --> C
    A --> SS

איור 7: כשהכניסה (האימות) מתקשה, ההתקפה עוברת לזרימת שחזור, אמצעים במקביל, חשבון ענן וסשן

סיכוני השארה שכדאי לקבע בפועל הם ארבעה.

1. נפילה במקביל הופכת לחוליה החלשה ביותר. אם רק «גם» אפשר להשתמש במפתח גישה, וסיסמה או כניסת SMS נשארו, התוקף פשוט משתמש בהן. עמידות לפישינג, ברמת החשבון כולו, מוגבלת לרמת אמצעי הכניסה החלש ביותר. לב הפריסה אינו הוספת מפתח גישה אלא צמצום וביטול מתוכננים של הנפילה.
2. זרימת השחזור הופכת למשטח התקפה חדש. התחבולה של להתחזות ל«איבדתי את המכשיר» ולהגיע להגדרה מחדש דרך דלפק או דוא״ל, ואז לרשום מפתח גישה של התוקף עצמו. בפועל, הנדסה חברתית שעוקפת אימות חזק ומרמה את דלפק התמיכה היא אמצעי שגרתי בפריצות גדולות. ככל שהאימות מתקשה, עולה השאלה איך מתכננים אימות זהות בבקשת שחזור.
3. במסונכרן חשבון הענן הוא נקודת כשל יחידה. כבפרק הקודם. נדרשים הגנה על החשבון שמפקידים בו מפתחות גישה, ומדיניות ארגונית «לאיזו פלטפורמה מתירים סנכרון».
4. גניבת סשן אינה נמנעת. מפתח גישה מגן רק על רגע הכניסה; אם גונבים את עוגיית הסשן אחרי הכניסה בתוכנה זדונית או XSS, שיטת האימות אינה רלוונטית. נשארת עבודה בשכבה אחרת: משך חיי אסימון, קישור, וניהול בריאות המכשיר.

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

7. פריסה בפועל — WebAuthn API וסביבת Windows

לבסוף, מקבעים עיקרי נקודות מנקודת המבט של מי שמיישם.

הוספת כניסה במפתח גישה לשירות Web שלכם

בצד הדפדפן אלה רק שתי פונקציות של WebAuthn API. רישום קורא ל-navigator.credentials.create(), ואימות ל-navigator.credentials.get().

// רישום (צד הדפדפן)
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: challengeFromServer,   // מספר אקראי חד-פעמי שהשרת יוצר
    rp: { id: "example.com", name: "Example" },
    user: { id: userIdBytes, name: "taro@example.com", displayName: "Taro" },
    pubKeyCredParams: [{ type: "public-key", alg: -7 }],  // ES256
    authenticatorSelection: {
      residentKey: "required",        // הופך לאישור ניתן-לגילוי (= מפתח גישה)
      userVerification: "required",   // מחייב אימות זהות בביומטריה או PIN
    },
  },
});
// את המפתח הציבורי שולפים מ-credential.response, ואת ה-credential ID
// מ-credential.id / credential.rawId ברמה העליונה. גם את תשובת הרישום
// מאמתים בצד השרת (אתגר, מקור, RP ID) לפני השמירה,
// כמו בזמן האימות

משמעות הפרמטרים העיקריים היא כדלקמן.

טבלה 4: הפרמטרים העיקריים של navigator.credentials.create()

זהירות בסביבת הבדיקה: WebAuthn API נחשף רק בהקשר מאובטח, ולכן בדף שמוגש ב-http:// גולמי קריאה ל-navigator.credentials נכשלת. החריג הוא http://localhost (וגם 127.0.0.1), שמטופלים כמקורות מהימנים, כך שבמכונת פיתוח אפשר לנסות בלי HTTPS. אבל RP ID חייב להיות הדומיין האפקטיבי של המקור (או דומיין האב שלו), כך שמפתח גישה שנוצר ב-localhost אינו עובד בדומיין הייצור. גם בלי מאמת ביד, הפעלת מאמת וירטואלי בלשונית «WebAuthn» בכלי המפתחים של Chrome מאפשרת להריץ רישום ואימות מקצה לקצה.

// אימות (צד הדפדפן)
const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: challengeFromServer,
    rpId: "example.com",
    userVerification: "required",
  },
  // מציע את מפתח הגישה כמועמד למילוי אוטומטי בשדה הכניסה. בודקים
  // קודם תמיכה ב-PublicKeyCredential.isConditionalMediationAvailable(),
  // ובדפדפנים שאינם תומכים חוזרים לקריאה רגילה בלי mediation
  mediation: "conditional",
  // (ב-<input> היעד נדרש autocomplete="username webauthn")
});
// מאמתים בצד השרת את החתימה של assertion.response

הגוף הוא האימות בצד השרת. לכל הפחות, תמיד עושים את הבאים.⁵

• הצלבת אתגר: האם זה אתגר שלא שומש שאתם הנפקתם. האם הוא חד-פעמי (הגנה מ-replay). בנוסף, שמירה קשורה לסשן הדפדפן (ניסיון הכניסה) בזמן ההנפקה, והתרת צריכה רק מתשובה מאותו סשן. אם זה רפוי, נפתח מקום לתוקף לשלוח דרך דפדפן הקורבן חתימה על אתגר שמיועד לו, ולהכניס את הקורבן לחשבון התוקף (login CSRF).
• הצלבת מקור: האם origin ב-clientDataJSON הוא המקור החוקי של האתר (לב הגנת הפישינג).
• הצלבת גיבוב RP ID: האם rpIdHash ב-authenticatorData תואם ל-SHA-256 של ה-RP ID של האתר.
• אישור סוג הטקס והדגלים: האם type ב-clientDataJSON הוא webauthn.get באימות ו-webauthn.create ברישום. האם דגל UP (נוכחות משתמש) ב-authenticatorData דולק. אם דרשתם אימות משתמש (UV), האם גם דגל UV דולק.
• אימות חתימה: האם החתימה מאומתת נכון במפתח הציבורי שנשמר ברישום.
• קישור לחשבון: האם שולפים את credential ID (ו-userHandle) שהוצג במסד הנתונים שלכם, ומנפיקים סשן לבעלים של האישור הזה. אמון ללא תנאי בשם משתמש שהוזן בנפרד פותח חור של כניסה כאדם אחר עם חתימה נכונה.
• שמירה והשוואה של מונה החתימה: שומרים את signCount ב-authenticatorData לפי אישור, ומאשרים שהערך הבא גדול מהקודם. ערך קטן או שווה לקודם (כולל שוויון) מטופל כסימן לשכפול (שיבוט) של מאמת. עם זאת, מפתחות גישה מסונכרנים לרוב מחזירים תמיד 0, ולכן 0 מול 0 מתירים כחריג.

לכתוב את האימות הזה ביד הוא מתכון לתאונה, ולכן משתמשים בספרייה עם ניסיון (fido2-net-lib ב-.NET, SimpleWebAuthn ב-Node.js וכו’). פרטי המפרט (פענוח CBOR, הסכמת אלגוריתם, ניהול אתגר) משאירים לספרייה, ואנחנו מתרכזים בשמירה ובביטול של אתגרים, בממשק ניהול של כמה מפתחות גישה, ובתכנון זרימת השחזור — זה חלוקת הכוח הנכונה.

במקרה של סביבת Windows ומערכות פנימיות

מקהל הקוראים של האתר הזה — «מי שאחראי למערכות עסקיות ב-Windows» — די בשלוש הנקודות הבאות.

• לקוח Windows כבר תומך. Windows 11 תומך ביצירה, שימוש וניהול של מפתחות גישה עם Windows Hello כמאמת (הגדרות > חשבון > מפתחות גישה), והמפתח הפרטי מוגן בחומרה אם יש TPM.¹⁰ WebAuthn דרך דפדפן (Edge/Chrome) עובד גם ב-Windows 10.
• בסביבת Entra ID מפעילים «מפתח גישה = שיטת אימות FIDO2». Microsoft Entra ID תומך במפתחות אבטחה ובמפתחות גישה בתוך אפליקציית Microsoft Authenticator (קשורי-מכשיר), ואם דורשים «MFA עמיד לפישינג» בעוצמת האימות של גישה מותנית, אפשר להגביל גישה למשאבים היעד למפתחות גישה וכדומה.⁹ המעבר מעולם NTLM ומדיניות תוקף סיסמה אינו מתקדם בקפיצה אחת, ולכן לצד מלאי תשתית האימות שטופל במאמר על NTLM ו-Kerberos, הנוהל הקבוע הוא לחייב קודם MFA עמיד לפישינג בחשבונות מנהל.
• גם ביישום Web פנימי התועלת זהה. אבל HTTPS היא הנחה. WebAuthn API אינו פועל אלא בהקשר מאובטח, ולכן גם ביישום אינטראנט (מלבד localhost בפיתוח) HTTPS וסידור שם דומיין פנימי שניתן להשתמש בו כ-RP ID הם קודם. אחרי שזה סגור, RP ID פועל גם מול דומיין פנימי. במובן של פרידה מפתקיות סיסמה, לא נדיר שהאפקט יוצא מהר יותר בפנים מאשר בשירות חיצוני.

8. סיכום

• חולשת הסיסמה אינה החוזק אלא המבנה של «חולקים סוד ושולחים אותו בכל אימות». הסוד קיים אצל המשתמש, בשדה הקלט, בנתיב ובשרת, ולכן יש הרבה יעדי התקפה. גם הוספת קוד חד-פעמי מפסידה לפישינג מסוג AiTM כי ממסרים אותו.
• מפתח גישה הוא זוג מפתחות של הצפנת מפתח ציבורי לכל אתר, מוסרים לשרת רק מפתח ציבורי שאי אפשר לנצל לרעה גם אם דלף, ובכניסה שולחים רק חתימה על אתגר חד-פעמי. אין סוד בשרת, ואין סוד שזורם בנתיב.
• בחתימה אפויים המקור וה-RP ID שהדפדפן אישר, ולכן באתר מזויף מפתח הגישה של האמיתי אינו מופיע כמועמד, וגם ממסור נופל באימות. שהמשתמש אינו צריך לזהות אתר מזויף הוא מהות «עמידות לפישינג», ובסיס ההגנה עבר מתשומת לב אנושית למבנה הפרוטוקול.
• מפתח גישה מסונכרן מסונכרן בהצפנה מקצה לקצה, וחזק בהחלפת דגם ובאובדן. בתמורה המקום שצריך להגן עליו מתכנס לחשבון ענן, ולכן הגנה על Apple ID/חשבון Google עצמו הופכת להנחה. ארגון יכול גם לבחור קשור-מכשיר (מפתח אבטחה, מפתח גישה של Authenticator ב-Entra ID).
• מפתח גישה אינו מחסל התקפות אלא דוחק אותן למקום חלש. סיסמה במקביל, זרימת שחזור חשבון וגניבת סשן נשארים משטח התקפה, ולב הפריסה הוא צמצום מתוכנן של הנפילה וחיזוק זרימת השחזור.
• המימוש הוא שתי הפונקציות create / get של WebAuthn API + אימות שרת. את האימות לא כותבים לבד אלא משאירים לספרייה עם ניסיון, ומקצים כוח לניהול אתגרים, ממשק של כמה מפתחות גישה, ותכנון שחזור.

מאמרים קשורים

• מהו ה-TPM ב-Windows — מדריך מאויר ל«כספת שלא מוציאה מפתחות» ולאתחול מדיד
• NTLM ו-Kerberos בתרשימים — למה האימות «נופל» ל-NTLM
• שילוב אימות Entra ID ביישומי WinForms/WPF — תצורה מעשית של MSAL.NET ו-WAM broker
• טיפול בטוח באישורים ב-PowerShell — לגרש סיסמאות גלויות מסקריפטים
• רשימת בדיקה מינימלית לאבטחה בפיתוח יישומי Windows
• מאיפה עסקים קטנים ובינוניים צריכים להתחיל באבטחה — סיור ב«הנחיות אבטחת מידע לעסקים קטנים ובינוניים» של IPA, מהדורה 4

תחומי ייעוץ קשורים

KomuraSoft LLC מטפלת בסיוע למימוש WebAuthn של כניסה במפתח גישה למערכות Web פנימיות, בתכנון פריסת MFA עמיד לפישינג בסביבת Entra ID, וב-Custom Software Development שכולל שילוב אימות ביישומים עסקיים ל-Windows כמו WinForms/WPF.

מאמרים קשורים

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

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

מה ההבדל היסודי בין מפתחות גישה לסיסמאות?

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

האם נתונים ביומטריים (טביעת אצבע, פנים) נשלחים לשרת?

לא. נתוני טביעת אצבע או פנים משמשים רק להתאמה מקומית בתוך המכשיר — לפתוח את דלת הכספת שמחזיקה את המפתח הפרטי — ולפי תכנון FIDO, נתונים ביומטריים אינם מועברים מחוץ למכשיר. כל מה שהשרת מקבל הוא חתימה עם הדגל שסומן שאימות זהות (user verification) התבצע; אין בה דבר מטביעת האצבע עצמה, ואף לא וקטור מאפיינים ביומטרי שנגזר ממנה. במקום שבו ביומטריה אינה אפשרית, PIN יכול להחליף, וגם PIN הזה, כמו PIN של Windows Hello, מותאם רק מקומית במכשיר — ההבדל המכריע מסיסמה הוא שהוא אינו נע ברשת.

למה מפתחות גישה עמידים לפישינג?

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

אם איבדתי את הטלפון, אהיה נעול מחוץ לחשבונות?

אם זה מפתח גישה מסונכרן — כזה שנשמר ב-iCloud Keychain או ב-Google Password Manager — אפשר לשחזר אותו למכשיר חדש שנכנס לאותו Apple ID או חשבון Google. עם זאת, שחזור הכספת המוצפנת מקצה לקצה דורש לא רק את סיסמת החשבון אלא אימות זהות נוסף, כמו הזנת נעילת המסך (קוד גישה) של המכשיר הקודם, כך שאם מאבדים גם את אמצעי השחזור האלה, השחזור עלול להיות בלתי אפשרי. חשוב לא להפקיד הכול בטלפון אחד. מפתחות גישה קשורי-מכשיר (מפתחות אבטחה, Windows Hello וכדומה) חולקים את גורל המכשיר, ולכן הנוהל הקבוע לחשבונות חשובים הוא לרשום יותר ממפתח גישה אחד. רוב השירותים מאפשרים לרשום כמה מפתחות גישה בחשבון אחד. שימו לב שאיך מבטלים מפתח גישה שאבד משתנה לפי הסוג. למפתח גישה מסונכרן, מכיוון שהעותקים בכל מכשיר הם אותו אישור אחד, קודם מסירים את המכשיר שאבד או מבצעים מחיקה מרחוק בצד חשבון הפלטפורמה כדי להשבית את העותק במכשיר (מחיקת מפתח הגישה בהגדרות החשבון של השירות עצמו מבטלת את העותקים בכל המכשירים בבת אחת). למפתח גישה קשור-מכשיר, מחיקת מפתח הגישה של המאמת בצד השירות מבטלת רק את המפתח שאבד. לשימוש ארגוני, חשוב לתכנן יחד גם «יתירות כדי שמשתמשים יוכלו לשחזר בעצמם» וגם «נוהל למנהלים לבטל באובדן».

יש גם חולשות למפתחות גישה?

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

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.