יש הרבה מערכות ואתרים שבהם אבטחת המידע היא אספקט מרכזי של המערכת: בנקים, חברות אשראי, קופות חולים, חברות ביטוח ועוד. גם במקומות אחרים, כמו דואר אלקטרוני, יש סיסמה פשוטה שעוזרת לנו לשמור על הפרטיות שלנו.
מה הגבול למכשולים שאבטחת המידע מציבה בפני המשתמש? כמה רחוק כדאי ללכת עם אבטחת המידע? בדקתי בכמה אתרים ישראליים, וגיליתי גישות שונות, חלקן מסוכנות, בעיקר לארגון שהגדיר אותן.
צילום: ברק דנין
סיסמאות: האם הן באמת מגינות על המידע?
סיסמאות נועדו, לכאורה, כדי לשמור על המערכת מפני פולשים זרים. אם אתה יודע את הסיסמה – תוכל להכנס ולראות את המידע האישי שלך; אם לא – תשאר בחוץ או תשחזר את הסיסמה. כדי שהמשתמשים לא יבחרו סיסמאות קלות לניחוש, המערכות מאלצות אותם להכניס גם מספרים, אותיות גדולות באנגלית, תווים מיוחדים, ליצור סיסמאות ארוכות ועוד ועוד.
הנה למשל הטקסט של ויזה-כ.א.ל, שמסביר כיצד לבחור סיסמה:
והנה זה של בנק לאומי:
במבט ראשון, זה נראה מנגנון מצויין. העניין הוא שמנגנון הסיסמאות רחוק מלהיות טוב, וכולנו אשמים בזה. לא בגלל שאנחנו לא יודעים להשתמש בו, אלא פשוט בגלל שלרובנו אין זיכרון מוצלח במיוחד. רובנו שוכחים את הסיסמאות בקלות. ככל שהדרישות מהסיסמה מורכבות יותר, יותר קשה לנו לזכור אותה. לכן כולנו מתנהגים באחת משלוש דרכים טיפוסיות:
- הטירונים/העצלנים/האופטימיים לא עושים כלום, ובדרך-כלל שוכחים את הסיסמה. הם משחזרים אותה בפעם הבאה שהם צריכים אותה. כאן סיכון האבטחה הוא המזערי ביותר.
- המנוסים/הקפדנים/הפסימיים רושמים את הסיסמה, על דף (שמונח לרוב ליד המחשב), במחשב, בסלולר או במקום אחר. מי שיגיע למקום המסתור של הסיסמאות, בין אם בדרך פיזית (פורץ) או בדרך דיגיטלית (האקר), יקבל גישה לכל המידע האישי שלנו.
- אחרים בוחרים את אותה הסיסמה למערכות שונות, כדי שיצטרכו לזכור פחות. מי שישיג את הסיסמה באחד המקומות יקבל גישה מיידית לכל שאר המקומות.
ברור מהרשימה הזו שכללים מורכבים לסיסמה רק מגבירים את הסכנה למערכת, ועשויים להגדיל את הסיכוי שיפרצו אליה. איכשהו במאבק בין חוויית המשתמש לאבטחה אנשי האבטחה נראים מפחידים יותר, כנראה, והתוצאה היא, באופן אירוני, חורים במערכת האבטחה.
שם משתמש אמיתי או מזהה אקראי?
יש לא מעט ארגונים, ובמיוחד בנקים, שמייצרים עבור המשתמשים שם משתמש אקראי, לכאורה כדי לשפר את האבטחה. הבעיה עם שמות משתמש כאלה זהה לזו של הסיסמאות המורכבות: הסיכוי שנזכור את שמות המשתמש האקראיים הללו הוא אפסי, אין לנו את היכולת ולרוב גם לא את הרצון. לכן ברוב המקרים, במקרה הטוב, נרשום אותם איפשהו, או במקרה הגרוע, נתקשר לשירות הלקוחות כשנצטרך אותם. בבנקים מסויימים צריך לגשת לסניף או לחכות למעטפה בדואר כששוכחים את שם המשתמש.
שמות המשתמש היחידים שקהל רחב מצליח לזכור אותם לאורך זמן הם כאלה שמשתמשים במידע אישי, כמו שם, מספר תעודת זהות, או דוא"ל. במקרים כאלה רצוי להשתמש בשם השדה הנכון ולא בכותרת הכללית "שם משתמש" במסך הכניסה, גם אם איש אבטחת המידע עומד על הרגליים האחוריות.
הנה למשל מסך הכניסה של סוכנות הביטוח "תמורה" שבו התכוונו להגיד "מספר תעודת זהות" אבל במקום זה אמרו "שם משתמש". כמה משתמשים זוכרים ששם המשתמש שלהם הוא מספר תעודת הזהות שלהם?
תוספות לשם המשתמש
יש לא מעט מקומות שמנסים להגביר את האבטחה על המערכת באמצעות צירוף של כמה שדות מזהים נוספים לשם המשתמש כשנכנסים למערכת. בקופת חולים כללית, למשל, נדרשים להזין קוד משתמש שנבחר עבור המשתמש על-ידי הקוּפָּה, וגם את מס' תעודת הזהות:
במאוחדת צריך להזין את מספר כרטיס החבר, בנוסף לשם המשתמש שניתן על-ידי הקוּפָּה:
בבנק לאומי נדרשים להזין גם שם משתמש אקראי וגם "שדה מזהה", שהוא לפעמים מספר החשבון ולפעמים משהו אחר (כשיש יותר מחשבון אחד), ובכל מקרה בטופס הכניסה רשום "שדה מזהה" ולא מספר חשבון:
תוספות מהסוג הזה אולי נותנות הרגשה נוחה לאנשי האבטחה, אבל ללקוחות שרוצים וזכאים להכנס לחשבון שלהם, זהו מכשול. כפי שכבר הסברתי למעלה, זה בדרך-כלל לא ממש משפר את האבטחה.
אז מה עושים עם המשתמש והסיסמה?
לעניות דעתי, כדי למנוע פריצה בצורה יעילה מספיק לעשות שני דברים:
- לחסום שימוש בסיסמאות נפוצות, כמו רצף מספרים 12345 או 11111, רצף מקשים במקלדת כמו qwerty או 1qazse4, או פרטים אישיים של המשתמש, כמו השם שלו, מספר תעודת זהות, טלפון, תאריך יום הולדת וכו'. זו הנטייה הראשונה של רוב המשתמשים, ואלה גם הסיסמאות הראשונות שפורצים פוטנציאליים ינסו.
- לחסום כניסה למערכת, באופן זמני או קבוע, אחרי מספר נסיונות כניסה כושלים, ולהציע למשתמש שחזור או איפוס סיסמה. כך יחָסמו נסיונות של מערכות פריצה אוטומאטיות, בלי לפגוע בחוויית המשתמש בצורה קשה.
המהדרין יכולים להוסיף שיחת טלפון ללקוח, על-ידי נציג או באמצעות מערכת טלפונית אוטומאטית, שתיידע אותו לגבי נסיון הפריצה לכאורה, ותשאל אותו האם הוא רוצה לבצע פעולה כלשהי בעקבות האירוע. למשל, אם זה הוא שניסה להכנס, הוא בוודאי ירצה לאפס את הסיסמה. אם זה היה מישהו אחר, הוא עשוי לרצות לשנות את שם המשתמש.
הנה דוגמא מארה"ב לדבר נוסף שאפשר לעשות כדי לשפר את האבטחה – אך בעלות נוספת לעסק וללקוח. ב-CitiBank הכניסה הרגילה לחשבון מורכבת משם משתמש וסיסמה בלבד:
ללקוחות שמעוניינים בכך, יש אפשרות לקבל אבטחה מוגברת בדמות "מחולל סיסמאות" שמייצר סיסמה חדשה כל 60 שניות – מפתח דיגיטלי. שרתי האבטחה של הבנק מסונכרנים עם המפתח הדיגיטלי, כך שאלא אם מישהו השיג את המשתמש, הסיסמה וקיבל גישה פיזית למפתח, אין לו סיכוי להיכנס לחשבון. ככה הוא נראה:
שחזור סיסמה
כדי ששחזור הסיסמה יהיה יעיל ומוצלח, נדרשים שני מרכיבים:
- דרך לזהות את המשתמש בצורה חלקית, ללא סיסמה.
- מקום שאליו אפשר לשלוח את הסיסמה החדשה (זמנית בדרך-כלל).
כששם המשתמש הוא אימייל, מספר תעודת זהות או מזהה אחר שהמשתמש זוכר בקלות (כזה שהוא בחר בעצמו, למשל), שלב 1 עובר בקלות. במקומות שבהם מקפידים על האבטחה נוהגים לשאול לאחר הקלדת שם המשתמש שאלות נוספות, שבסבירות גבוהה אדם זר לא ידע את התשובה אליהן.
הנה למשל בכ.א.ל, מבקשים בשלב ראשון פרטים על כרטיס האשראי ומציגים captcha. למי שמחזיק בכרטיס הפיזי קל לענות על השאלות:
בשלב השני מבקשים תשובות לשאלות שבסבירות גבוהה רק בעל הכרטיס ידע לענות עליהן (טשטשתי אותן כאן מסיבות מובנות…)
את התשובות לשאלות האלה המערכת מבקשת בדרך-כלל בזמן ההרשמה, באתר האינטרנט או באמצעות פקיד בטלפון או בסניף, ודואגים לזיהוי וודאי של המשתמש בשלב הזה. כשהמשתמש רוצה לשחזר סיסמה הוא מתבקש לתת את התשובות האלה שוב:
יש מקומות שלוקחים את העניין הזה רחוק מדי, עד כדי כך שהוא הופך את מנגנון שחזור הסיסמה ללא רלוונטי. בסוכנות הביטוח "תמורה", למשל, מבקשים מהמשתמש לזכור גם את השאלה וגם את התשובה, ובכך מפספסים את כל הרעיון בשאלות אבטחה מהסוג הזה.
המטרה היא לא לבדוק את הזכרון של המשתמש, ולראות אם הוא זוכר מה שאלת האבטחה שהגדיר, אלא לוודא שהוא מי שהוא אומר שהוא, על-ידי שאלה שהמשתמש המורשה ידע את התשובה אליה בקלות, אבל כל אחד אחר לא ידע.
כך זה ב"תמורה":
אגב, כדי לעשות את זה עוד יותר קשה, ב"תמורה" גם משנים את הסיסמה באופן אוטומאטי עבור המשתמש פעם ב-6 חודשים. מאחר והשימוש במערכת כזו, שעוקבת אחרי תיק ביטוח פנסיוני, קרן השתלמות וכו', הוא לא ממש תדיר, המשמעות היא קשה: גם עבור הלקוח וגם עבור שירות הלקוחות. הלקוח מטורטר לשירות הטלפוני על כל פניה, והשירות מצידו נאלץ לענות להרבה פניות שהיו יכולות לקבל מענה על-ידי האתר. אני משוכנע שזה עולה ל"תמורה" הרבה כסף.
ב-Skype יש שם משתמש, אבל בשביל לשחזר סיסמה הם לא דורשים לזכור גם את שם המשתמש. מספיק לזכור את האימייל שנרשמתם איתו. כמה נוח! לעומת סקייפ, יש כמה מערכות, למשל הפורומים של "זמן דיגיטלי" שבהן בלי שם המשתמש אי אפשר לשחזר סיסמה. נחשו מה קורה במערכות האלה? נכון מאוד, אנשים יוצרים לעצמם שם משתמש חדש בכל פעם שהם שוכחים את הסיסמה.
לסיכום
סיסמאות מורכבות בדרך-כלל גורמות לפרצות באבטחה, במקום לשיפור שלה. עדיף שהמערכת תתמודד עם נסיונות פריצה בצורה נבונה, מאשר לדרוש מהמשתמשים לבחור סיסמאות שקשה לזכור. קל לנו יותר לזכור שמות משתמש וסיסמאות שאנחנו הגדרנו. אם רוצים להגביר את האבטחה, עדיף לא לתת למשתמש עוד שדות לזכור בעל-פה בנוסף לשם המשתמש שלו. כשמתכננים ממשק לשחזור סיסמה, חשוב להקפיד לשאול את המשתמש רק שאלות שהוא ידע עליהן את התשובה בקלות, ושאחרים לא ידעו לענות עליהן בכלל (בסבירות גבוהה).
אשמח מאוד לשמוע את דעתכם ומנסיונכם בתחום.
בתקווה שהמלאכים הרעים לא יבואו לבקר אצלי על סמך הכתוב להלן:
כמה נקודות:
1. אצלי יש חלוקה – ססמא אחת מרכזית (שגם אותה הספקתי להחליף בינתיים) למייל. אני לא משתמש בססמא זו בשום מקום אחר וגם לא רשמתי אותה בשום מקום. (רמת אבטחה גבוהה).
2. לאתרים שדורשים הרשמה אבל אין לי כח להזכר כל פעם בססמה, וגם לא אכפת לי שיפרצו לי לחשבון שם, אז אני משתמש בססמא אחרת, אבל פחות מקפיד על שמירתה. קחו בחשבון שגם בזה יש סיכון מסוים, שהרי לפעמים תשאירו פרטים מזהים גם באתרים כאלו, כגון ת. לידה וכו')
3. באתרים שנדרשת ססמא ייחודית וגם מאובטחת, אני משתמש במילת מפתח + צירוף מספרים משתנה בצורה עקבית באחת הספרות (לא הראשונה / האחרונה). זה כמובן לא מאה אחוז, אבל נראה לי סביר.
4. אני מכיר חברים שמתנהלים ביחס לנק' 1 עם פיירפוקס וסיסמת על שמגינה על כל הססמאות.
והמלצה אחרונה – OPENID שמאפשרת את אותו הרעיון לעיל עם ססמא מרכזית אחת בצורה מעט יותר מורכבת הדורשת שת"פ של האתרים עצמם.
זו אופציה שלצערי לא כל האתרים עדיין אימצו (ברק, זה יכול להיות מחקר בפני עצמו לפוסט ההמשך 🙂
תודה על הפוסט!
היי אוריאל,
תודה על חשיפת כל הסודות המקצועיים שלך בניהול סיסמאות 🙂
רציתי בפוסט להתמקד במערכות שבהן נדרשת רמת אבטחה גבוהה מאוד, כאלה שלא סביר שילכו עם OPENID. חוץ מ-OPENID שהוא פתרון טכנולוגי מצויין, יש פתרונות טכנולוגיים נוספים, כמו תוכנות שזוכרות עבורך את כל הסיסמאות בכל האתרים (מעולם לא סמכתי על כאלה).
למי שרוצה לקרוא על OPENID מצד המשתמש:
http://openid.net/get-an-openid/what-is-openid/
ומידע לבעלי אתרים:
http://openid.net/add-openid
פוסט מצויין.
זיהיתי עוד כמה מכשלוים בתהליך:
1. עברית/אנגלית – מומלץ להציג את שפת הכתיבה – או להציג את הסיסמא עצמה (ללא הכוכביות) – ברק כבר כתב על זה שנילסן כתב על זה…
2. אותיות קטנות גדולות – לא תמיד ברור אם יש רגישות או אין
3. בשאלות שחזור – לרב יש שאלות קבועות ואני תמיד מסתבך איתן – שם חיית המחמד – יש לי חמישה (ואחת שהשתמשתי בה נפטרה…) ואיך אייתתי את שם החתולה שלי?! גם שם בית הספר שלי יכול להיות עם מקף או ללא, בכתיב חסר או מלא. אפילו השם של אמאשלי יוצר לי אותה בעיה. בקיצור – שלשום נחסמה לי גם אפשרות שחזור הסיסמה במנורה-מבטחים אחרי שניסיתי כמה קומבינציות… גררררררר…
בד"כ אני מעדיף שישלחו סיסמא חדשה לאימייל הרשום במערכת. לא הכי מאובטח – אבל נח.
והכי מעניין שלמרות שזו אחת הבעיות הכי נפוצות – אין עדיין פתרון אחיד ומקובל – זיהוי ביומטרי, כרטיס חכם וכו'
יש גם טכנולוגיות שמקלות על הזכירה – כמו הצגת תמונה ועליך ללחוץ על פריטים מסויימים הבסדר מסויים. אבל שוב – שם משתמש וסיסמא הם הכי זמינים ונפוצים.
ברק,
תודה על הפוסט הנהיר והבהיר.
אהבתי את השיטה של "תמורה" שמבקשת שאלה ותשובה… זה פשוט גדול.
בגיל 67 כשתבוא להתחיל לקבל שם פנסיה, בוודאי יבקשו ממך קודם כל "כמה אתה חושב שמגיע לך?"
תודה על התגובות, אבשלום, יורם.
יורם, אני חושב שהם ישאלו קודם: "מה השאלה שביקשת שנשאל אותך בשביל לתת לך את הכסף?" – "לא זוכר!" – "אז אין כסף!" – "אבל הייתי בן 30 כשהגדרתי את השאלה!" – "'צטערת…"
אבשלום, תודה שהזכרת את הפוסט ההוא על הסתרת סיסמאות, הוא גרר הרבה תגובות… הנה הוא כאן:
http://www.usable.co.il/archives/1420
בעניין שחזור הסיסמה לדוא"ל, אני מסכים שזה לא מאובטח. במיוחד עבור חשבונות בנק בהם אפשר לבצע פעולות ברשת כמו העברה מחשבון אישי לחשבון אחר. במקומות שבהם אין כסף או מידע סודי מעורב, אם עושים שהשחזור שולח קישור זמני שיהיה בתוקף לזמן קצר, נאמר – 30 דקות, אני מאמין שזה פתרון סביר.
במערכות פיננסיות תמיד יעדיפו (ובצדק) אימות טלפוני, באמצעות מסמך שנשלח באימייל או בפקס, או אם אין ברירה – פנים מול פנים. אני חושש מהיום שבו הפתרון יהיה ביומטרי, גם בגלל החדירה לפרטיות, ומקווה שתהיה דרך יותר מוצלחת.
בבנק לאומי הכניסו לאחרונה למענה הקולי מערכת לזיהוי קול. היא עובדת בצורה מעט מסורבלת אבל זה יכול להיות כיוון מצויין, גם לזיהוי דרך הרשת, אגב. מידע הקול שאפשר להעביר באמצעות מיקרופון ומחשב הוא עשיר בהרבה מזה שהטלפון מסוגל להעביר (טווח תדרים, איכות דגימה וכו'). זה סוג של ביומטריה שיכול להיות יעיל מצד אחד, ולא פולשני (כמו טביעות אצבע) מצד שני. אם הוא יהיה אפקטיבי מבחינת אבטחה – זכינו.
אחלה פוסט ברק!!!
אני איבדתי לא מזמן את ה – wish list שלי באמאזון (היו לי תוכניות יומולדת על זה) עקב אבדן החשבון שלי, ממש מבאס.
איך זה שלא דיברת על קפצ'ה ? בזמן האחרון נתקלתי בכמה מקרים בצירופים שהתקשיתי לזהות – מוגזם, לא?
תודה, נורית!
צודקת, בהקשר של חסימת בוטים ומזיקים אחרים בהחלט קפצ'ה יכולה לעזור.
לדעתי אפשר לוותר על הקפצ'ה לגמרי אם חוסמים את החשבון לנסיונות שחזור/כניסה עם סיסמה, אחרי כמה נסיונות (חסימה זמנית או קבועה). כמובן שבכל אתר ומערכת זה אחרת, ויכול להיות שזה ייצור עומס מיותר על שירות הלקוחות (אם יש כזה בכלל) – גוגל הוסיפו קפצ'ה אחרי נסיון או שניים שגויים כנראה בדיוק מהסיבה הזו.
ובעניין הקפצ'ות הבלתי קריאות, זו אכן בעיה. נסי לפענח את הקפצ'ות לעיוורים בג'ימייל, זה בכלל בלתי מובן. אני מניח שעם הזמן, כמו בדיון כאן למעלה עם אבשלום, יצטרכו להיווצר פתרונות אלטרנטיביים לאבטחה, אולי ביומטריים, אולי אחרים. קפצ'ה היא בהחלט פגיעה קשה בשמישות, במיוחד עם קהל מבוגר וכשהקפצ'ה מורכבת מדי.
נורית, קיימת דיעה שימיהן של הקאפצ'ות ספורים בכל מקרה 🙂 http://uxtasy.wordpress.com/2009/11/26/captcha/
ברק, לא הייתי אומר שאתר "תמורה" מכריח את המשתמש לזכור גם את השאלה וגם את התשובה – אם הוא זוכר את התשובה, אז מן הסתם שהוא ידע מה הייתה השאלה, ולרוב גם להיפך (למרות שאבשלום מעלה טענות מעניינות לגבי זה). מה שכן, הוא באמת מכריח אותך לנסות לנחש כיצד בדיוק ניסחת את השאלה, עד רמת האות, ולדעתי זה כבר באמת ברמת הניחוש ולא הזיכרון, כי גם אם הוא זוכר שהתשובה היא "ברוריה", אין מצב שהמשתמש יזכור באילו מילים בדיוק הוא ניסח את השאלה לגבי שמה של המחנכת הראשונה שלו. אז אני מסכים שזאת פאשלת שימושיות אומללה במיוחד.
מדובר, למעשה, בשלושה נושאים שונים – שמישות, אבטחה וחווית משתמש.
ההבדל בין אבטחה לחווית משתמש די ברור, אבל מעניין לציין ההבדל שקיים, כשעוסקים באבטחת מידע, בין שמישות לבין חווית משתמש.
מבחינת שמישות, כל מה שמקשה או מעקב את תהליך העבודה, פוגע במערכת.
מבחינת חווית המשתמש, יש לא פעם ערך מוסף משמעותי לחווית המרחב הממוגן. משתמשים מרגישים בטוחים יותר כשהמערכת יוצרת תחושה שהי מוקפת בשכבות הגנה. מערכת מאובטחת שלא תחווה ככזו, תהיה אולי שמישה יותר, אך במחיר של פגיע בחוויה של מרחב מוגן, חוויה שלא פעם יש לה חשיבות שיווקית.
(הרחבתי על נושא זה במאמר " העיקר היעילות?" – http://ranli.blogix.co.il/2010/01/26/experience-efficiency-2/ )
ויטלי, השאלה הוגדרה לפני כ-4 שנים (היא באמת הוגדרה לפני 4 שנים). מה הסיכוי שאני אזכור אותה היום כשאני בא להסתכל על הצבירה בתוכנית הפנסיה שלי? לא ראיתי תקדים לזה בשום מערכת.
רן, באופן כללי – אתה צודק, ותארת בפוסט יפה את המתח בין שמישות לבין החוויה. אבל עניינית, אם ל-CitiBank מספיקים שם משתמש וסיסמה, אני בטוח שגם לתמורה זה יכול להספיק. גם לבנק לאומי וקופ"ח מאוחדת, לצורך העניין. יש פה סרבול מיותר, שמעמיס על המשתמשים, ולדעתי לא ממש מייצר כאן חוויה של "מרחב מוגן" כפי שאתה מגדיר אותה.
נכון, אבל בכל מקרה היא לא מכריחה אותך לזכור את שני הדברים :). אם תזכור את השאלה, אז כנראה שכבר תדע את התשובה ולא תצטרך להזכר בה בנפרד.
לעניות דעתי, אחת הסיבות לבעייתיות בתהליכי גישה מאובטחת לאתרים הוא ראיית המיקרו הממוקדת מדי ממנה סובלים חלק ממומחי אבטחת המידע.
למומחים, בכל תחום שהוא, יש נטייה להתמקד בתחומם ולשכוח את ההקשר הרחב יותר, שבסופו של דבר רלוונטי מאוד לתחום בו הם עוסקים. כמו אצל אנשי שיווק שמתמקדים יותר מדי בכתיבת טקסט מוכוון SEO ועשויים תוך כדי כך לפגוע במיתוג של המוצר שלהם באינטרנט, כך מומחי אבטחה שמנסים להגביר את האבטחה, שוכחים לפעמים שבצד השני של המקלדת יושב לקוח אנושי. כשמעיקים על הלקוח יותר מדי בכל מני אופני אבטחה מורכבים, הלקוח פשוט מחפש (ומוצא) דרכים להקל על עצמו.
לדוגמה, על פי התפיסה הצרה של אבטחה, ככול שקוד הכניסה מסובך וארוך יותר, כך הוא מאובטח יותר. קראתי לפני זמן מה על מערכת שחייבה את המשתמשים בהזנת קוד של 40 (!) תווים. אם זה לא מספיק, בכדי "לשפר" את האבטחה עוד יותר, המשתמש רואה בעת ההקלדה כוכביות במקום תווים. כמובן שרוב בני האדם לא טורחים לשנן קוד שכזה, והכוכביות מונעות מהם כל אפשרות של בדיקת תקינות הקלדה. מה עושים רוב המשתמשים הנבונים? רושמים את הקוד בקובץ, ומעתיקים אוו משם.
התוצאה – המחסום הכבד שהציבו אנשי האבטחה פשוט גרם למשתמשים ללכת בדרך עוקפת – ולא מאבטחת בעליל.
באבטחה, כמו בשאר התחומים של עיצוב חווית המשמש, נדרשת גישה הוליסטית. יש לקחת בחשבון לא רק את האבטחה ה"טכנית" של הנתונים (קודי גישה, סיסמאות וכו') אלא גם את האופן בו משמשים מקיימים אינטראקציה עם המערכת.
רן, את אותו הדבר אומרים מומחי האבטחה על אנשי חוויית משתמש 🙂 אבל אני מסכים עם כל מילה. הראייה ההוליסטית היא הנכונה, והאתגר של כולנו, אנשי UX ואנשי ניהול המוצר, הוא למצוא את דרך האמצע: זו שמרצה את כולם, לפחות באיזושהי רמה.
ויטלי, *אם* אזכור את השאלה… זה "אם" מאוד מאוד גדול 🙂
הנה רשימה מצויינת, יותר רחבה משלי, לסיסמאות נפוצות, וטיפים לאיך לבחור סיסמה חזקה:
http://www.blogherald.com/2007/05/08/protect-your-blog-with-a-solid-password/
אחלה סקירה.
תודה על הפוסט 🙂
תודה על הסקירה!
— "רצוי להשתמש בשם השדה הנכון ולא בכותרת הכללית "שם משתמש" במסך הכניסה, גם אם איש אבטחת המידע עומד על הרגליים האחוריות." —
אם איש האבטחה טוען כך, הזכירו לו את עקרון קרקהופס: בסופו של דבר התוקף ידע איך עובדת המערכת, למשל שהשדה הוא תעודת זהות. אפשר וצריך להסתיר רק את הערכים הספציפיים (הפרטים של כל משתמש), אך לא את העובדה הכללית.
הפרסום ב-UXI עובד… הודיעו לי מ"תמורה" שהם תיקנו את הממשק, בינתיים רק את שחזור הסיסמה ולא את ההזדהות ("תעודת זהות" במקום "שם משתמש") כפי שהערתם – רן ומוטי, אבל המענה המהיר מעודד. עכשיו כשמשחזרים סיסמה מופיעה השאלה שהגדרתי, כך שעלי מוטל (כראוי) רק לזכור את התשובה.
מרטין ומוטי, תודה על הפרגון 🙂
מה שלי אישית מפריע בהרבה מהאתרים הללו, בהקשר של סיסמאות, היא דווקא המוגבלות של הסיסמאות- מבחינת סוג התווים ואורך הסיסמא.
הרבה יותר קל לזכור passphrase מאשר password- אבל המערכות הללו לא תומכות בסיסמאות ארוכות.
שיטה קלה נוספת ליצירת סיסמא קלה לזכירה וקשה לניחוש היא "החלפה" של מלה בסימנים "מיוחדים".
כדוגמא פשטנית, במקום password לכתוב P@$$~0^d.
הבעייה היא שהמערכות הללו לא מאפשרות בדרך כלל להשתמש בתווים כאלו בסיסמא, כך ששוב הם דוחפים את המשתמש לשיטת הפתק על הצג…
אני עם Xslf, הדרך הנכונה היא להמליץ למשתמש על החלפות ולאפשר תווים מיוחדים., אם תשים בטקסט ההסבר את דוגמת החלפת ה Password ב P@$svv0rrd אז אנשים יבינו שהאות איי (i) יכולה להיכתב כ 1 או ! או | או אפילו ו (וו בעברית) שלא לדבר על נון סופית…
אני לגמרי עם ענייני ה passphrase וחושב שזה אידיוטי להגביל אותי ל 8-10 תווים.
לגבי קפצ'ה, אומרים שאת הגירסה הראשונה של קפצ'ה כבר פרצו וצריך, אם כבר משקיעים, להשתמש בקפצ'ה 2 או 3 (הגירסה האחרונה)
לגבי ענייני הוליסטיות, הרעיון הוא שיש מנהלי פרויקט, והם צריכים לראות את התמונה הרחבה. זה added value אם איש UX/UI גם מבין באבטחה (ויודע כמה קל לפרוץ סיסמאות של אותיות בלבד /מספרים בלבד אם מגבילים אותן ל 6-8 תוים) אבל כמו שלא נבקש מאיש שמבין בהצפנות לבנות מודל קונספטואלי של אתר, לפעמים המודולריות האנושית חשובה.