Passkeys ו-WebAuthn: הסוף לעידן הסיסמה שאפשר לגנוב

מאת צוות מדיה דיל · 02.07.2026 · אבטחת מידע · 7 דק׳ קריאה

WebAuthn, זוג מפתחות ציבורי-פרטי, Platform ו-Roaming Authenticators, Origin Binding נגד Phishing, סנכרון Passkeys בין מכשירים, ומנגנוני Recovery.

כל מנגנון שמבוסס על "סוד משותף" - סיסמה, קוד SMS, אפילו קוד TOTP באפליקציית אימות - חולק תכונה מסוכנת אחת: את הסוד אפשר להעביר. תוקף שמקים דף התחברות מזויף יכול לגרום למשתמש להקליד סיסמה וקוד OTP ישירות לתוך הטופס שלו, ומשם לשדר אותם הלאה לאתר האמיתי תוך שניות - מה שנקרא real-time phishing relay, ושמעקף אפילו 2FA. Passkeys, המבוססים על תקן WebAuthn, פותרים את הבעיה מהשורש: אין סוד לגנוב, כי ההתחברות מבוססת על זוג מפתחות קריפטוגרפי שהמפתח הפרטי שלו אף פעם לא עוזב את החומרה של המשתמש.

זוג מפתחות במקום סוד משותף

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

Passkeys כשכבת UX וסנכרון מעל WebAuthn

WebAuthn הוא ה-API הטכני שהדפדפן חושף; Passkey הוא השם המסחרי-שיווקי למימוש שמוסיף סנכרון בין מכשירים דרך iCloud Keychain, Google Password Manager או דומיו. המשמעות המעשית: משתמש שנרשם עם Passkey באייפון יכול להתחבר מהמק שלו בלי תהליך הרשמה נוסף, כי המפתח הפרטי מסונכרן בין המכשירים שלו תחת אותו חשבון ענן. זה פותר את החולשה הכי גדולה של מפתחות אבטחה פיזיים מסורתיים (כמו YubiKey) - אובדן מכשיר יחיד שמנעל אותך החוצה.

למה Phishing לא עובד - Origin Binding

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

Platform Authenticators מול Roaming Authenticators

WebAuthn תומך בשני סוגי authenticator: Platform, כלומר החומרה המובנית במכשיר עצמו (Face ID, Touch ID, Windows Hello), ו-Roaming, מפתח פיזי חיצוני כמו YubiKey שמתחבר דרך USB או NFC ועובד בין מכשירים שונים. ארגונים עם דרישות אבטחה גבוהות במיוחד, כמו גישה ל-production infrastructure, נוטים להעדיף roaming keys כי הם לא תלויים בענן סנכרון של ספק חיצוני, ומספקים אפשרות ל-attestation שמוודאת את דגם החומרה המדויק שהפיק את המפתח.

האתגר האמיתי: Recovery כשאין סיסמה לאפס

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

שוקלים לעבור מסיסמאות ו-2FA מסורתי להתחברות מבוססת Passkeys באפליקציה שלכם? נשמח לעזור לכם בוואטסאפ.

תמיכת דפדפנים ומכשירים - מה קורה כשהמכשיר ישן

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

מה משתנה בצד השרת ובמסד הנתונים

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

Cross-Device Sign-in - התחברות למחשב באמצעות הנייד

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

Attestation: איך שרת יכול לוודא איזו חומרה יצרה את המפתח

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

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

שילוב עם Single Sign-On ארגוני

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

מה קורה בגניבה פיזית של המכשיר

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

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

מיגרציה הדרגתית ממשתמשים קיימים

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

שאלות נפוצות

מה קורה אם המשתמש מאבד גישה לכל המכשירים שרשם עליהם Passkey?

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

האם צריך לוותר על סיסמה לגמרי כדי להשתמש ב-Passkeys?

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

האם Passkey אחד עובד בכל האתרים, כמו סיסמה אחת שמשתמשים בכמה מקומות?

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

כמה זמן לוקח למשתמש קצה להירשם עם Passkey בפעם הראשונה?

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

האם Passkeys מתאימים גם לאפליקציות מובייל נייטיב, לא רק לאתרים?

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

תגיות: Passkeys · WebAuthn · Public Key Cryptography · Phishing Resistance · Origin Binding · Platform Authenticator

← חזרה לבלוג · צור קשר