הפניה אוטומטית של בקשה אל /.well-known/change-password
לכתובת ה-URL לשינוי סיסמאות
מגדירים הפניה אוטומטית מ-/.well-known/change-password
לדף שינוי הסיסמה באתר. כך מנהלי הסיסמאות יוכלו לנווט ישירות לדף הזה.
מבוא
כפי שאולי ידוע לך, סיסמאות הן לא הדרך הטובה ביותר לנהל חשבונות. למרבה המזל, אנחנו משתמשים בטכנולוגיות חדשות כמו WebAuthn וטכניקות כמו סיסמאות חד-פעמיות, שעוזרות לנו להתקרב לעולם שאין בו סיסמאות. עם זאת, הטכנולוגיות האלה עדיין בתהליך פיתוח, ודברים לא משתנים במהירות. מפתחים רבים עדיין יצטרכו לטפל בסיסמאות לפחות בשנים הקרובות. בזמן שאנחנו מחכים שהטכנולוגיות והטכניקות החדשות יהפכו להיות נפוצים, לפחות נוכל להקל על השימוש בסיסמאות.
דרך טובה לעשות זאת היא להעניק תמיכה טובה יותר למנהלי סיסמאות.
איך מנהלי סיסמאות עוזרים
אפשר להשתמש במנהלי סיסמאות מובנים בדפדפנים או לספק אותם כאפליקציות צד שלישי. הם יכולים לעזור למשתמשים במגוון דרכים:
מילוי אוטומטי של הסיסמה בשדה הקלט הנכון: דפדפנים מסוימים יכולים למצוא את הקלט הנכון בצורה היוריסטית גם אם האתר לא עבר אופטימיזציה למטרה הזו. מפתחי אתרים יכולים לעזור למנהלי סיסמאות על ידי הוספת הערות לתגי קלט HTML בצורה נכונה.
מניעת פישינג: מאחר שמנהלי סיסמאות זוכרים איפה הסיסמה נרשמה, אפשר למלא את הסיסמה באופן אוטומטי רק בכתובות URL מתאימות, ולא באתרים של פישינג.
יצירת סיסמאות חזקות וייחודיות: מכיוון שמנהל הסיסמאות יוצר ושומר סיסמאות חזקות וייחודיות, המשתמשים לא צריכים לזכור תו אחד בכל סיסמה.
יצירה ומילוי אוטומטי של סיסמאות באמצעות מנהל סיסמאות כבר משרתות היטב את האינטרנט, אבל בהתחשב במחזור החיים שלהן, חשוב לעדכן את הסיסמאות בכל פעם שהן נדרשות, כמו יצירה ומילוי אוטומטי. כדי להשתמש בהם בצורה נכונה, מנהלי הסיסמאות מוסיפים תכונה חדשה:
זיהוי סיסמאות פגיעות והצעה לעדכון: מנהלי סיסמאות יכולים לזהות סיסמאות שנעשה בהן שימוש חוזר, לנתח את האנטרופיה ואת נקודות החולשה שלהן, ואפילו לזהות סיסמאות שעלולות להיות דליפו או סיסמאות שידוע שהן לא בטוחות ממקורות כמו Did I Been Pwned.
מנהל סיסמאות יכול להזהיר משתמשים לגבי סיסמאות בעייתיות, אבל יש הרבה חיכוך בבקשה של המשתמשים לנווט מדף הבית לדף לשינוי סיסמה, בנוסף לתהליך של שינוי הסיסמה בפועל (שמשתנה מאתר לאתר). יהיה הרבה יותר קל אם מנהלי סיסמאות יוכלו לנווט את המשתמש ישירות לכתובת האתר לשינוי סיסמה. זה המקום שבו כתובת 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 מתחיל לתמוך ב-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
ומעבדת את הדף 'לא נמצא' בצד הלקוח כשאין תוכן.
במקרי הקצה האלה, המשתמשים יועברו לדף Not Found (לא נמצא) וזה יהיה מקור לבלבול.
לכן יש הצעה למנגנון סטנדרטי
שקובע אם השרת מוגדר להגיב באמצעות 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 ב-UnFlood