מיקרוסופט להילחם בהונאת המילוי האוטומטי של Chrome על ידי הוספת חיכוך נוסף

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

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

מהנדסי מיקרוסופט התייחסו כעת לחששות שהביעו משתמשים בפוסט ב-GitHub:

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

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

מהר קדימה לשנת 2020, יש למיקרוסופט עכשיו מוּצָע פתרון שמתייחס לחששות אלו. "בהתבסס על מחקר משתמש/משוב", החברה מציעה "כבוי כברירת מחדל, וו אימות מחדש של מערכת ההפעלה בנתיב קוד המילוי האוטומטי של Chromium" הוא הפתרון.

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

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

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

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

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

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

גם Chrome וגם Firefox כבר אימצו אימות של Windows Hello כדי לאשר את הצגת הסיסמאות השמורות בהגדרות. אנו יכולים להניח שבמקום לבקש מאיתנו לזכור סיסמה אחרת, סביר להניח שמיקרוסופט מתכוונת לאפשר למשתמשים להשתמש באימות ביומטרי של Windows Hello כדי לאשר מילוי אוטומטי של סיסמאות למי שמודאג לגבי מכשירים משותפים.

מקור: חלון ראווה