שוב, כשל דמיון, אם אתה מדמיין שהדלפת המפתח היא הדרך היחידה לזיין תהליך.
הם צריכים ליישם API כדי לאפשר למנהל סיסמאות של צד שלישי ליירט את אחסון המפתח הפרטי, או אפשר לפלאגין של צד שלישי להיות מאמת שלם - צור צמד מפתחות, הצהרת חתימה, אימות משתמש, וכו '
אם אפל מאפשרת לשמור רק מפתחות פרטיים ב-iCloud, אני אתקשה להמליץ על מפתחות סיסמה לקבוצת המשתמשים שמשתמשת באייפון ובמחשבי ווינדוס. האנשים האלה יתקעו ביצירת סיסמה אחת לכל מערכת אקולוגית ו/או בתקווה ששחזור החשבון יעבוד.
לקוח שרת זדוני <> אפליקציה אמיתית
השרת הזדוני יוצר קשר עם האפליקציה בשם הלקוח, מבקש את החתימה מהלקוח ואז מעביר אותה בחזרה לאפליקציה. הם לא צריכים את המפתח הפרטי כדי לעשות זאת, הם רק צריכים את האפליקציה כדי לבקש את המפתח והלקוח יגיב עם המפתח הנכון. מנגנון זה יכול, במידה מסוימת, להיות מופחת בצד השרת, אבל זה חל על סיסמאות ומפתחות סיסמה.
סוג ההתחזות שזה כן מונע הוא אתר קצירת האישורים הסטטי שמתיימר להיות דף התחברות אבל למעשה לא מעביר שום דבר לאתר האמיתי. וזה גם מפספס את הנקודה שהיא לפסקה הבאה שלך.
"נקודת שימוש" היא בזמן אמת. התקפות שידור חוזר הן נדירות וניתן למתן אותן בצד יישום האינטרנט. מלית אישורים אינה "נקודת שימוש" - היא משמשת בכל פעם שהתוקף רוצה להשתמש בה, לא הלקוח.
דיוג בהחלט נפוץ, מעולם לא אמרו שזה לא. אני אומר שעם גיבויי סיסמאות, מפתחות סיסמה לא עוזרים למתן את התקפות הדיוג האמורות מכיוון שהגיבוי נופל קורבן לאותה מתודולוגיית תקיפה כמו מנגנון האימות הישן.
מדינות לאום בהחלט מכוונות לתמיכה טכנית תוך התחזות לעובדים כדי לאפס מכשירים/MFA. אז אין לי מושג על מה אתה הולך כאן.
היה מודע לחלוטין שאתה סרקסטי. הגבתי בעגמת נפש מכיוון שאיש לא הראה את התוכנית להסיר סיסמאות (עד עמוד 14).
הם צריכים ליישם API כדי לאפשר למנהל סיסמאות של צד שלישי ליירט את אחסון המפתח הפרטי, או אפשר לפלאגין של צד שלישי להיות מאמת שלם - צור צמד מפתחות, הצהרת חתימה, אימות משתמש, וכו '
אם אפל מאפשרת לשמור רק מפתחות פרטיים ב-iCloud, אני אתקשה להמליץ על מפתחות סיסמה לקבוצת המשתמשים שמשתמשת באייפון ובמחשבי ווינדוס. האנשים האלה יתקעו ביצירת סיסמה אחת לכל מערכת אקולוגית ו/או בתקווה ששחזור החשבון יעבוד.
כן, ככה חשבון Houzz שלי יכול להיכנס רק דרך ה-Mac/iPhone שלי ולא מכשיר ה-Windows שלי :/
מכיוון שכאשר הלקוח חותם על דברים, הוא מחפש מאמת FIDO2 המבוסס על התחום של MITM. אם אם אין לו אחד, אתה לא מקבל אישור FIDO2. אם יש לו אישור FIDO2, הוא עדיין לא יתאים לזה שהשרת האמיתי מצפה לו, כי טוב, יש לו דומיין משלו. אז המפתח הציבורי שיש לו לא יתאים למפתח הפרטי המשמש לחתימה על דברים.
אז הוסף את מכשיר Windows שלך באמצעות Windows Hello. Edge, Firefox וכרום כולם תומכים בכך. זה אחד הדברים הבודדים שבהם Firefox מתעדכן - הם תומכים במפתחות ספציפיים לפלטפורמה באמצעות Windows Hello. עם זאת, לא מובטחת יכולת פעולה הדדית בין דפדפנים.
וזה מה שאני מנסה להסביר לך: יהיה קל לבצע אימות עם מכשיר קיים, ולהשתמש בזה מכשיר כדי להוסיף מפתח ציבורי אחר, שנוצר במכשיר אחר, חדש, ונשלח למכשיר הישן על ידי אומר. לדוגמה, אני יכול ליצור מפתח סודי / מפתח ציבורי חדש במחשב השולחני שלי, לשלוח את המפתח הציבורי למחשב הנייד שלי, להיכנס עם המחשב הנייד שלי ולהוסיף את המפתח הציבורי של שולחן העבודה. אני עושה דברים דומים עם SSH כל הזמן.
אין כאן שום מכשול טכני. אם זה לא אפשרי עם מפתחות סיסמה, אז זה מבחירה.
למעט אנדרואיד, די חראתי בגוגל מהחיים שלי. הסיבה היחידה שלי לחשבון Google הן אפליקציות ועדכונים בחנות Play. זהו זה.
לקוח שרת זדוני <> אפליקציה אמיתית
השרת הזדוני יוצר קשר עם האפליקציה בשם הלקוח, מבקש את החתימה מהלקוח ואז מעביר אותה בחזרה לאפליקציה. הם לא צריכים את המפתח הפרטי כדי לעשות זאת, הם רק צריכים את האפליקציה כדי לבקש את המפתח והלקוח יגיב עם המפתח הנכון. מנגנון זה יכול, במידה מסוימת, להיות מופחת בצד השרת, אבל זה חל על סיסמאות ומפתחות סיסמה.
גם אם יש לך מפתח סיסמה שונה לשרת הזדוני, תחתום על טענה עם ה-nonce של השרת הזדוני, שאפליקציית True תדחה מכיוון שיש לה מפתח ציבורי אחר.
הרבה מהאבטחה של זה נובעת מהעובדה שלעולם לא נעשה שימוש חוזר בצמדי מפתחות - הם תמיד נוצרים חדשים עבור כל שרת.
פרוטוקולי FIDO משתמשים בטכניקות הצפנה סטנדרטיות של מפתח ציבורי כדי לספק אימות חזק יותר ותוכננו מהיסוד כדי להגן על פרטיות המשתמש.
fidoalliance.org
"המכשיר משתמש במזהה החשבון של המשתמש שסופק על ידי השירות כדי לבחור את המפתח הנכון ולחתום על האתגר של השירות."
האם המזהה מסופק על ידי השירות או שהוא נקרא על ידי הלקוח? כי אם זה עובד כמו שאתה אומר אז כן אני מסכים, אבל בתיעוד של FIDO הבנתי שזה אומר שהשירות שולח את הנתונים עבור איזה מפתח להשתמש - ובמקרה זה MITM עדיין יעבוד.
אגב, ניסיתי את ההדגמה ב-passkeys.io, גם Firefox וגם Vivaldi ב-Manjaro רוצים שאחבר מפתח אבטחה. אם זו מגבלה של הדפדפנים או ההדגמה, אני לא בטוח.
תודה! זה צריך להיות במאמרים שמדברים על סיסמאות, לא בעמוד 14 של קטע הערות.
אני לא משתמש ב-Windows Hello מכיוון שהוא שולחן עבודה ואני לא משתמש במצלמת אינטרנט.
עכשיו כשיש לך את המידע, האם אתה מתכוון לפרסם כיצד הצעקות שלך היו שגויות או מידע מוטעה?
Windows Hello יכול להשתמש ב-PIN, בסורק טביעות אצבע (אפילו ב-USB, יש לי כמה מרחפים סביבי איסוף מאמזון תמורת 25 דולר או משהו כזה), או מפתח חומרה (אז יש יתירות מסוימת עַל... במקום להשתמש במפתח החומרה ישירות...)
למעשה אני מנסה למצוא את המפרט דרך גוגל כבר די הרבה זמן וללא הועיל. כנראה בגלל שהמפרט חסר SEO ואף אחד מהפוסטים בבלוג לא מתייחס למפרט.
פרוטוקולי FIDO משתמשים בטכניקות הצפנה סטנדרטיות של מפתח ציבורי כדי לספק אימות חזק יותר ותוכננו מהיסוד כדי להגן על פרטיות המשתמש.
fidoalliance.org
"המכשיר משתמש במזהה החשבון של המשתמש שסופק על ידי השירות כדי לבחור את המפתח הנכון ולחתום על האתגר של השירות."
האם המזהה מסופק על ידי השירות או שהוא נקרא על ידי הלקוח? כי אם זה עובד כמו שאתה אומר אז כן אני מסכים, אבל בתיעוד של FIDO הבנתי שזה אומר שהשירות שולח את הנתונים עבור איזה מפתח להשתמש - ובמקרה זה MITM עדיין יעבוד.
האם זה מבוסס על ספקולציות, או שאתה יכול להצביע על משהו מ-FIDO שתומך בטענות שלך שהמפתח הפרטי זמין במהלך אימות ורישום? הדרך שבה אני קורא את המפרט של WebAuthn, הפוסט שלך שזוכה להצבעות, שגוי ב-100%. האופן שבו אני קורא את המפרט של הטלפון או מכשיר אחר המאחסן את המפתח הפרטי פשוט מוכיח שיש לו את המפתח הפרטי (אולי על ידי מענה לאתגר מהספק עם המפתח הציבורי שלך?). הדבר היחיד שהשרת מוציא מהעסקה הוא איזשהו אימות קריפטוגרפי שהמפתח הפרטי תקף. המפתח הפרטי נשאר ב-100% במכשיר במהלך העסקה הזו. כך מתרחש האימות מבלי שהמפתח הפרטי יעזוב את המכשיר אי פעם (למעט כפי שכבר צוין כבלוב E2EE המסונכרן למכשירים המהימנים של המשתמש).
למעשה אני מנסה למצוא את המפרט דרך גוגל כבר די הרבה זמן וללא הועיל. כנראה בגלל שהמפרט חסר SEO ואף אחד מהפוסטים בבלוג לא מתייחס למפרט.
טוב שמאמתי FIDO2 אינם התקני אחסון USB. אני חושב שהם USB-HID. זה שמחובר למחשב הנייד שלי עכשיו בהחלט נראה שכן.
למעשה אני מנסה למצוא את המפרט דרך גוגל כבר די הרבה זמן וללא הועיל. כנראה בגלל שהמפרט חסר SEO ואף אחד מהפוסטים בבלוג לא מתייחס למפרט.
עכשיו למה שיעצבו מפרט אבטחה ככה? ברצינות? מאות אנשים במספר תאגידי אינטרנט גדולים עבדו על זה במשך שנים, אבל הנה ג'ארקס מהאינטרנט מי יכול לזהות את הבעיה, אפילו בלי לקרוא אף אחד מהמסמכים (מכיוון שלא הצליחו למצוא אותם באמצעות חיפוש מנוע).
מגניב, לא ידעתי ש-PIN עובד. חשבתי שהלו תמיד קשור לביומטריה, מה שלא היה לי במחשב הזה.
לא בטוח שאני עוקב - אם השרת הזדוני לוקח את ההודעה של האפליקציה, מעביר אותה ללקוח (כי הוא מתיימר להיות האפליקציה שרת זדוני) ואז לוקח את תגובת החתימה של הלקוח ומעביר אותה לאפליקציה, מה מונע מזה לקרות ב תַרחִישׁ? בתרחיש השרת הזדוני לא צריך את המפתח הפרטי (לא צריך לחתום על שום דבר), הוא רק צריך לשחק יד-אוף בין הלקוח לאפליקציה.
אני הולך לעצור אותך כאן. בפעם הראשונה והמיליון, אם גוגל ומיקרוסופט וגוגל ו-1Password et al. כל מחק את מפתח הסיסמה שלך, אתה פשוט נכנס לחשבון Google שלך באמצעות הסיסמה שלך. כל הסיכון להינעל בחוץ שהיה לך בעבר באמצעות סיסמאות הוא בדיוק אותו סיכון שאתה מתמודד כשאתה שומר מפתח סיסמה. יש עלייה אפסית לחלוטין. בבקשה תפסיקו לחזור על שטויות.
כעת, לאחר שביקרתם את ה-SEO הגרוע של מפרט WebAuthn, האם תאמר בבקשה אם אתה מתכנן לתקן את עצמך בפומבי?
אממ, פשוט עברתי על כל המאמרים ואף אחד מהם לא מסביר איך זה מונע התקפות MITM. אם יש לי אתר אינטרנט ואני מרמה אותך לבקר בו, אני לא רואה סיבה לכך שזה לא יהיה רגיש להתקפות MITM.