Passkey או SRP? שיטות כניסה וגבולות אמון

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

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

מה משנה passkey?

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

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

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

מה נותן SRP לשרת?

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

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

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

השוואה הוגנת

שאלה	Passkey	SRP
האם המשתמש זוכר סיסמה לשירות?	בדרך כלל לא; נדרשת שליטה באמצעי ההזדהות	כן, השיטה מבוססת על ידיעת הסיסמה
מה שומר השירות לצורך הכניסה?	מפתח ציבורי ומידע קשור	ערך אימות ופרמטרים קשורים
כיצד מושגת עמידות לדיוג?	קשירת אמצעי ההזדהות לשירות/למקור בתכנון FIDO	אי־שליחת הסיסמה בפרוטוקול אינה מספיקה כדי להפוך שדה קלט מזויף לבטוח
האם הענן הכרחי?	לא; קיימות גם אפשרויות הקשורות למכשיר	הפרוטוקול אינו דורש מעצם טבעו ספק זהות חיצוני, אך דורש שירות אימות
כיצד מתבצע השחזור?	תלוי בסוג אמצעי ההזדהות ובספק	מדיניות החשבון והמוצר קובעת זאת, לא השם SRP

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

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

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

בתיעוד האבטחה של Livara, SRP מתואר לצורך כניסה, וחבילת השחזור v7 לזהות המוצפנת מוצגת בנפרד. החבילה משחזרת את הזהות, לא את היסטוריית הצ׳אט. לכן, ״סיסמת הכניסה נכונה״ אין פירושו ש״כל המפתחות וההודעות הישנות חזרו״.

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

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

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

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