WebAuthn Level 3 הפך לתקן: Passkeys עוברים מפיצ׳ר אבטחה לתשתית מוצר
ב־25 באוגוסט 2026 פרסם W3C את Web Authentication Level 3 כהמלצה רשמית. זהו צעד משמעותי עבור מוצרים דיגיטליים: אימות מבוסס מפתח ציבורי כבר אינו תוספת ניסיונית לצד סיסמה, אלא בסיס בשל יותר לבניית כניסה עמידה לפישינג — בתנאי שמטפלים גם ברישום, שחזור, תמיכה ותפעול.
מה פורסם — ומה המשמעות של Recommendation
WebAuthn Level 3 מגדיר API ליצירה ולשימוש באישורי מפתח ציבורי חזקים, תחומים ל־Relying Party ומתווכים על ידי הדפדפן. W3C מציין שזהו היורש של Level 2 וממליץ על פריסה רחבה. סטטוס Recommendation אינו אומר שכל דפדפן, מערכת הפעלה ומכשיר מיישמים באותו יום כל פרט באותה דרך; הוא כן מספק חוזה יציב יותר בין יישומי Web, דפדפנים ומאמתים. עבור מנהל מוצר, המשמעות היא שאפשר לעבור מדיון כללי ב׳כניסה ללא סיסמה׳ לתוכנית מוצר שמגדירה אילו מסעות נתמכים, באילו פלטפורמות ומה קורה כאשר יכולת מסוימת אינה זמינה.
Passkey הוא מסע חיים, לא כפתור
הדגמה של Passkey נראית פשוטה: המשתמש מאשר באמצעות ביומטריה או קוד מקומי ונכנס. מוצר אמיתי חייב לטפל במחזור חיים מלא — יצירת אישור, הוספת מכשיר, מעבר בין מכשירים, החלפת טלפון, ביטול הרשאה, חשבון משותף, שינוי שם דומיין ותמיכה באדם שאיבד גישה. אם מסלול השחזור חלש, הוא הופך לדרך העוקפת את מנגנון האימות החזק. אם הוא קשיח מדי, התמיכה הופכת לצוואר בקבוק. לכן צוות צריך לתכנן את ההרשמה והשחזור יחד, ולהגדיר מתי נדרש אימות נוסף ומהי הראיה המספקת להשבת שליטה בחשבון.
פרטיות ו־Relying Party boundaries
אחד העקרונות החשובים ב־WebAuthn הוא שאישור המפתח הציבורי תחום ל־Relying Party. הדבר מצמצם את האפשרות להשתמש באותו סוד בין אתרים ומחזק עמידות לפישינג. אבל הגבול הזה הוא גם החלטת ארכיטקטורה: קבוצת מוצרים עם כמה דומיינים, אפליקציות White-label או מעבר דומיין צריכות להבין כיצד זהות המותג וה־RP ID משפיעות על האישורים. אין לתכנן את הנושא רק בתוך מסך ההתחברות. נדרש מיפוי של דומיינים, סביבות, אפליקציות ושותפים, לצד בדיקה שאף קיצור דרך אינו מרחיב את גבול האמון מעבר לנדרש.
Progressive enhancement ותאימות
גם לאחר פרסום התקן, בסיס המשתמשים נשאר מגוון. מכשירים מנוהלים, דפדפנים ישנים, סביבות משובצות ומדיניות ארגונית עשויים לתמוך באופן שונה ביכולות. לכן אימוץ אחראי מתחיל בזיהוי יכולות ובהצעת מסלול מתאים, לא בחסימה גורפת. אפשר להציע Passkey בזמן הנכון, לשמור חלופה בטוחה ולמדוד היכן התהליך נכשל. צוות QA צריך לבדוק שילובים אמיתיים של מערכת הפעלה, דפדפן ומאמת, כולל ביטול על ידי המשתמש, timeout, שינוי מכשיר ותקלת רשת. התאימות היא חלק מחוויית המוצר ולא הערת שוליים טכנית.
אבטחה חזקה דורשת תפעול חזק
מפתח ציבורי מפחית תלות בסיסמאות ובסודות משותפים, אך אינו מבטל סיכוני השתלטות על חשבון, social engineering, session theft או טעויות בהרשאות. יש להגן על יצירת Passkey חדש, להציג למשתמש רשימת מאמתים, לאפשר ביטול, להתריע על שינוי רגיש ולתעד אירועים שניתנים לחקירה. בצד השרת נדרשים אימות מלא של challenge, origin, RP ID, חתימה ומוני שימוש כאשר הם רלוונטיים. אסור להפוך מאפייני attestation או מידע על המכשיר למנגנון מעקב מיותר; יש לבחור מדיניות שמתאימה לרמת הסיכון ולצמצם איסוף מידע.
איך למדוד מעבר בלי לבלבל הצלחה עם הרשמה
מספר ה־Passkeys שנוצרו אינו מדד מספק. צוות צריך למדוד שיעור השלמת כניסה, זמן כניסה, הצלחה לפי פלטפורמה, שיעור מעבר למסלול חלופי, פניות תמיכה, שחזורים חשודים והפחתה באיפוסי סיסמה או ניסיונות פישינג מוצלחים. חשוב להפריד בין adoption לבין reliability: ייתכן שמשתמשים נרשמו אך אינם מצליחים להשתמש ביכולת ברגע קריטי. ניסוי הדרגתי לפי קבוצת משתמשים מאפשר לזהות בעיות לפני שמרחיבים. מדידה טובה מחברת אבטחה, חוויית משתמש ועלות תפעולית לאותה תמונה.
תוכנית פעולה לצוותי Web ו־SaaS
הצעד הראשון הוא מלאי של מסעות זהות וסיכון: כניסה, פעולה רגישה, הוספת מנהל, תשלום ושחזור. לאחר מכן מגדירים RP IDs, מודל חשבון, חלופות בטוחות ונתוני מדידה; בונים פיילוט לקבוצה מצומצמת; ובודקים דפדפנים, מכשירים ותמיכה. רק אחרי שהשחזור, הניטור וההסבר למשתמש עובדים, מרחיבים את ההצעה או הופכים אותה לברירת מחדל. WebAuthn Level 3 מספק בסיס תקני חזק יותר. הערך העסקי יגיע מהאופן שבו המוצר הופך את התקן למסע אמין, מובן וניתן לתפעול.