שני שלבים אינם בהכרח שני גורמים: סיסמה ו־PIN הם שניהם ידע. ביומטריה יכולה להפעיל אמצעי אימות, אך לבדה אינה מבטיחה אנונימיות או עמידות לדיוג.
להשוות מנגנונים ולא מסכים
NIST מבחין בין ידע, החזקה ומאפיינים ביומטריים. אפשר להעביר קוד חד־פעמי מוקלד דרך אתר מתחזה; לכן SMS ו־TOTP אינם שקולים לאימות עמיד לדיוג. מפתח גישה המיושם כראוי קושר את התגובה לשירות. ההגנות תלויות גם באימות המקומי ובתנאי הגיבוי והסנכרון.
להבין את תפקיד הביומטריה
ב־WebAuthn זיהוי ביומטרי יכול להתבצע בתוך אמצעי האימות; הנתונים הביומטריים אינם נשלחים לשירות האינטרנט המקבל. אימות מקומי עשוי להשתמש גם ב־PIN. נוכחות משתמש (UP) ואימות משתמש (UV) שונים. על השרת לבדוק את התגובה לפי הפרוטוקול; מסך זיהוי פנים אינו מספיק.
להגן על מחזור החיים
לתכנן רישום, הוספת שיטה, אובדן מכשיר, ביטול ושחזור חשבון. לבחון נגישות וחלופות העלולות להחליש את מסלול הכניסה הראשי. אימות זהות אינו מחליף הרשאות למידע ולפעולות.
מקורות
בדיקה עריכתית: 1 בנובמבר 2026.
הפרדת גורם שני מעמידות לפישינג
NIST מציין כי קוד חד פעמי שהוזן ידנית יכול להיות מועבר על ידי דף מתחזה, כך שנוכחותו לבדה אינה הופכת כניסה לעמידה בפני פישינג. WebAuthn משולב כראוי קושר את התגובה לשירות המקורי. שחזור חשבון נותר נתיב לאבטחה.
- רשימת יישומים שעדיין מקבלים SMS, קודים או אישורים הניתנים לעקיפה ותעדוף חשבונות בעלי זכויות יוצרים.
- בדיקת הרשמה, אובדן מכשירים וביטול באמצעות מסע משתמש אמיתי.
- מדוד כיסוי גורמי עמידות ושמור חריגים מעודכנים עם הבעלים.
מקור ראשוני: NIST SP 800-63B-4. שיטה קשורה: קריאת המדריך המעשי.
Passkeys: הכנה לשינוי דומיין ו־RP ID
להפריד בין חשבון, מקור אינטרנט ו־RP ID כדי למנוע קישור מחדש שקט של פרטי הזדהות.
- תעדו מקורות ישנים וחדשים, RP ID וחשבונות קשורים. שם חשבון זהה אינו הופך passkey לתקף עבור RP ID אחר. בדקו צירופים מותרים ב־WebAuthn ונתיבי גישה זמינים בזמן המעבר.
- בסביבת בדיקה מורשית בדקו challenge, מקור, RP ID ושיוך חשבון בספרייה מתאימה. נסו מקור לא צפוי ואתגר חוזר. שינוי RP ID דורש רישום חדש לאחר אימות; העתקת שורה אינה מעבירה מפתח.
- בדקו משתמש עם פרטי הזדהות ישנים בלבד, שחזור וסשנים פתוחים. קבעו פתיחת נתיבים וסגירתם עם חזרה שנבדקה. רישום בדומיין חדש אינו מוכיח ביטול כל הסשנים הישנים.
מקרה קבלה שניתן לשחזר
דוגמה בדיונית: הנתונים אינם מתארים לקוח או תוצאה שנצפתה.
הצגת נתוני המקרה
{
"old_origin": "https://login.old.example",
"old_rp_id": "old.example",
"new_origin": "https://login.new.example",
"new_rp_id": "new.example",
"same_service_account": true,
"expected": "authenticated_new_registration"
}החלטה צפויה
דוגמה בדיונית: החשבון זהה, אך old.example נעשה new.example עם RP ID אחר. אין לקשר מחדש בשקט את פרטי ההזדהות הישנים; הרישום החדש עובר בנתיב האימות המתוכנן.
האם שינוי במסד יכול לשנות RP ID של passkey?
לא. RP ID הוא חלק מהתחום המאומת של פרטי ההזדהות. הכינו רישום תקף בתחום החדש ושיוך חשבון לאחר אימות.
מקור ראשוני: W3C — Web Authentication Level 2. שיטה קשורה: קריאת המדריך המעשי.
postMessage: לבדוק מקור, חלון ופקודה
להגדיר חוזה הודעות ל־iframe או לחלון קופץ הדוחה שולחים ונתונים לא צפויים.
- רשמו origins מדויקים, חלון צפוי וסוגי הודעות. השתמשו ב־targetOrigin מדויק לנתונים רגישים. origin כולל פרוטוקול, מארח ופורט; חיפוש מחרוזת חלקית בשם דומיין אינו מאמת שולח.
- השוו event.origin ובשילוב זה event.source לחלון הצפוי. בדקו מבנה, ערכים מותרים ומצב פעולה. התייחסו לתוכן כנתונים בלי eval או הזרקת HTML. מקור מאושר אינו מחליף הרשאה בשרת.
- בדקו דומיין דומה, פורט אחר, חלון אחר מאותו origin, שדות לא תקינים והודעות לאחר סגירה. הסירו מאזינים מיותרים ובטלו חילופים שהסתיימו. השיבו ל־origin שאושר מראש גם לאחר ניווט החלון.
מקרה קבלה שניתן לשחזר
דוגמה בדיונית: הנתונים אינם מתארים לקוח או תוצאה שנצפתה.
הצגת נתוני המקרה
{
"allowed_origin": "https://widget.example",
"observed_origin": "https://widget.example",
"expected_window": "active_iframe",
"observed_window": "another_window",
"payload_schema_valid": true,
"expected": "reject_without_effect"
}החלטה צפויה
דוגמה בדיונית: https://widget.example מאושר אבל event.source הוא חלון אחר. החוזה דורש את חלון ה־iframe הפעיל: דחו בלי פקודה.
מקור ראשוני: MDN — Window.postMessage. שיטה קשורה: קריאת המדריך המעשי.
זהות: גורמים, הפעלות ושחזור
שני גורמים: לבדוק את הפרוטוקול מעבר לממשק
קודים מוקלדים, אישורי push ותגובות WebAuthn קושרים את הכניסה לשירות באופן שונה. ביומטריה יכולה להפעיל אמצעי אימות, אך אינה מחליפה בדיקה קריפטוגרפית של התגובה.
- הפעלה מקומית — PIN או ביומטריה לפי אמצעי האימות.
- חתימת תגובה — מפתח תחום לשירות ואתגר שהתקבל.
- בדיקה בשרת — אתגר, מקור, חתימה ודגלים.
- הרשאת פעולה — זכויות לאובייקט ולפעולה.
- לבחון UP ו־UV בנפרד.
- לבדוק דרישות סנכרון ואי־יכולת ייצוא הנחוצות בפועל.
- לתרגל אובדן והוספת שיטה מתוך הפעלה קיימת.
המקורות נבדקו בתאריך · NIST SP 800-63B-4 · final publication NIST · Authenticator Event Management W3C · WebAuthn Level 3
תוספים: הרשאות וגישה
הערות המקורות המפורטות זמינות באנגלית במהדורה זו.
Robust authentication does not describe extension access
Phishing resistance does not remove the need to examine what runs in the browser after a session opens. A manifest provides clues about cookies, scripting, debugging and identity without establishing collection.
- Test approved extensions in a profile dedicated to sensitive operations.
- For identity, inspect OAuth scopes and recipients; this permission does not enumerate identity-provider rights.
- Distinguish session revocation, token revocation, extension disablement and native-component removal.
Read the permission directory and manifest examples →
Google Chrome · Stay secure · Documentation consulted 2026-10-23; browser behaviour remains version-dependent