הפניה אוטומטית של בקשה לכתובת /.well-known/change-password לכתובת ה-URL של change-passwords
מגדירים הפניה אוטומטית מ-/.well-known/change-password לדף לשינוי הסיסמה באתר. כך מנהלי הסיסמאות יוכלו לנווט את המשתמשים ישירות לדף הזה.
מבוא
כידוע, סיסמאות הן לא הדרך הטובה ביותר לנהל חשבונות. למרבה המזל, יש טכנולוגיות חדשות כמו WebAuthn וטכניקות כמו סיסמאות חד-פעמיות שעוזרות לנו להתקרב לעולם ללא סיסמאות. עם זאת, הטכנולוגיות האלה עדיין נמצאות בפיתוח והדברים לא ישתנו במהירות. מפתחים רבים עדיין יצטרכו להתמודד עם סיסמאות לפחות בשנים הקרובות. בזמן שאנחנו ממתינים לטכנולוגיות ולשיטות המתפתחות שיהפכו לדבר שבשגרה, אנחנו יכולים לפחות להקל על השימוש בסיסמאות.
דרך טובה לעשות זאת היא לספק תמיכה טובה יותר למנהלי סיסמאות.
איך מנהלי הסיסמאות עוזרים
מנהלי סיסמאות יכולים להיות מובְנים בדפדפנים או להיכלל כאפליקציות של צד שלישי. הם יכולים לעזור למשתמשים בדרכים שונות:
השלמה אוטומטית של הסיסמה בשדה הקלט הנכון: דפדפנים מסוימים יכולים למצוא את הקלט הנכון באופן היוריסטי גם אם האתר לא עבר אופטימיזציה למטרה הזו. מפתחי אתרים יכולים לעזור למנהלי הסיסמאות על ידי הוספת הערות לתגי קלט של HTML בצורה נכונה.
מניעת פישינג: מאחר שמנהלי הסיסמאות זוכרים איפה הסיסמה תועדה, אפשר למלא את הסיסמה באופן אוטומטי רק בכתובות URL מתאימות, ולא באתרי פישינג.
יצירת סיסמאות חזקות וייחודיות: מאחר שסיסמאות חזקות וייחודיות נוצרות ומאוחסנות ישירות על ידי מנהל הסיסמאות, המשתמשים לא צריכים לזכור אפילו תו אחד מהסיסמה.
יצירת סיסמאות ומילוי אוטומטי שלהן באמצעות מנהל סיסמאות כבר עזרו לאינטרנט, אבל בהתחשב במחזור החיים שלהן, עדכון הסיסמאות בכל פעם שנדרש חשוב באותה מידה כמו היצירה והמילוי האוטומטי. כדי לנצל את זה בצורה נכונה, מנהלי הסיסמאות מוסיפים תכונה חדשה:
זיהוי סיסמאות חשופות והצעה לעדכן אותן: מנהלי סיסמאות יכולים לזהות סיסמאות בשימוש חוזר, לנתח את האנטרופיה והחולשה שלהן ואפילו לזהות סיסמאות שדלפו או כאלה שידועות כבלתי בטוחות ממקורות כמו Have I Been Pwned.
מנהל סיסמאות יכול להזהיר משתמשים על סיסמאות בעייתיות, אבל יש הרבה חיכוך בבקשה מהמשתמשים לנווט מדף הבית לדף לשינוי סיסמה, בנוסף לתהליך הפיזי של שינוי הסיסמה (ששונה מאתר לאתר). יהיה הרבה יותר קל אם מנהלי הסיסמאות יוכלו להפנות את המשתמש ישירות לכתובת ה-URL לשינוי הסיסמה. כאן נכנסת לתמונה כתובת URL ידועה לשינוי סיסמאות.
אם שומרים נתיב ידוע של כתובת URL שמפנה את המשתמש לדף לשינוי הסיסמה, האתר יכול להפנות את המשתמשים בקלות למקום הנכון לשינוי הסיסמה.
מגדירים 'כתובת URL ידועה לשינוי סיסמאות'
.well-known/change-password מוצע ככתובת URL ידועה לשינוי סיסמאות. כל מה שצריך לעשות הוא להגדיר את השרת להפנות אוטומטית בקשות ל-.well-known/change-password לכתובת ה-URL לשינוי הסיסמה באתר.
לדוגמה, נניח שהאתר שלכם הוא https://example.com וכתובת ה-URL לשינוי הסיסמה היא https://example.com/settings/password. פשוט צריך להגדיר את השרת להפנות אוטומטית בקשה ל-https://example.com/.well-known/change-password אל https://example.com/settings/password. זה הכול. להפניה האוטומטית, משתמשים בקוד סטטוס HTTP
302 Found, 303 See
Other או 307
Temporary Redirect.
לחלופין, אפשר להציג HTML בכתובת ה-URL .well-known/change-password באמצעות תג <meta> באמצעות http-equiv="refresh".
<meta http-equiv="refresh" content="0;url=https://example.com/settings/password">
בודקים מחדש את ה-HTML של דף שינוי הסיסמה
מטרת התכונה הזו היא לעזור למחזור החיים של הסיסמה של המשתמש להיות חלק יותר. יש שני דברים שאפשר לעשות כדי לאפשר למשתמש לעדכן את הסיסמה שלו ללא טרחה:
- אם צריך להזין את הסיסמה הנוכחית בטופס לשינוי הסיסמה, מוסיפים את הערך
autocomplete="current-password"לתג<input>כדי לעזור למנהל הסיסמאות למלא את הטופס באופן אוטומטי. - בשדה הסיסמה החדשה (במקרים רבים יש שני שדות כדי לוודא שהמשתמש הזין את הסיסמה החדשה בצורה נכונה), מוסיפים את הערך
autocomplete="new-password"לתג<input>כדי לעזור למנהל הסיסמאות להציע סיסמה שנוצרה.
מידע נוסף זמין במאמר שיטות מומלצות ליצירת טפסים לכניסה.
איך משתמשים בזה בעולם האמיתי
דוגמאות
בזכות ההטמעה של Apple Safari, התכונה /.well-known/change-password כבר זמינה בחלק מהאתרים הגדולים כבר זמן מה:
נסו אותם בעצמכם ותעשו את אותו הדבר בחשבון שלכם.
תאימות דפדפן
כתובת URL ידועה לשינוי סיסמאות נתמכת ב-Safari מאז 2019. מנהל הסיסמאות של Chrome מתחיל לתמוך בכך מגרסה 86 ואילך (הגרסת היציבה אמורה לצאת בסוף אוקטובר 2020), וייתכן שדפדפנים אחרים שמבוססים על Chromium יתחילו לתמוך בכך בהמשך. ב-Firefox סבורים ששווה להטמיע את התכונה, אבל נכון לאוגוסט 2020 הם לא הודיעו שהם מתכננים לעשות זאת.
ההתנהגות של מנהל הסיסמאות ב-Chrome
נראה איך מנהל הסיסמאות של Chrome מטפל בסיסמה פגיעה.
מנהל הסיסמאות ב-Chrome יכול לבדוק אם סיסמאות שלכם נחשפו. כשמעבירים את העכבר אל about://settings/passwords, המשתמשים יכולים להריץ את בדיקת הסיסמאות ביחס לסיסמאות השמורות, ולראות רשימה של סיסמאות מומלצות לעדכון.
כשלוחצים על הלחצן שינוי סיסמה לצד סיסמה מומלצת לעדכון, הדפדפן:
- פותחים את הדף לשינוי הסיסמה באתר, אם
/.well-known/change-passwordמוגדר בצורה נכונה. - פותחים את דף הבית של האתר אם
/.well-known/change-passwordלא מוגדר ו-Google לא מכירה את חלופת הגיבוי.
200 OK גם אם /.well-known/change-password לא קיים?מנהלי הסיסמאות מנסים לקבוע אם אתר תומך בכתובת URL ידועה לשינוי סיסמאות, על ידי שליחת בקשה אל /.well-known/change-password לפני שהם מעבירים את המשתמש לכתובת ה-URL הזו. אם הבקשה מחזירה את הערך 404 Not Found, ברור שכתובת ה-URL לא זמינה. עם זאת, תגובה עם הערך 200 OK לא בהכרח מצביעה על כך שכתובת ה-URL זמינה, כי יש כמה מקרים קיצוניים:
- באתר עם רינדור בצד השרת, הסטטוס 'לא נמצא' מוצג כשאין תוכן, אבל עם
200 OK. - אתר עם עיבוד בצד השרת מגיב עם
200 OKכשאין תוכן אחרי ההפניה האוטומטית לדף 'לא נמצא'. - אפליקציה של דף יחיד מגיבה עם המעטפת עם
200 OKומרינדרת את הדף 'לא נמצא' בצד הלקוח כשאין תוכן.
במקרים קיצוניים כאלה, המשתמשים יועברו לדף 'לא נמצא', וזה יהיה מקור לבלבול.
לכן יש מנגנון סטנדרטי מוצעת כדי לקבוע אם השרת מוגדר להגיב עם 404 Not Found כשאין באמת תוכן, על ידי שליחת בקשה לדף אקראי. למעשה, גם כתובת ה-URL שמורה: /.well-known/resource-that-should-not-exist-whose-status-code-should-not-be-200.
לדוגמה, Chrome משתמש בנתיב כתובת ה-URL הזה כדי לקבוע מראש אם הוא יכול לצפות לכתובת URL מתאימה לשינוי הסיסמה מ-/.well-known/change-password.
כשפורסים את /.well-known/change-password, חשוב לוודא שהשרת מחזיר את הערך 404 Not Found לכל תוכן שאינו קיים.
משוב
אם יש לכם משוב לגבי המפרט, תוכלו לשלוח דיווח על בעיה למאגר המפרטים.
משאבים
תמונה של Matthew Brodeur ב-Unsplash