חווית משתמש

אבטחת מידע וחווית משתמש : סיפור אהבה

יואב מורן | 25 באוקטובר 2016

15

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

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

שגרירי המשתמשים

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

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

זיהוי צרכי האבטחה

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

נהלי אבטחה פומביים

כדי שהמשתמשים ירגישו שדואגים לבטחונם, כדאי לאמץ נוהלי אבטחה פומביים (Public Security Policy) שיהיו קלים לאיתור באתר החברה. הנהלים יכילו תיאור של החשיבות באבטחת מידע ופרטי המשתמשים, ושל הצעדים הננקטים לדאוג לכך.

מה כדאי שהנהלים יכילו? הנה מספר דוגמאות לנושאי אבטחה שנרצה לקדם למען המשתמשים:

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

חינוך לאבטחה

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

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

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

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

תהליכים רגישים

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

הגדרת סיסמא וניהולה

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

סיסמא חזקה: חשוב שתעודדו את המשתמש לבחור בסיסמא חזקה על ידי שימוש במיקרוקופי טוב, אולם מהי ״סיסמא חזקה״? הגיע זמן לנתץ עוד מיתוס: סיסמא חזקה לא אומרת בהכרח אותיות קטנות, גדולות, ספרות, סימני פיסוק, סמלים של מזלות ונקודות ברייל מעורבבים יחד בתערובת בלתי זכירה על ידי בן אנוש. סיסמא חזקה מטרתה למנוע פריצה לחשבון, לא למנוע זכירות, והפרמטרים המשפיעים על פריצתיות (מילה שהמצאתי עכשיו, דיבס!) לא מחייבים את הזוועה הקבועה הזו. סיסמא חזקה יכולה להיות פשוט מספר מילים לא קשורות בשפת אדם המוצמדות אחת לשניה. אל תגבילו את אורך הסיסמא, הציעו את הרעיון שהסיסמא תהיה מספר מילים, והוסיפו מד-חוזק סיסמא. כאשר המשתמש בוחר סיסמא תנו לשרת לבדוק מול מילון אם מדובר במילה קיימת (מומלץ גם לבדוק מול רשימות הסיסמאות הנפוצות ביותר, כאלה שהאקרים משתמשים בהן), ואם הסיסמא כולה תהיה מילה אחת כזו – התריעו שמדובר בסיסמא פשוטה מדי והציעו לו רעיונות להצמדת מילה או שתיים למילה המקורית. כאשר המשתמש בוחר סיסמא חזקה באמת כדאי לחגוג את זה עם גרפיקה/ מיקרוקופי, מה שיספק חיזוק חיובי לאבטחה גבוהה.

נלקח מתוך xkcd מספר 936

נלקח מתוך xkcd מספר 936

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

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

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

שימוש ב-Two Factor Authentication) TWA): מומלץ לתמוך ב-TWA. מציק, אולי, אבל בטוח במיוחד. דרך להקל על השימוש ולמנוע הצקות נרחבות: ברגע שמשתמש מאושר על ידי המערכת, אפשרו לו להיכנס בפעמים הבאות רק על ידי pattern lock או PIN code.

המלצות נוספות

לאחרונה שוחררו המלצות של מומחי בטיחות לניהול סיסמאות עבור הארגונים הממשלתיים בארה״ב (NIST). סט המלצות זה מקיף מאד ומהווה את חוד החנית של הידע הקיים בנושא סיסמאות בטוחות. מומלץ לעבור על הסיכום של ההמלצות.

כניסה למערכת

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

2-1

תמיכה במנהלי סיסמאות: בשביל להקל על המשתמשים להתנהל בצורה מאובטחת כדאי לתמוך במנהלי סיסמאות (כמו LastPass, למשל). משמעות תמיכה כזו היא לא לפרק את תהליך ה- log in למספר מסכים/ צעדים אלא למקם את כל השדות באותו טופס, מה שיאפשר למנהל סיסמאות להזין את המידע אוטומטית. חשוב לא ״להמציא״ שדות מסוג חדש ולא מוכר (כמו ״מפתח״ או ״קוד משתמש״) שמנהלי הסיסמאות לא ידעו איך לבלוע. שם משתמש וסיסמא מספיקים, תודה רבה.

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

group-4

איפוס סיסמא:

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

  1. אפשרו למשתמש להזין שאלה משלו. כמעט בלתי אפשרי למצוא סט שאלות שיתאימו לכולם וזה מאלץ משתמשים לוותר על היכולת לשחזר סיסמא או להשתמש בתשובה שאינה קשורה וחוזרת תמיד.
  2. בין המשתמשים יכולים להיות גם כאלה שהם בני 60 פלוס פלוס. אם תציעו להם רק שאלות בסגנון ״המורה הראשונה שלי״ או ״האהבה הראשונה שלי״ לא בטוח שיהיו להם תשובות.
  3. טעמים משתנים. שאלות בסגנון ״המאכל האהוב עלי״ לא בהכרח יניבו את אותה תשובה כעבור מספר שנים.
  4. אפשרו להזין לשאלת אבטחה תשובה עם תווים מיוחדים. כשאתם מונעים את זה אתם מתעלמים מקיום אנשים שלא נולדו בארה״ב, למשל (״מה העיר הראשונה שגרת בה?״ Düsseldorf).

דוגמא למסך כניסה למערכת הבנוי היטב:

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

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

שיתוף

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

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

הרשאות ותפקידים במערכת

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

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

התנגשות בין אבטחה ל-UX

פחות מדי אבטחה

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

דוגמא 1: אפל הכריחה בעבר לבצע אימות OAuth (אימות מול שירות צד שלישי, כמו מול גוגל או פייסבוק) ישירות מהאפליקציות. מה שאמר שאם המשתמש היה מעוניין להרשם באפליקציה ולהיעזר לכך בחשבון של  Spotify למשל, הוא מגיע למסך שנראה כמו Spotify וממלא שם את הפרטים – אבל זה מסך שנכתב ונבנה על ידי אותה אפליקציה, מה שאומר שבאותו רגע היא מקבלת את פרטי שם המשתמש והססמא שלו ב- Spotify. המשתמשים נאלצו לסמוך על האפליקציות שאין להן כוונות רעות ושלא ישמרו את המידע אצלם.

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

יותר מדי אבטחה

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

דוגמא 1: שאלות אבטחה לשחזור סיסמא מתחכמות (״השם של אשתו הראשונה של סבך מצד הדודה״) מאלצות משתמשים רבים למצוא מעקף במטרה לזכור משהו מורכב כל-כך או ישן כל-כך (לך תזכור את שם המורה שלך אם אתה בן 60). דוגמא למעקף שכזה היא כתיבת אותה תשובה בכל השאלות – שמם, מספר הטלפון שלהם או מילה קבועה שמשתמשים בה תמיד. ברור ששיטה כזאת פותחת פירצה להאקר. ניתן לפתור את הבעיה על ידי שימוש בטיפים שהזכרנו קודם.

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

סיכום

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

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

באילו שיטות אבטחה אתם משתמשים באפיונים שלכם? אילו אתגרים נוספים עומדים מולכם כשאתם מנסים לשמור על המידע של המשתמשים?

עוד לקריאה:

http://blog.usabilla.com/credibility-trustworthiness-expertise/

http://www.fastcodesign.com/3059293/security-vs-ux-how-to-reconcile-one-of-the-biggest-challenges-in-interface-design

http://www.dtelepathy.com/blog/design/security-and-web-design

http://10rem.net/blog/2012/02/14/ux-anti-patterns-for-security-on-the-web-and-in-the-enterprise

https://www.sitepoint.com/3-rules-painless-account-ux-login-screens/

https://uxmag.com/articles/security-vs-design-standing-at-odds

אהבתם את הפוסט? אולי תאהבו גם את עמוד הפייסבוק שלנו, אנחנו מעלים טיפים יומיים על נושאים שמרגשים אותנו.

כתיבת תגובה

האימייל לא יוצג באתר.

הוספת תגובה בפייסבוק