פיתוח אימות ביומטרי (Touch ID) באפליקציית iOS

למה Touch ID באפליקציית iOS מפסיק להכניס משתמשים

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

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

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

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

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

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

מה משתנה אחרי הטמעת כניסה ביומטרית

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

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

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

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

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

מצבי Touch ID והביומטריה המערכתית: השוואת גישות

הביומטריה המערכתית של המכשיר היא בדיקת הבעלים בצד מערכת ההפעלה: האפליקציה לא מקבלת את טביעת האצבע עצמה, אלא רק אישור "שלנו או זר".

לכן בחירת מצב הכניסה היא בראש ובראשונה שאלה של מה לעשות כשהביומטריה אינה זמינה: החיישן לא עבד, האצבע לחה, נתוני הביומטריה במערכת נכתבו מחדש או כובו. להלן שלוש סכמות עבודה והמחיר שלהן.

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

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

שלבי ההטמעה: מביקורת הכניסה ועד מסירה לתמיכה

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

1. ביקורת הרשאה. עוברים על תרחישי הכניסה ושחזור הגישה הקיימים: תוקף המושב, עבודה בכמה מכשירים, טיפול ביציאה. מקבלים מפה של המקומות שבהם Touch ID משתלב בלי סיכון לשאר הלוגיקה.
2. סכמת הכניסה באפליקציה. קובעים מה בדיוק מאשרת טביעת האצבע: זהו מנעול מקומי למפתח במאגר המאובטח של המכשיר, והשרת ממשיך לבדוק את המושב. כניסה בביומטריה אינה הופכת לחור נפרד.
3. רישום וקישור מחדש. מתארים הפעלה של הביומטריה, התנהגות בעת הוספת טביעת אצבע חדשה — המערכת מבטלת את המפתח — ונסיגה תקינה להזנת סיסמה.
4. הגדרת הביומטריה. מממשים בקשת גישה, טיפול בסירוב ובאי-זמינות של החיישן, הודעות ברורות במקום שגיאות מערכת.
5. בדיקה במכשירים. מריצים תרחישים על מגוון מכשירים: דגמים עם ביומטריה ובלעדיה, סירוב בגישה, איפוס הגדרות, התקנה מחדש, החלפת מכשיר. מודדים את שיעור הכניסות המוצלחות.
6. מסירה לתמיכה. מוסרים תיעוד של התרחישים, סכמת הנסיגה ושלבי אבחון, כדי לא ללמד את הקו הראשון על פניות חיות.

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

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

• תיאור תרחישי הכניסה — כניסה ראשונה, הוספת טביעת אצבע שנייה, החלפת מכשיר: איזה שלב עובר להזנת סיסמה ואיזה ל-Touch ID ולמה.
• סכמת מצבי הכניסה — המעברים בין "לא מורשה", "הביומטריה אינה זמינה", "המושב פג"; איפה נשמר מפתח הגישה ומה קורה ביציאה מהחשבון.
• כללי שלילת גישה — אובדן מכשיר, פיטורי עובד, חסימה במערכת החשבונות: באיזו בקשה נשללים המפתחות ובתוך איזה פרק זמן המושב מפסיק לעבוד.
• תיעוד ההרשאה — נקודות האינטגרציה עם השרת, טיפול בשגיאות, התנהגות בהיעדר רשת ובסירוב החיישן.
• נהל התמיכה — מה בודק המהנדס התורן בתלונה על כניסה, אילו אירועים בלוגים הוא בוחן ואילו שלבי שחזור הוא מבקש מהמשתמש.
• צ'ק-ליסט לפני שחרור — בדיקות חובה, כדי שעדכון ממשק או תלויות לא ישבור את הכניסה לפי טביעת אצבע.
• תסריטים לקו הראשון — תשובות קצרות לפניות טיפוסיות: הביומטריה אינה מוגדרת, טביעת האצבע אינה מזוהה, הגישה חסומה.

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

מקרה בוחן: כניסה ביומטרית באפליקציה לפני ואחרי

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

לפני: כניסה כמשימה נפרדת

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

אחרי: כניסה בנגיעה אחת

זמן הכניסה הצטמצם ל-2-3 שניות, שיעור הניסיונות המוצלחים עלה ל-97%. הפניות לתמיכה בנושא כניסה וסיסמה ירדו בערך פי שלושה, וסירובים מסוג "הקוד לא הגיע" חדלו להתקיים כסוג — התרחיש נעלם יחד עם שלב מסירת הקוד.

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

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

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

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

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

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

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

ספקות טכניים נפוצים בנוגע לביומטריה ולכניסה

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

איך מתנהגת הכניסה עם כמה חשבונות?

הקישור נעשה לצמד "חשבון + מכשיר", ולא לטביעת האצבע: בטלפון אחד אפשר להחזיק שני פרופילי עבודה, שלכל אחד רשומה משלו וטוקן משלו. המעבר — בחירת רשומה אחרת וקישור מחדש בכניסה הראשונה; הביומטריה נשארת מערכתית ומשותפת.

מה קורה אחרי נעילה או אתחול של המכשיר?

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

מה עם פרטיות ובדיקות בעת הפרסום?

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

נדון במשימה: נתאים סכמת כניסה לתרחיש שלכם

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

להתחלה די לשלוח:

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

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