לדלג לתוכן

Passkeys ו-WebAuthn מוסברים - הסוף של הסיסמאות

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

הבעיה שסיסמאות אף פעם לא באמת פתרו

סיסמאות סובלות מבעיה מובנית: הן סוד משותף (shared secret) - גם אתם וגם השרת "יודעים" את הסיסמה (או לפחות את ה-hash שלה). זה אומר שאם השרת נפרץ ומאגר הסיסמאות דולף, או אם אתם עצמכם נופלים קורבן לפישינג ומוסרים את הסיסמה לאתר מזויף, התוקף מקבל בדיוק את מה שהוא צריך כדי להתחבר בשמכם. אימות דו-שלבי (2FA) שיפר את המצב, אבל לא פתר אותו לגמרי - קודי SMS ניתנים ליירוט, וגם קודי אימות מבוססי אפליקציה עדיין ניתנים להעברה על ידי מועמד שמשכנע אתכם "להקריא" אותם בשיחת Vishing.

המהפכה - קריפטוגרפיה אסימטרית במקום סוד משותף

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

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

למה זה עמיד בפני פישינג בצורה שסיסמה לעולם לא תהיה

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

איך זה עובד בפועל מבחינת המשתמש

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

מה זה אומר מבחינת מפתחים

אם אתם בונים אפליקציות ורוצים ליישם Passkeys, ה-API הרלוונטי הוא WebAuthn - ממשק שהדפדפן חושף, שמאפשר לאתר לבקש יצירת Passkey חדש (registration) או אימות מול Passkey קיים (authentication). מבחינת אבטחת השרת, זה אומר שאתם צריכים לאחסן רק מפתחות ציבוריים - הרבה פחות רגיש מאחסון hash-ים של סיסמאות, ומקטין דרמטית את הנזק הפוטנציאלי אם מסד הנתונים שלכם דולף. ההטמעה בפועל דורשת הבנה טובה של אימות ואותנטיקציה בכלל - אם אתם עדיין לא מכירים את היסודות של Session מול JWT, כדאי להתחיל שם לפני שקופצים ל-Passkeys.

תכירו את קורס פיתוח צד שרת שלנו כאן

האם זה אומר שסיסמאות נעלמות מחר

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

לסיכום

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

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

הצטרפו לקהילה בדיסקורד