סיסמה היא סוד משותף: אתם יודעים אותה, והשרת שומר גרסה שלה. כל דליפה מצד השרת, וכל אתר מזויף שמשכנע אתכם להקליד אותה, מנצלים בדיוק את זה. Passkey מבטל את השיתוף. במכשיר שלכם נוצר זוג מפתחות: הפרטי נשאר במכשיר, הציבורי נשמר באתר. בכניסה, האתר שולח אתגר, המכשיר חותם עליו אחרי שאישרתם בטביעת אצבע, פנים או קוד המכשיר, והאתר מאמת את החתימה. השרת לא מחזיק שום דבר שאפשר להשתמש בו כדי להתחזות אליכם.
למה זה עמיד לפישינג, ולא רק ״בטוח יותר״
החתימה כוללת את שם הדומיין שהבקשה הגיעה ממנו. passkey שנוצר עבור bank.example לא יעבוד ב-bank-example.login.example, גם אם האתר המזויף זהה למקור בפיקסל. זה ההבדל המהותי מול קוד SMS או אפליקציית אימות: את הקוד אפשר לשכנע אתכם להקליד במקום הלא נכון; את החתימה של ה-passkey אין איך להעביר.
מצב התקן
הבסיס הטכני הוא Web Authentication (WebAuthn) של W3C יחד עם פרוטוקול CTAP של FIDO Alliance. Level 2 הוא המלצה מ-2021, ו-Level 3 פורסם כהמלצה רשמית ב-25 באוגוסט 2026. לפי FIDO Alliance, Level 3 מתקנן בעיקר יכולות שהדפדפנים כבר שלחו בפועל, ובהן הטיפול ב-passkeys מסונכרנים. כלומר: מה שאתם רואים היום ב-Chrome, Safari ו-Firefox הוא התקן, לא ניסוי.
מה עובד היום
- יצירה וכניסה בדפדפנים העיקריים, במובייל ובדסקטופ, עם אימות ביומטרי או קוד המכשיר.
- סנכרון בתוך אקוסיסטם: passkey שנוצר באייפון זמין במק דרך iCloud Keychain; passkey באנדרואיד זמין ב-Chrome דרך Google Password Manager. גם מנהלי סיסמאות של צד שלישי שומרים ומסנכרנים passkeys.
- כניסה ממכשיר אחר (cross-device): סריקת QR מהמחשב בטלפון, עם בדיקת קרבה ב-Bluetooth. זה פותר את ״המפתח נמצא בטלפון ואני במחשב של העבודה״, במחיר של כמה שניות.
- מפתחות חומרה (YubiKey ודומיו) כ-passkey שאינו מסונכרן, למי שרוצה שהמפתח הפרטי לא יעזוב פיסת סיליקון.
מה עדיין תלוי בספק
סנכרון בין אקוסיסטמים. passkey שנוצר ב-iCloud Keychain לא עובר לבד ל-Google Password Manager. הפתרונות: ליצור passkey נפרד בכל אקוסיסטם (רוב האתרים מאפשרים כמה), להשתמש במנהל סיסמאות חוצה-פלטפורמות, או להסתמך על QR בכל פעם. FIDO Alliance עובדת על פורמט ייצוא וייבוא, אבל התמיכה בו תלויה בכל ספק בנפרד; נכון להיום אל תניחו שהיא קיימת אצלכם.
שחזור חשבון. זו הנקודה החלשה בכל מערכת ללא סיסמה. אם איבדתם את כל המכשירים ואין גישה לחשבון הסנכרון, מה שקובע הוא תהליך השחזור של האתר, לא של ה-passkey. אתר שמאפשר שחזור דרך SMS בלבד החזיר את החולשה שה-passkey ניסה למנוע. כשאתם בוחרים אתר או מתכננים אחד, בדקו את מסלול השחזור לפני הכול.
ניהול בארגון. בחברות, השאלה היא מי שולט במפתחות: המשתמש דרך החשבון האישי שלו ב-Apple או Google, או הארגון דרך מנהל זהויות. הספקים מציעים תשובות שונות, וזה שיקול מדיניות לפני שהוא שיקול טכני.
למי זה מתאים עכשיו
למשתמש פרטי: לכל חשבון שמציע את זה, בעיקר דוא״ל, בנק וחשבונות הענן. השאירו את הסיסמה הישנה כגיבוי רק אם האתר לא מאפשר להסיר אותה, ובכל מקרה הפעילו שחזור דרך מכשיר שני ולא דרך SMS.
לבעל אתר: אם יש באתר כניסה של משתמשים, הוספת passkey כאפשרות (לצד הסיסמה, בשלב ראשון) היא השדרוג האבטחתי עם היחס הטוב ביותר בין מאמץ לתועלת. ספריות WebAuthn קיימות לכל שפת שרת נפוצה. מה שדורש מחשבה אמיתי הוא לא הקוד אלא ה-UX: איך מסבירים למשתמש מה זה, ומה קורה כשהוא מאבד מכשיר.
מה לא נבדק כאן
הסקירה מבוססת על המסמכים הרשמיים ועל שימוש יומיומי, לא על בדיקה מסודרת של כל צירוף דפדפן ומערכת. לא בדקנו שחזור מלא של חשבון אחרי אובדן כל המכשירים אצל ספק מסוים, ולא מדדנו זמני כניסה. אם מישהו מהקוראים עשה בדיקה כזו, נשמח לקבל את התוצאות.
