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

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

בהנחה שיישום ה- backend שלך ו- SIEM צריכים להציג ניסיונות כניסה נכשלים ליישומים שונים (ובכך להציג את הודעת השגיאה "User P @ $$ w0rd is not valid") אז זה לא יהיה טריוויאלי לעצור את זה.

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

אז הבעיה היא שאתה לא רוצה שאנליסטים יראו את הסיסמאות בקבצי היומן הרגישים?

זהירות: גם אם היית משתמש ב- Javascript הוא לא עוסק בנתוני הסיסמה השמורים בדיסק שלך בטקסט רגיל.

פיתרון טוב יותר הוא לעבד מראש את היומנים לפני שהאנליסטים יראו אותם ולערוך מידע ביומנים.

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

באפשרותך לרשום שמות משתמש בהמתנה כאשר הם מופיעים בקובץ יומן ש

• יש תבנית ([az] + מספר) או ([az] + נקודה + [az])
• כולל שם דומיין ואחריו קו נטוי "\" לסביבות AD
• מופיעים מספר פעמים
• האם יש לשטוף בספריית LDAP של שמות משתמש ידועים לפני שהאנליסטים יראו אותה

אתה מזהה וסיסמאות גם ברשימה השחורה על ידי:

• מדיניות הסיסמאות נוהגת לרוב על פי תבנית (סמל אחד, עליון / תחתון, x תווים ...)

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

אז איך נראה קו מסונן?

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

  eb574b236133e60c989c6f472f07827b Redact1 7e67b89a695bfbffc05b7ed2c38f927f Redact2 ..etc  

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

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

אני יכול לזהות רק שלוש בעיות במה שאתה דן.

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

לדעתי זה פשוט למדי לתיקון.

1. קבל שגיאת משתמש, .
2. אל תרשמי שמות משתמש לא תקפים, במקום היכנס ניסיונות כושלים ו- IP.
3. אל תשלח שמות משתמש בטקסט ברור. השתמש בטכנולוגיה כמו HTTPS או השתמש ב- javascript כדי לקודד את הטקסט הרגיל (למשל ROT13).
o>

יומן דוגמה לכניסה נכשלה ואז לנסות שוב בהצלחה.

  [00:00:00] כניסה לחשבון נכשלה החל מה -192.168.1.100 [00:21:00] כניסה מוצלחת 'שורש' מ- 192.168.1.100  

---

קריאה על פני תשובות אחרות, ברצוני לכלול זאת.

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

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

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

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

אם אתה יכול ליישם את זרימת העבודה הזו, זה יעזור למקד את המשתמשים במה שהם מקלידים ומתי.

כמו כן, בהתחשב בכניסה שלך: אולי תוכל לשנות את הרישום שלך. לא לכלול אישורים ממשיים?

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

אם אתה מבצע בדיקה ושם המשתמש לא שם, משהו כמו "משתמש מכתובת ה- IP '192.168.0.10' ניסה להתחבר באמצעות מזהה משתמש לא חוקי".

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

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

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

1. מזהה משתמש או חסר סיסמה
2. סיסמה שאינה תואמת את ההנחיות
ol>

כך שבכל מקרה כשאתה עדיין רואה ערכים אלה ביומן,

  משתמש P @ $$ w0rd לא יוצא [...] חשבון נכשל בכניסה: P @ $$ w0rd [...]  

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

אז הפוך אותו לאימות דו-מעבר

1. מעבר ראשון, שלח את כל הפרטים המוצפנים כולל סיסמה לשרת. ודא אם שדה הסיסמה ריק.
2. מעבר ראשון, ודא אם הסיסמה תואמת את שגיאת הנחיות אחרת.
3. מעבר ראשון, בדוק אם הסיסמה קיימת ב- DB שלך. אם לא שגיאה.
4. שלח בחזרה תגובת RPC ללקוח והניח לו לשלוח את מזהה המשתמש והסיסמה כעת.
5. כעת בצע את תהליך האימות
ol >

כל מהות התהליך הזה היא

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

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

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

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

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

הבעיה הכללית היא אימות מבוסס סיסמה. כל חנות אמא ופופ מתעקשת לקבל אימות משלה עם סיסמאות. זה טיפשי.

תן לאיזה ספק זהות אחר לעשות את העבודה הקשה בכדי לשמור על אישורי האישורים. בצע את אותו הדבר כמו שעושה StackOverflow: אפשר אימות באמצעות OpenID, Gmail וכו '.

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

סקריפט JavaScript בצד הלקוח נראה סביר.

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

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

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

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

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

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

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

מדוע לא להגיב רק עם זה?

  שם משתמש זה לא קיים  

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

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

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

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

Con: כדי להשוות עם שמות משתמש במסד הנתונים שלך, עליך לאחסן שתי עמודות למשל. 'שם משתמש' ו- 'md5 (שם משתמש)' או שאתה צריך לבצע חשיש דינמי בכל פעם שאתה מבקש שם משתמש להתחברות.

• צור רשומת יומן רק אם שם המשתמש קיים במסד הנתונים, אחרת כניסה IP בלבד.

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

• בצע הגבלה מסוימת לשמות משתמש וסיסמאות מותרים:

  1. סיסמאות חייבות להכיל תו מיוחד כמו! @ # $% ^ & * ()
  2. שמות משתמש לא חייבים להכיל שום תו מיוחד

בדרך זו, תוכל לבצע JavaScript כדי לזהות במהירות אם שם המשתמש שהוזן או סיסמה.

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

יש לי נקודה אחרת ... איזו בעיה אתה מנסה לפתור באמת?

1. סיסמאות גרועות? כְּלוֹמַר. כאשר אתה רואה אדם שמשתמש ב"סיסמה "(או גרסה) אתה רוצה להיות מסוגל להתחקות אחר המשתמש ולתקן אותו?

2. סיסמאות שנשלחות בברור?

3. או הבעיה עם אידיוטים שאינם יכולים להקליד או לקרוא טפסים (או אולי ממשק משתמש מעוצב רע)?

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

עכשיו לכל אחד.

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

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

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

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

רק 2 הסנטים שלי.

ביומטריה זולה למדי כעת ועובדת לפחות 80% מהזמן. אני מוצא את זה נהדר במכשירי TabletPC ורציתי לפרוס מקלדות ביומטריות כי זה מהיר יותר (לפחות 80% מהזמן הזה).

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