שאלות נפוצות

כללי

מי תומך במפתחות גישה?

מפתחות גישה מבוססים על תקני FIDO, ולכן הם פועלים ב-Android וב-Chrome, וגם במערכות אקולוגיות ובדפדפנים פופולריים רבים אחרים כמו Microsoft Windows,‏ Microsoft Edge, ‏ macOS, ‏ iOS ו-Safari.

במאמר סביבות נתמכות אפשר לבדוק את סטטוס התמיכה ב-Chrome וב-Android.

האם מפתחות גישה פועלים במכשירים שלא מוגדרת בהם שיטה לביטול נעילת המסך?

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

איך אפשר להשתמש במפתחות גישה שנרשמו בפלטפורמה אחת (כמו Android) כדי להיכנס לחשבון בפלטפורמות אחרות (כמו אינטרנט או iOS)?

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

האם אפשר להעביר מפתחות גישה מסונכרנים מספק פלטפורמה אחד לספק אחר?

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

האם משתמש יכול לסנכרן את מפתחות הגישה שלו במכשירי Android שאינם של Google?

מפתחות הגישה מסתנכרנים רק בתוך הסביבה העסקית של המכשיר (כלומר, מ-Android ל-Android עם מנהל הסיסמאות של Google כברירת מחדל), אבל לא בין סביבות עסקיות שונות.

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

מה מפתחים צריכים לעשות לגבי מכשירים ופלטפורמות שלא תומכים במפתחות גישה?

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

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

לא. זה תלוי בספק שמאחסן את מפתחות הגישה וב-RP (צד שלישי), אבל אין שיטה נפוצה להגדרת תפוגה למפתחות גישה.

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

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

מפתחות גישה ב-Android וב-Chrome

האם אפליקציות ל-Android יכולות להשתמש במפתחות גישה שנוצרו ב-Chrome לאימות?

  • למפתחות גישה שנוצרו ב-Chrome ב-Android:

    כן, מפתחות הגישה שנוצרו ב-Chrome נשמרים ב'מנהל הסיסמאות של Google' וזמינים ב-Android, ולהפך, כשהמשתמשים מחוברים לאותו חשבון Google.

  • למפתחות גישה שנוצרו ב-Chrome בפלטפורמות אחרות:

    אם מפתח הגישה נוצר ב-Chrome בפלטפורמות אחרות (Mac, ‏ iOS, ‏ Windows), התשובה היא לא. מידע נוסף זמין במאמר בנושא סביבות נתמכות. בינתיים, המשתמשים יכולים להשתמש בטלפון שבו הם יצרו את מפתח הגישה כדי להיכנס לחשבון.

מה קורה לפרטי הכניסה שנוצרו לפני שהוצגו מפתחות הגישה? האם אפשר להמשיך להשתמש בהם?

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

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

מפתחות גישה שנוצרו ב-Android מגובים ומסונכרנים עם מכשירי Android שמחוברים לאותו חשבון Google, באותו אופן שבו סיסמאות מגובות למנהל הסיסמאות.

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

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

מספיקה שיטה אחת לביטול הנעילה.

האם מפתח גישה קשור לשיטה ספציפית לביטול הנעילה, כמו טביעת אצבע, קוד אימות או קו ביטול נעילה?

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

האם צד שלישי יכול ליצור פרטי כניסה שקשורים למכשיר ולא מסונכרנים?

בשלב הזה, פרטי כניסה שלא ניתן לגלות שנוצרו ב-Chrome ב-Android או באפליקציית Android באמצעות ממשקי ה-API של Play Services, ממשיכים להתנהג כמו קודם, ולכן הם עדיין קשורים למכשיר.

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

איך עובד סנכרון של מפתחות גישה למכשיר חדש? האם המשתמשים צריכים גישה למכשיר שבו הם יצרו מפתח גישה?

ב-Android:

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

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

פרטיות ואבטחה

האם המידע הביומטרי של המשתמש מאובטח?

כן, נתונים ביומטריים של משתמשים אף פעם לא נשלחים מהמכשיר ואף פעם לא נשמרים בשרת מרכזי שבו הם עלולים להיגנב בפריצה.

האם משתמש יכול להיכנס למכשיר של חבר באמצעות מפתח גישה בטלפון שלו?

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

האם מפתחות גישה שמאוחסנים במנהל הסיסמאות של Google מוגנים אם חשבון Google של משתמש נפרץ?

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

איך מפתחות גישה בהשוואה לאיחוד שירותי אימות הזהות?

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