אני לא רואה איך זה יפתור דיוג בחנית עם התקפות שידור חוזר של סיסמאות. רוב הדיוג MITM פשוט משמיע מחדש את הקלט לשרת ומחזיר את הפלט לקורבן, בדרך כלל עם הפניה מחדש בסוף. סוגי התקפות אלה עדיין פועלים גם נגד מכשירי TOTP MFA, כך שאלו לא באמת ההתקפות שאנשים מנסים למנוע כאן.fvgfvghvgv אמר:דיוג ודיוג בחנית כבר לא מהווה בעיה מכיוון ש-HTTPS נמצא כמעט בכל מקום?כמו כן (תדירות נמוכה בהרבה, אבל תאמינו לי שזה תדירות עצומה עבור מדינות לאום) כל הצורות השונות של לוגרי מפתחות מרוחקים מוגנות על ידי HTTPS? באופן אישי, אם הייתי פרנואידית לגבי ממוקד בדרך זו וצריך להיכנס לגוגל במחשב חדש, מעדיף לכוון את הטלפון שלי לקוד QR על המסך למשך 2 שניות, מאשר להקליד לאט סיסמה חזקה על מקלדת.
ובהקשר של מאמר זה, האם אתה באמת חושב שגוגל מאחסנת את האישורים של חשבון Google שלנו במסד נתונים חשוף לא מוצפן?
אני מסכים איתך ב-100% ששיפור לטווח ארוך יותר יהיה החלפה מלאה של סיסמאות במפתחות, כדי לסגור את החולשות מדור קודם במערכת הסיסמאות.
הנה ההצעה שלי איך אנחנו מגיעים לשם: לשלב 1 שחקן מקוון גדול בכל מקום צריך לעשות השקה מקבילה של מפתחות סיסמה לצד סיסמאות כהדגמה בעולם האמיתי כדי לקבל מומנטום, ואז לשלב 2 כל מחזיק המפתחות בענן ומנהל הסיסמאות של צד שלישי חברות צריכות לדון כיצד לשפר את יכולת הפעולה ההדדית וספקי מערכת ההפעלה והדפדפנים צריכים ליישם בו-זמנית מפתחות סיסמה מערכות. זה ישקף את סיפור ההצלחה עם HTTPS ואת יתרונות האבטחה שהוא הביא לאקוסיסטם.
בשלב ידוע מוקדם בתוכנית זו, arstechnica יכולה לכתוב מאמר על מה עובד/מה לא/מה מתוכנן בעתיד...
לחץ להרחבה...
אם אנחנו מדברים על שחקני מדינת לאום, הם פשוט הולכים למקד את התמיכה הטכנית של כל מה שהם רוצים גישה אליו, אז לדון בטכנולוגיה כדי למנוע את זה הוא חסר משמעות.
ולא, מעולם לא אמרתי שגוגל מאחסנת סיסמאות במסד נתונים לא מוצפן. לא כך מתרחשות התקפות מילוי אישורים. בדרך כלל אנשים עושים שימוש חוזר בסיסמאות במספר מיקומים והאתרים החלשים יותר חושפים את אותן סיסמאות שהיו בשימוש באתרים שלוקחים את הקצה האחורי שלהם בצורה מאובטחת יותר.
אני מסכים עם ההצעות שלך להפצה, עם אזהרה אחת - למעשה פרסם מסמך לבן שלא מתעסק בו תיאורטיות כמו ה-FIDO הטוענת שלמשתמשים "כנראה" יהיה מכשיר שני לשחזר אם המכשיר הראשון שלהם אבוד. ואותו נייר לבן זה גם לא אמור להציע רק שסיסמאות משמשות כחלופה לחדשות מכשירים, הוא צריך למעשה לנסח את התוכנית להסרה מלאה של סיסמאות -- כי זו המטרה הסופית ימין? אנחנו צריכים לדעת את הצעדים שאנחנו הולכים לנקוט לפני שנגיע לשם.
השבתתי את BT כדי לראות מה יקרה, ובאמת, גוגל התלוננה שהיא לא מצליחה להגיע לטלפון שלי... והציעו לי להפעיל את BT. זה, לפחות, לא עבד. עדיין. (אני מניח את זה עושה עובד כך ב-Windows, ואולי גם ב-MacOS.)
להיות מְאוֹד ברור, שוב, זה לא קשור למפתחות עצמם; כסטנדרט אימות, הם בסדר. אני פשוט לא מאוהב במידת השליטה של הדפדפן על החומרה שלי (כי ככל שיש לו יותר שליטה, כך יש יותר שליטה לתוקף בעל הדפדפן).
אתה שוב מבלבל את עצמך. אף אחד מהציטוטים לא מרמז על מחיקת סיסמאות. אני מקווה שהם אכן מוחקים סיסמאות לחשבונות שלהם בשלב מסוים, אבל זה מציאותי עשרות שנים בעתיד אם זה יקרה אי פעם, ברגע שרוב מקרי הקצה נפתרו או נעלמו וכאשר רוב שאר האינטרנט הפך את המפתחות לכל מקום אוֹפְּצִיָה.ג'ארקס אמר:כן אחי, לגמרי:מאת: Arnar Birgisson ודיאנה K Smetters, Identity Ecosystems וצוותי אבטחה ובטיחות של חשבון Google החל מהיום, אתה יכול ליצור...
security.googleblog.com
שני מפתחות הסיסמה הם חלופה מצוינת ומאובטחת יותר לסיסמאות - במקרה זה לגוגל יש את כל הסיבות לנסות להסיר סיסמאות. לחלופין, מפתחות סיסמה הם רק אלטרנטיבה פשוטה שלמעשה לא עושה שום דבר כי יש סיסמה חוזרת שניתן להשתמש בה לאותו אימות בדיוק.אם זה הראשון, אז למה אתה מנסה לטעון שגוגל לא דוחפת סיסמאות החוצה (כפי שהבלוגים המרובים שלהם מרמזים בבירור שיהיו בעתיד).
אלא אם כן, כי לאף אחד אין תשובה לגבי איך הם עושים את זה כי עדיין יש להם סיסמה חוזרת וממש אפס מהמסמכים של FIDO, אומרים בבלוגים של גוגל, אפל משהו לגבי האופן שבו הם הולכים ליישם fallback ללא סיסמאות שאתה מודע באופן לא מודע לכך שהם לא יכולים לדבר על הסרת סיסמה לסגת. במקרה זה, אני מפנה אותך לנקודה המקורית שלי, שהיא שמפתחות סיסמה הם חסרי תועלת עם סיסמה שנייה.
לחץ להרחבה...
תראה כמה זמן לוקח להפעיל את 2FA עבור יותר מחלק קטן מהאינטרנט העמוק!
אז כן, אני חושב שכמה פוסטים בבלוג של גוגל אומרים "מכשירים רבים אינם תומכים עדיין במפתחות סיסמה" ו"נחיל בדיקה מדוקדקת יותר לפעילות התחברות לסיסמה כי אנו מאמינים שאלו הם החוליה החלשה"
אינו זהה ל:
"אנחנו מתכננים למחוק את הסיסמאות של חשבון Google של כולם בעתיד הקרוב"
בעיה גדולה נוספת היא בעיה שאני כבר צריך להתמודד איתה עם 2FA (אם כי אני משתמש ותומך ב-2FA באופן כללי) - אני עושה הרבה תמיכה טכנית לאנשים מבוגרים, ולפעמים צריך לעשות דברים מרחוק, בשמם. עם 2FA קשה מאוד להיכנס לחשבון של מישהו אחר (גוגל וכו') כדי לשנות הגדרה, לחפש משהו, לעזור לו לשחזר או לאפס סיסמה וכו'. זה כמובן מכוון ובדרך כלל דבר טוב, אבל זה מסבך את התמיכה הטכנית. מפתחות סיסמה נראים אפילו גרועים יותר למטרה זו מ-2FA, מכיוון שלפחות עם 2FA אני יכול להתקשר אליהם ולבקש ממני לקרוא קוד שמוצג בטלפון שלהם, או להגיד להם להקיש על כל הנחיה שמוצגת.
כמובן שהם לא מתכננים למחוק את הסיסמאות של כולם בזמן הקרוב. כי הם לא יודעים איך להיפטר מגיבויים של סיסמאות. אבל ההודעות של הכותרות שלהם "שלום סיסמאות, תודה על כל הדיוגים" ו"אולי הבא יום הסיסמה, לא תצטרך לזכור את הסיסמה שלך!" הם בעלי משמעות רבה לכך שבעצם לא צריך סיסמאות. מה שמהווה חוסר שירות למשתמשים ונותן את ההשלכה השקרית שמפתחות סיסמה מאובטחים יותר מסיסמאות, אפילו כשגיבויים מבוססי סיסמאות מסוגלים לעשות 100% ממה שמפתחות יכולים לעשות.fvgfvghvgv אמר:אתה שוב מבלבל את עצמך. אף אחד מהציטוטים לא מרמז על מחיקת סיסמאות. אני מקווה שהם אכן מוחקים סיסמאות לחשבונות שלהם בשלב מסוים, אבל זה מציאותי עשרות שנים בעתיד אם זה יקרה אי פעם, ברגע שרוב מקרי הקצה נפתרו או נעלמו וכאשר רוב שאר האינטרנט הפך את המפתחות לכל מקום אוֹפְּצִיָה.תראה כמה זמן לוקח להפעיל את 2FA עבור יותר מחלק קטן מהאינטרנט העמוק!
אז כן, אני חושב שכמה פוסטים בבלוג של גוגל אומרים "מכשירים רבים אינם תומכים עדיין במפתחות סיסמה" ו"נחיל בדיקה מדוקדקת יותר לפעילות התחברות לסיסמה כי אנו מאמינים שאלו הם החוליה החלשה"
אינו זהה ל:
"אנחנו מתכננים למחוק את הסיסמאות של חשבון Google של כולם בעתיד הקרוב"
לחץ להרחבה...
אז שוב, החוליה החלשה ביותר היא גיבוי סיסמאות, מבלי להסיר גיבויי סיסמאות, מפתחות סיסמה חסרי תועלת מנקודת המבט של מתן יתרונות אבטחה ממשיים. אם אין מתודולוגיה ידועה להסרת גיבויי סיסמאות, אז מה הטעם במפתחות סיסמה?
נמאס מהבלוגרים הטכנולוגיים האלה בהנחה שלכולם יש את אותה מערך "עובד" כמו שלו. אני לא אשתמש באלה בעתיד הקרוב ככל שאני רוצה, כי תמיכה חלקה עדיין לא שם, ושבירה של משהו איפשהו יגרום ליותר כאב ראש.
מפתחות כניסה הם למעשה יתרון עצום עבור מקרה השימוש הספציפי שלך וזה דבר אחד שגם אני ארוויח ממנו (תמיכה בבני משפחה מזדקנים).shawn99452 אמר:אני בעד הרעיון של שימוש במפתחות סיסמה באופן כללי, אבל יש לו כמה מגבלות רציניות... מבחינתי, חוסר התמיכה במחשבים (הרבה מחשבים שולחניים) ללא Bluetooth הוא די גדול. בנוסף, היעדר תמיכה בלינוקס הוא עניין גדול עבורי באופן אישי - אני מקווה שמישהו יצור אחסון מפתח סיסמה שמתארח בעצמו מערכת (כמובן שתצטרך להיות דרך כלשהי להוסיף את כתובת האתר של שרת מפתח הסיסמה המתארח בעצמך או דומה בעת הוספת מפתח ל- שֵׁרוּת).בעיה גדולה נוספת היא בעיה שאני כבר צריך להתמודד איתה עם 2FA (אם כי אני משתמש ותומך ב-2FA באופן כללי) - אני עושה הרבה תמיכה טכנית לאנשים מבוגרים, ולפעמים צריך לעשות דברים מרחוק, בשמם. עם 2FA קשה מאוד להיכנס לחשבון של מישהו אחר (גוגל וכו') כדי לשנות הגדרה, לחפש משהו, לעזור לו לשחזר או לאפס סיסמה וכו'. זה כמובן מכוון ובדרך כלל דבר טוב, אבל זה מסבך את התמיכה הטכנית. מפתחות סיסמה נראים אפילו גרועים יותר למטרה זו מ-2FA, מכיוון שלפחות עם 2FA אני יכול להתקשר אליהם ולבקש ממני לקרוא קוד שמוצג בטלפון שלהם, או להגיד להם להקיש על כל הנחיה שמוצגת.
לחץ להרחבה...
יכול להיות להם שמפתח סיסמה לחשבון שלהם במערכת שלהם, ואתה יכול לקבל שונה סיסמה עבור אותו חשבון, שמור במערכת שלך.
הסיבה העיקרית שאהנה היא שהם לא יהיו מותנים מראש למתן קודי 2FA לעתים קרובות בטלפון או הקשה על כן בהנחיית מסך.
אולי לא הייתי מניח הנחה כזו אם אי פעם ראיתי משהו שמצביע על כך שלThunderbird תהיה תמיכה במפתחי סיסמה בזמן הקרוב. בהתחשב בכמה זמן לקח לתמיכה ב-OAuth להתווסף, אני חושב שזה היה הגיוני להסיק שזה לא יהיה משהו שאוכל לעשות ב-Thunderbird.דנגודין אמר:WebAuthn כבר משתלב בצורה חלקה עם Gmail ב-Thunderbird.הערה זו היא עוד דוגמה למישהו שלא שואל שאלות, אלא טוען בביטחון (שמפתחות סיסמה לא יעבדו בסביבה שלך) על סמך הבנה לא מדויקת מבחינה טכנית. במקום לקפוץ למסקנות, למה לא לחקור קצת קודם?
לחץ להרחבה...
אגב, ניסיתי את ההדגמה ב-passkeys.io, גם Firefox וגם Vivaldi ב-Manjaro רוצים שאחבר מפתח אבטחה. אם זו מגבלה של הדפדפנים או ההדגמה, אני לא בטוח.
יש להם בעצם - אם אתה יודע איך לתרגם את השיווק מדברים "Passkeys" למפרט הטכני: "אישור ריבוי מכשירים" או "אישור תאימות לגיבוי".ג'ארקס אמר:כן. אם הם באמת מפרסמים כיצד הם מתכננים להסיר סיסמאות כאישור גיבוי, מפתחות סיסמה יכולים להיות מצוינים.
לחץ להרחבה...
מפרט הטיוטה הנוכחי עבור Webauthn נמצא כאן: Webauthn
כאשר אתה רושם מפתח סיסמה, האתר יכול לראות שמדובר באישור מרובה מכשירים, ואם המפתח הפרטי מגובה. במקרה הזה:
(Relying Party = שרת אינטרנט, בטרמינולוגיה שלהם, "Client" = דפדפן, "Authenticator" = Yubikey, למשל, או זה המובנה בטלפון או במחשב "Platform Authenticator")
תְעוּדָה זכאות לגיבוי ושוטף מצב גיבוי מועבר על ידי ה לִהיוֹת ו BSדגלים בתוך ה נתוני המאמת, כהגדרתו ב שולחן .הערך של ה לִהיוֹתדֶגֶל מוגדר במהלך authenticatorMakeCredential פעולה ואסור לשנות.
הערך של ה BSדֶגֶל עשוי להשתנות עם הזמן בהתבסס על המצב הנוכחי של מקור אישור מפתח ציבורי. שולחן להלן מגדירים שילובים תקפים ומשמעותם.
לִהיוֹת ו BSדֶגֶל שילובים
לִהיוֹת BS תיאור 0 0 האישור הוא א אישור של מכשיר בודד. 0 1 שילוב זה אסור. 1 0 האישור הוא א אישור ריבוי מכשירים ואינו כרגע מגובה. 1 1 האישור הוא א אישור ריבוי מכשירים והוא כרגע מגובה.
זה מומלץ ש צדדים סומכים לאחסן את הערך העדכני ביותר של אלה דגלים עם ה חשבון משתמש להערכה עתידית.להלן רשימה לא ממצה של איך צדדים סומכים עשוי להשתמש באלה דגלים:
- דורש תוספת מאמתים:
כאשר לִהיוֹתדֶגֶל מוגדר ל-0, האישור הוא a אישור של מכשיר בודד וה יוצר אימות לעולם לא יאפשר גיבוי של האישורים.
א אישור של מכשיר בודד אינו עמיד בפני אובדן מכשיר בודד. צדדים סומכים צריך להבטיח שכל אחד חשבון משתמש יש עוד מאמתיםרשום ו/או תהליך שחזור חשבון. לדוגמה, המשתמש יכול להתבקש להגדיר תוספת נוספת מאמת, כגון א מאמת נודד או א מאמת שמסוגל אישורי ריבוי מכשירים.
- שדרוג משתמש לחשבון ללא סיסמה:
כאשר BSדֶגֶל משתנה מ-0 ל-1, ה מאמת מסמן כי ה תְעוּדָה מגובה ומוגן מפני אובדן מכשיר בודד.
ה מפלגת הסתמכות עשוי לבחור לבקש מהמשתמש לשדרג את אבטחת החשבון שלו ולהסיר את הסיסמה שלו.
לחץ להרחבה...
אז לאחר שתיצור מפתח סיסמה ותגבה אותו, השרת יכול לדעת ולהציע לך להסיר את הסיסמה שלך.
אם יש לי מפתח סיסמה בטלפון אנדרואיד הישן שלי, כיצד אוכל להעביר או להגדיר אותו בטלפון אנדרואיד חדש?
אתה אפילו לא מבין איך מפתחות סיסמה הם הקלה חזקה נגד התקפות דיוג ו-MITM? אז למה אתה ממלא את ההערות במידע מוטעה כשלא עשית מחקר בסיסי? כל זה הוסבר בבירור במאמרים שהייתם מאוד קולניים בתגובות.ג'ארקס אמר:אני לא רואה איך זה יפתור דיוג בחנית עם התקפות שידור חוזר של סיסמאות. רוב הדיוג MITM פשוט משמיע מחדש את הקלט לשרת ומחזיר את הפלט לקורבן, בדרך כלל עם הפניה מחדש בסוף. סוגי התקפות אלה עדיין פועלים גם נגד מכשירי TOTP MFA, כך שאלו לא באמת ההתקפות שאנשים מנסים למנוע כאן.אם אנחנו מדברים על שחקני מדינת לאום, הם פשוט הולכים למקד את התמיכה הטכנית של כל מה שהם רוצים גישה אליו, אז לדון בטכנולוגיה כדי למנוע את זה הוא חסר משמעות.
ולא, מעולם לא אמרתי שגוגל מאחסנת סיסמאות במסד נתונים לא מוצפן. לא כך מתרחשות התקפות מילוי אישורים. בדרך כלל אנשים עושים שימוש חוזר בסיסמאות במספר מיקומים והאתרים החלשים יותר חושפים את אותן סיסמאות שהיו בשימוש באתרים שלוקחים את הקצה האחורי שלהם בצורה מאובטחת יותר.
אני מסכים עם ההצעות שלך להפצה, עם אזהרה אחת - למעשה פרסם מסמך לבן שלא מתעסק בו תיאורטיות כמו ה-FIDO הטוענת שלמשתמשים "כנראה" יהיה מכשיר שני לשחזר אם המכשיר הראשון שלהם אבוד. ואותו נייר לבן זה גם לא אמור להציע רק שסיסמאות משמשות כחלופה לחדשות מכשירים, הוא צריך למעשה לנסח את התוכנית להסרה מלאה של סיסמאות -- כי זו המטרה הסופית ימין? אנחנו צריכים לדעת את הצעדים שאנחנו הולכים לנקוט לפני שנגיע לשם.
לחץ להרחבה...
כמו כן, אמרת קודם לכן שסיסמאות נפגעות רק לעתים רחוקות בנקודת השימוש והאישור הזה הפשרות נובעות בעיקר מהתקפות מילונים, מילוי אישורים וסיסמה לא מאובטחת חשופה מסדי נתונים. עכשיו אתה אומר שלמעשה יש התקפות פישינג שמצליחות אפילו עם TOTP, וה-NCSC וה-CISA מצהירים שניהם פישינג הוא עדיין וקטור ההתקפה הרווח, אז אני עדיין אומר שטעית קודם לכן ושהסיסמאות עדיין פגיעות ב- נקודת שימוש.
מדינות הלאום לא מתכוונות למקד את התמיכה הטכנית של שירות מקוון כמו גוגל הכולל הצפנה מקצה לקצה ואשר מודיע למשתמשים שלו אם הוא חושד בניסיון חדירה עוין. זה יהיה הדבר הכי גרוע שהם יכולים לעשות. הם יקבלו גוש מוצפן של נתונים במקרה הטוב, ויסכנו שהמטרה תקבל התראה ויבקש ייעוץ אבטחה.
אני שמח שאתה אוהב את מפת הדרכים המוצעת שלי אבל הייתי סרקסטי; מה שהצעתי קורה בפועל עכשיו ומה מתוכנן לעתיד, כפי שתועד במאמר זה... אבל אל תבזבזו את זמנכם בהמתנה למסמכים לבנים משמעותיים, כבר עשרות שנים שהם מונח נוסף ל'שיווק מוך לשלוח לרואי החשבון ולהנהלה העליונה' וקהל היעד הוא אנשי ה-IT שיודעים בדיוק מספיק כדי להיות מְסוּכָּן
מפרטי ה-FIDO דורשים שכל מנגנון סינכרון שמשתמש בוחר (בין אם זה מאפל, מיקרוסופט, גוגל או צד שלישי) הוא לספק הצפנה מקצה לקצה כמו מחזיק מפתחות iCloud וסנכרון סיסמאות עם דפדפנים כרגע (ב-Chrome, E2EE זה חייב להיות נדלק).
לחץ להרחבה...
האם הדרישה הזו מתועדת במקום כלשהו?
אני שואל כי לפני FIDO היה שירות המטא נתונים שלהם לרשום מאמתים תואמים. לפי המפרט, הם מפרטים רק סוגי הגנה מרכזיים - ואין שום דבר בין תוכנה לסוגי החומרה השונים.
מפרט כאן: מטא נתונים
ראה 3.2 סוגי הגנת מפתחות
cse84 אמר:מכיוון שנראה שכל המטרה של מערכת המפתחות היא להיפטר מסיסמאות, הרשו לי לפרט כמה מהיתרונות של סיסמאות:
- הם פשוטים מספיק כדי להבין עבור כל מי שמסוגל נפשית להפעיל מכשיר אלקטרוני
- קל לזכור אותם אם אתה מתאמץ בכלל ומשתמש בהם באופן קבוע
- הם עובדים על כל מערכות ההפעלה מחוץ לקופסה
- הם אינם דורשים גישה לאינטרנט (יש מערכות שאינן מקוונות מסיבה טובה)
- הם אינם דורשים שיתוף פעולה של אף צד שלישי
- הם אינם דורשים נוכחות של סמארטפון או גאדג'ט אחר
- הם אינם דורשים Bluetooth, WiFi, מצלמות או סוללות
- ניתן לאחסן אותם במקרה חירום ללא צורך בחשמל
- ניתן להעביר אותם בקלות לאדם אחר ללא שימוש במכשיר כלשהו
- אם אינך מוגבל ואינו משתמש בסמארטפון, אימות באמצעות סיסמה אורך שניות בודדות
לחץ להרחבה...
הנקודות שלך מס' 1, מס' 2 ו-#10 פשוט שגויות - שאל את כל מי שעובד בתמיכה טכנית באיזו תדירות הוא צריך לבצע איפוס סיסמה בגלל שמישהו שכחו את הסיסמה שלהם, השאירו את מקש ה-caps lock מופעל (או שמו את ידם לא נכון על המקלדת), או הקישו על זה מספיק פעמים כדי להינעל הַחוּצָה. כן, כן, אני יודע שאתה באופן אישי תמיד מוציא את זה בצורה מושלמת, אבל תאמין לי, לכל מי שמקבל טלפונים למוקד יש נקודת מבט … פחות אופטימית … על האנושות. אוסיף גם שאני תומך בהרבה משתמשים עיוורים ובהזנת סיסמא בצורה מאסיבית מבאס עבורם כי לאתרים רבים יש דרישות מורכבות שקשה למשתמשי קוראי מסך, ואם אתה לא קלדנית מיומנת להגיד את זה בקול זה לא נהדר. זו נישה אבל היא כזו שאנשים רבים שבונים מערכות אימות נדרשים על פי חוק לתמוך היטב, וזו אחת הסיבות שבגללן אני מתעניין בה הטכנולוגיה מאז "האם אתה רוצה להיכנס עם המפתח שלך?" "כן" הוא לפחות סדר גודל אחד מהיר וקל יותר מכל צורה של סיסמה + MFA עבור רבים מהם משתמשים.
נקודה מס' 3 נכונה לגבי WebAuthn MFA אבל תמיד מפתחות - משהו כמו Yubikey עובד בכל מקום שיש לך USB/NFC אבל אתה יכול צריך להגדיר קוד PIN או להשתמש במפתחות הסדרה הביומטרית שלהם עבור מיישמי מפתחות סיסמה כמו Google.com שדורשים יותר מאשר פשוט בֶּרֶז.
נקודות #5, #6, #7 ו-#8 נכונות גם לכל סוגי WebAuthn - גם MFA וגם מפתחות סיסמה. נקודה מס' 4 נכונה למעט הפעם הראשונה שבה אתה רושם מכשיר בעת סנכרון מפתח קיים. לאחר הפעם הראשונה שסנכרנת את המפתחות שלך, אינך זקוק לחיבור רשת. אם אתה לא רוצה לסנכרן, אתה יכול גם לקנות כמה מפתחות ביומטריים של Yubikey ששוב עובדים במצב לא מקוון לחלוטין בכל מקום שיש לך USB או NFC.
זה משאיר את מס' 9, שהוא תרגול גרוע ויש להימנע ממנו אם אפשר. למערכות מודרניות יש דברים כמו אימות מבוסס תפקידים, שבהם אנשים אף פעם לא חולקים סיסמאות, אבל מותר למספר אנשים לקחת תפקיד נתון, או דברים כמו מדור קודם או מואצלה חשבונות שבהם אתה שוב לעולם לא משתף סיסמאות אלא נותן לאחד או, אפילו טוב יותר, למספר אנשים הנדרשים בשילוב את היכולת לעשות משהו כמו לאפס את הסיסמה שלך או להשיג שליטה על הקבצים שלך.
זה שמשהו חדש ולא למדת איך הוא עובד לא אומר שהוא רע או שיש להימנע ממנו. מפתחות סיסמה הם שינוי גדול עבור רובנו - .gov למעט מאז PIV/CAC חוזר למאה הקודמת שם גם אם מעט מקומות אחרים אימצו את זה - אבל יש להם מספר שיפורים בשימושיות בנוסף ליתרונות האבטחה, ויש דרך ברורה לבנייה. חלק מהחלקים החסרים (למשל, אני באמת רוצה את היכולת לסנכרן מפתח אפל/גוגל ל-Yubikey כדי שאוכל להשאיר אותו בכספת שלי רק ב מקרה).
ג'ארקס אמר:אני לא מדבר על שירותים אחרים. גוגל פרסמה (לפחות) 5 פוסטים בבלוג האומרים שמפתחות יהרגו סיסמאות, אך מעולם לא פירטה פעם אחת כיצד מפתחות יפעלו בבידוד של סיסמאות אלה. השתמשתי בבלוטוס כדי לנסות להעביר את הנקודה שלי - וזה לא משנה אם חשבונות גוגל עובדים טוב עבור רוב האנשים, סיסמאות עדיין משמשות כגיבוי - מה מביס את כל המטרה של מפתחות סיסמה בכללותה.אם משתמשים בסיסמאות כגיבוי אז יש אפס נקודת מפתח למפתחות. סיסמאות עדיין יהיו ב-DBs מאושרים, סיסמאות עדיין ידלפו, עדיין ניתן להשתמש בסיסמאות כדי להשתלט על חשבונות של אנשים. מפתחות סיסמה, בצורתם ובצורתם הנוכחיים, הם חסרי טעם אלא אם כן למשתמשים עם מפתח גישה בלבד יש דרך להוסיף מכשירים חדשים ללא סיסמאות.
אפשרויות נפילה אינן רק אפשרויות - מנקודת מבט אבטחה היא קובעת אם מנגנון האבטחה אכן משפר את האבטחה הכוללת של האימות או לא.
זה לא מהותיות אם התרחיש בפועל הופך את השירות לחסר תועלת וחסר טעם בכל התרחישים. ועד שתהיה זרימת עבודה המאפשרת לך להשבית לחלוטין גיבויים של סיסמאות ולתחזק את אותן יכולות שמעניקות סיסמאות (גישה לחשבונות דרך כל מכשיר) אז הבעיה הזו תהיה שם.
אם אני מעצב פותחן דלת מוסך שמשתמש ב-PKI ואף אחד לא יוכל לחקות את התקשורת של הפותחן שלי עם המוסך שלי אלא ליצור נפילה שבה הוא מקבל את הקודים של פותחן דלת מוסך רגיל. נחשו מה, הנסיגה הופכת את הפותחן החדש שלי לחסר תועלת לחלוטין.
זה לא רעש כאשר הנפילה מבטלת את יתרונות הטכנולוגיה.
לחץ להרחבה...
אני חושב שעניתי על זה בשרשור אחר איפשהו, אבל סיסמאות אינן נדרשות בתור סתירה בעיצוב ללא סיסמה. אתה יכול פשוט לשחרר אותם כמנגנון אימות.
אתה עדיין יכול לשמור אותו כשיטת "איבדתי את כל המפתחות שלי, בוא נתחיל בתהליך השחזור", באותו אופן ש'שאלות אבטחה' מיועדות סיסמאות, או שאתה יכול לבחור כל שיטה אחרת שתרצה ("איבדתי את כל המפתחות שלי, שלח לי אימייל קישור וסמס לי קוד שאני צריך להקליד בקישורים טפסים"... או אם אתה IT עבור חברה "גש לדלפק שירות ה-IT והצג את זיהוי הצוות שלך"). לא היית קורא לזה סיסמה בשלב זה, היית קורא לזה "מפתח שחזור", ובמקום לאפשר למשתמש תבחר בו, אתה יוצר אותו בעת יצירת החשבון ואומר להם לשמור אותו/להדפיס אותו או שהם עלולים להינעל בסופו של דבר הַחוּצָה.
אתה עדיין תקבל כמה אנשים שיפוצצו גם את זה, וזה נופל בחזרה ל"מזל קשה" או "הנה מספר 1800 שלנו..." או מה שאתה רוצה.
אבל בשום שלב אתה לא נותן לאנשים את האפשרות להקליד סיסמה שאפשר להתחזות בטופס ההתחברות הרגיל - הם רק מקלידים סיסמאות ב מאוד מקרים מיוחדים נדירים שבהם הם יודעים לצפות לזה כי הם התחילו בתהליך ההחלמה כי הם איבדו את המפתחות שלהם.
עריכה: תקן שגיאת הקלדה. אני יכול לכסות שולחן שירות IT, והאמינו לי, בזמן שאני בטוח שכל אחד מאיתנו ירצה בכך, אבל אני חושב שהליכה היא בדרך כלל התהליך השימושי יותר
זה למעשה CTAP 2.2 ו-WebAuthn 3.SeanJW אמר:זה לא מושלך רק על אנשים - זהו עדכון ל-FIDO2, בעצמו הגרסה השנייה של התקן. U2F היה FIDO1; זהו CTAP 2.4 (אני חושב, אני שולף את המספר מהזיכרון ויכול להיות שאני טועה), חלק מ-FIDO2/WebAuthn. זה באמת לא מסובך כמו שזה הולך... הם שחררו את דרישות ה-Authenticator כך שניתן (חייבים...) להעתיק את המפתח הפרטי בצורה מאובטחת, והוסיפו כמה תכונות של Javascript כדי להקל על החיים. כניסות ללא סיסמה? תמיד היה אפשרי עם FIDO2. זה החלק המסודר של זה - FIDO1 יכול להיות רק MFA. האם להוסיף מפתח פרטי לדפדפן שלך המאוחסן ב-TPM או ברכיב מאובטח? תמיד היה אפשרי, ו הוטמע בעבר בכרום, פיירפוקס וספארי. מה שחדש הוא שניתן לסנכרן אותו, ולגשת אליו דרך BT/QR rigmarole. בעבר, הוא כונה (וסומן לאתרי אינטרנט) כ"מפתחות ספציפיים לפלטפורמה", בניגוד לאלה הניידים שהיו התקני חומרה. עכשיו זה PassKeys.
לחץ להרחבה...
סוף סוף הם פרסמו טיוטת עבודה - זהו כאן:
העניין של קוד QR נקרא בסופו של דבר הובלה היברידית (סעיף 11.5). יש הרבה מחרוזות "כבלים" בפרוטוקול בוודאי מכיוון שהוא התבסס על הגרסה של גוגל שנקראת "cloud assisted Bluetooth LE".
מר קייט אמר:מצטער לתרום לתאונת הרכבת הזו, אבל מה הם המקומות האלה שאומרים "אין כוונות אצבע"? אני לא יכול לחשוב על שום הקשר הכולל מכשירים אישיים שבו זה הגיוני.
לחץ להרחבה...
לא מכשירים אישיים אלא חברות ובעיקר ממשלתיות. יש שני חששות: הראשון הוא פשוט שאחסון USB הוא אחסון מקומי ועלול להיות מסוכן - למשל. אנשים עשו בדיקות שבהן אתה יכול להוריד מפתחות USB ב- מגרש חניה ליד בניין וחלק מהאנשים יחברו אותם למחשב העבודה שלהם, וזו תהיה דרך מצוינת להגניב תוכנות זדוניות למחשב מאובטח רֶשֶׁת. השני הוא עבור כל מקום שיש בו נתונים שהם רוצים להימנע מאיבוד שליטה עליהם: אם אתה יכול להשתמש בכונן אצבע, אתה יכול להעתיק אליו נתונים ולקחת זה מחוץ לבניין שבו זה עלול להפוך לאסון (מכוון או לא) - תארו לעצמכם אם מישהו ב-HR רוצה לעבוד בבית ואז מוריד את המפתח עם אלפי רישומי כוח אדם ועליך לחשוף הפרה עבור כולם למקרה שמישהו זדוני ימצא זה.
התשובה הקלה ביותר בשני המקרים היא לחסום התקני אחסון המוני USB כדי שתוכל לאפשר דברים כמו מקלדות ומיקרופונים אך לא אחסון. זה עדיין מציע כמה התקפות - אחת ישנה מפורסמת הייתה https://lcamtuf.coredump.cx/plasma_globe/ - כך שמקומות עשויים להגיע אפילו רחוק יותר. זה היה זמן מה אבל לפני כמה עשורים כשהייתי במפגש אבטחה מקומי עם כמה אנשים ממתקן SPAWAR של הצי, הם אמרו מערכת ההגנה שלהם הייתה שפופרת אפוקסי: היה זול יותר לשלם למישהו כדי לסתום אותה בזמן שמישהו אחר צפה כמה פעמים בשנה כדי להחליף מקלדת או עכבר שבורים מאשר זה ניסה להבין את כל הדרכים האפשריות שמישהו יכול לנצל משהו כמו USB, Firewire, וכו ' זה מקרה קיצוני אבל כדאי לזכור שאם יש לך עלות אמיתית לאיבוד שליטה המחשבים או הנתונים שלך אולי זול יותר להגביל את האופן שבו אנשים יכולים להתחבר למחשבים שמחזיקים אותם נתונים. אני יודע שאנשים עובדים בתעשיות מוסדרות שיש להם דברים מסוימים שהם יכולים לעשות רק על שרתי מסוף נעולים מאותה סיבה - יש גבול עליון לכמה מהר אתה יכול לסנן נתונים אם מישהו צריך לבצע OCR הפעלה של שולחן עבודה מרוחק בזמן שהוא מחזיק את הדף לחוץ מקש למטה.
אני לא מסכים איתך - רישום חשבון עם מפתחות הוא ללא מאמץ בהשוואה להגדרת "הזן שם משתמש, הבא, הזן סיסמה, הבא הזן קוד 2FA/בקשת אישור". הכניסה היא ללא מאמץ לחלוטין בהשוואה ללהטט בסיסמאות ואישורי 2FA.נאם לוק אמר:איחרתי למסיבה הזו אבל כן... אני כבר מוצא את "הזן שם משתמש, הבא, הזן סיסמה, הבא הזן 2FA code/confirm prompt” זרימת העבודה כדי להיות מעצבן אבל אני מבין את התועלת לי ושלי מעסיק. זה... זה פשוט יותר מדי בשבילי לעומת הסיכון להתחזות כשכבר יש לי סיסמאות ייחודיות ל-Auto Gen ו-MFA על כל מה שיכול לקבל את זה.ג'ו או ג'יין הממוצעים שצריכים את זה הכי הרבה לא יכולים אפילו לזכור את הסיסמאות שלהם בלי לרשום אותן ולא מצליחים לסדר את מנהל הסיסמאות נגמר הרבה לפני שאני אפילו מתעצבן. הם לא יוכלו להגדיר את זה לבד ואם מישהו ידריך אותם בהתקנה, בפעם הראשונה שהם יתקלו בזרם הזה הם יתחילו להתפרע. עזרתי ל"אנאלפביתים למחשב" לבצע משימות בסיסיות כמו הרשמה לאימייל. תרגיל טריוויאלי של שתי דקות עבור Ars Readers הוא חצי שעה בגיהנום עבורם.
לחץ להרחבה...
רוב האנשים האנאלפביתים למחשבים מרגישים הרבה יותר נוח עם הטלפון שלהם מאשר מחשב נייד או שולחני ושימוש בו אימות ביומטרי של טביעת אצבע או זיהוי פנים בא להם באופן טבעי יותר כדי לפתוח את הטלפון או לגשת אפליקציות בנקאות/הודעות. מניסיוני האחרון, מפתחות סיסמה הופכים את כל הדברים האלה לקלים יותר.
לדוגמא לרמת אוריינות המחשב של בן משפחתי שמשתמש במפתחות סיסמה ללא מאמץ בחשבון eBay שלו: אותו אדם ביקש ממני לאחרונה לחקור בעיה עם המחשב הנייד שלהם מכיוון שחלון הדפדפן היה קטן מדי במשך יותר משבוע - הם לא הבינו שניתן לגרור את הקצוות והפינות של החלון כדי לשנות את הגודל של החלון. חַלוֹן…
הגישה ל-eBay באמצעות מפתחות סיסמה באייפון וב-MacBook (שניהם מכשירי TouchID) עדיין הייתה קלה עבור האדם הזה.
אפל לא גמורה.SeanJW אמר:אֲנָחָה. עדיין מאוחר למסיבה. גוגל מכינה מזה ארוחת בוקר לכלבים, מה שבשום אופן לא מפתיע אף אחד, אבל יש להם דברים עובדים שם בחוץ. אפל היא על פני הלוח בוצע. מיקרוסופט רוכבת על זנבות המעיל של גוגל (אם כי למען ההגינות, הם עושים את החלק של Windows Hello, שגוגל צריכה בשביל זה ב-Windows).פלא שאני שונא לבדוק את FIDO2 בפיירפוקס (במיוחד בלינוקס)
לחץ להרחבה...
הם צריכים ליישם API כדי לאפשר למנהל סיסמאות של צד שלישי ליירט את אחסון המפתח הפרטי, או אפשר לפלאגין של צד שלישי להיות מאמת שלם - צור צמד מפתחות, הצהרת חתימה, אימות משתמש, וכו '
אם אפל מאפשרת לשמור רק מפתחות פרטיים ב-iCloud, אני אתקשה להמליץ על מפתחות סיסמה לקבוצת המשתמשים שמשתמשת באייפון ובמחשבי ווינדוס. האנשים האלה יתקעו ביצירת סיסמה אחת לכל מערכת אקולוגית ו/או בתקווה ששחזור החשבון יעבוד.
מר קייט אמר:נראה שהחשבון שאתה מגיב אליו (אולי בכוונה) לא מבין שגוגל איכשהו בלולאה של שימוש במפתח כדי להיכנס לאתר אחר. נראה שהמילים "מפתח Google" ברצף בכותרת ערבלו כמה מוחות לחשוב שזה שירות שמסופק על ידם שגורם לאנשים להיות תלויים ברצונה הטוב של גוגל או מה לא.אני חצי ברצינות מתחילה לחשוב שחלק מההיסטריה שנדלקת כאן היא מחוות בוטים המנוהלות על ידי פושעים שמגנים על העסק שלהם.
לחץ להרחבה...
המאמר עצמו אומר "באיזה מנגנון סינכרון שמשתמש בוחר (בין אם זה מאפל, מיקרוסופט, גוגל או צד שלישי)". אז מהימנות התשתית המתווכת המטפלת בסנכרון מפתחות היא שאלה חשובה. המערכת האקולוגית המטפלת במפתחות חשובה, וכרגע לא נראה שיש אלטרנטיבה שאינה תאגיד גדול.
השיחה בתגובות דיברה גם על אימוץ מפתח סיסמה רחב יותר ואיך זה עשוי להיראות, לא ספציפית רק כניסה לגוגל, אז אולי זה היה מבלבל? כאשר הטכנולוגיה הזו מתחילה זה זמן סביר להתחיל לחשוב על השלכות אפשריות. אנשי הטכנולוגיה כבר ראו עד כמה תאגידים פרטיים המחזיקים בפיסות תשתיות מרכזיות עלולים להגיע אליהם.
אם דן היה מתמקד בתשובה לשאלות כמו SeanJW או חבורה של משתמשים אחרים כאן במקום לעלות על סוס גבוה על מידע שגוי (כשהוא בהתחלה טעה בדרישות ה-Bluetooth במאמר עצמו חחחח) הדברים היו הרבה רגוע יותר.
fvgfvghvgv אמר:אתה אפילו לא מבין איך מפתחות סיסמה הם הקלה חזקה נגד התקפות דיוג ו-MITM? אז למה אתה ממלא את ההערות במידע מוטעה כשלא עשית מחקר בסיסי? כל זה הוסבר בבירור במאמרים שהייתם מאוד קולניים בתגובות.
לחץ להרחבה...
אממ, פשוט עברתי על כל המאמרים ואף אחד מהם לא מסביר איך זה מונע התקפות MITM. אם יש לי אתר אינטרנט ואני מרמה אותך לבקר בו, אני לא רואה סיבה לכך שזה לא יהיה רגיש להתקפות MITM.
לקוח שרת זדוני <> אפליקציה אמיתית
השרת הזדוני יוצר קשר עם האפליקציה בשם הלקוח, מבקש את החתימה מהלקוח ואז מעביר אותה בחזרה לאפליקציה. הם לא צריכים את המפתח הפרטי כדי לעשות זאת, הם רק צריכים את האפליקציה כדי לבקש את המפתח והלקוח יגיב עם המפתח הנכון. מנגנון זה יכול, במידה מסוימת, להיות מופחת בצד השרת, אבל זה חל על סיסמאות ומפתחות סיסמה.
סוג ההתחזות שזה כן מונע הוא אתר קצירת האישורים הסטטי שמתיימר להיות דף התחברות אבל למעשה לא מעביר שום דבר לאתר האמיתי. וזה גם מפספס את הנקודה שהיא לפסקה הבאה שלך.
כמו כן, אמרת קודם לכן שסיסמאות נפגעות רק לעתים רחוקות בנקודת השימוש והאישור הזה הפשרות נובעות בעיקר מהתקפות מילונים, מילוי אישורים וסיסמה לא מאובטחת חשופה מסדי נתונים. עכשיו אתה אומר שלמעשה יש התקפות פישינג שמצליחות אפילו עם TOTP, וה-NCSC וה-CISA מצהירים שניהם פישינג הוא עדיין וקטור ההתקפה הרווח, אז אני עדיין אומר שטעית קודם לכן ושהסיסמאות עדיין פגיעות ב- נקודת שימוש.
לחץ להרחבה...
"נקודת שימוש" היא בזמן אמת. התקפות שידור חוזר הן נדירות וניתן למתן אותן בצד יישום האינטרנט. מלית אישורים אינה "נקודת שימוש" - היא משמשת בכל פעם שהתוקף רוצה להשתמש בה, לא הלקוח.
דיוג בהחלט נפוץ, מעולם לא אמרו שזה לא. אני אומר שעם גיבויי סיסמאות, מפתחות סיסמה לא עוזרים למתן את התקפות הדיוג האמורות מכיוון שהגיבוי נופל קורבן לאותה מתודולוגיית תקיפה כמו מנגנון האימות הישן.
מדינות לאום בהחלט מכוונות לתמיכה טכנית תוך התחזות לעובדים כדי לאפס מכשירים/MFA. אז אין לך מושג על מה אתה הולך כאן.מדינות הלאום לא מתכוונות למקד את התמיכה הטכנית של שירות מקוון כמו גוגל הכולל הצפנה מקצה לקצה ואשר מודיע למשתמשים שלו אם הוא חושד בניסיון חדירה עוין. זה יהיה הדבר הכי גרוע שהם יכולים לעשות. הם יקבלו גוש מוצפן של נתונים במקרה הטוב, ויסכנו שהמטרה תקבל התראה ויבקש ייעוץ אבטחה.
לחץ להרחבה...
היה מודע לחלוטין שאתה סרקסטי. הגבתי בעגמת נפש מכיוון שאיש לא הראה את התוכנית להסיר סיסמאות (עד עמוד 14).אני שמח שאתה אוהב את מפת הדרכים המוצעת שלי אבל הייתי סרקסטי; מה שהצעתי קורה בפועל עכשיו ומה מתוכנן לעתיד, כפי שתועד במאמר זה... אבל אל תבזבזו את זמנכם בהמתנה למסמכים לבנים משמעותיים, כבר עשרות שנים שהם מונח נוסף ל"מוך שיווקי" לשלוח לרואי החשבון ולהנהלה העליונה' וקהל היעד הוא אנשי ה-IT שיודעים בדיוק מספיק כדי להיות מסוכנים
לחץ להרחבה...