הגנה על סיסמאות - Salt כנגד Rainbow Tables
לבקשת מספר אנשים , הנה דרך מקובלת על מנת להקשיח מנגנוני ססמאות כנגד פעולות סריקת ססמאות בתצורת Rainbow Table ובתצורת Dictionary Attack.
מדהים לגלות לפעמים עד כמה נאיבים יכולים להיות אנשים אשר מגינים על מסדי הנתונים , וקבצי הססמאות או האפליקציות שלהם באמצעות מנגנוני סיסמאות . אז נכון - אני מסכים שצריך לקבוע כל מיני כללים כגון שימוש בתווים מיוחדים , אותיות קטנות וגדולות , וכמובן מספרים - אבל יש סטטיסטיקות מסויימות לגבי חזרה על תווים - פרסמתי בעבר פוסט בנושא ( קישור לפוסט המדובר )
בגדול , לא ניתן להגן בצורה טובה , לפחות לא באמצעים שיש לנו היום - כנגד BRUTEFORCE , אך עם זאת , ניתן להגביל נסיונות הקשה מקבילים וכדומה - בואו נהיה כנים - BF בסופו של דבר מוצא את הסיסמה כ יש ריצה על כל תו בכל תצורה אפשרת , אך עם זאת התהליך יכול לקחת ימים , שבועות , חודשים ולפעמים שנים. ולכן בדיוק קיימות שיטות שונות כגון חישוב לפי טבלאות שייכות ( Rainbow Tables ) ועבודה לפי מילונים , אשר בצורה סטטיסטית מוצאים את רוב התוצאות הרלוונטיות בשלב מוקדם או מאוחר - ויש לכך הגיון צרוף - הרי לכל סיסמה כמעט יש משהו שיוצר טריגר אצל משתמש להשתמש בה - ולכן על ידי בנית מילון עם מילים כאלה חוזרת , או צירופים - ניתן לפצח 85-90 אחוז מהססמאות באופן זה - ולכן שיטות אלו הן היעילות ביותר ביחס של עלות מול תועלת וזמן פעולה , אך מקשות ביותר להגנה כנגדן.
ויש פתרון - SALT.
הקונספט מאחורי עיקרון הSALT הוא פשוט ביותר - בניית תוספים אקראיים למחרוזות הסיסמה בעלי אורך מחושב לפי הסיסמה עצמה - וביצוע HASH רק לאחר התוספת . מה שקורה בעצם הוא הדבר הבא :
מתבצע קלט של סיסמה - נניח - ABcd12!@ שהוא סיסמה מוכרת במילונים רבים ...
על סמך חישוב ערך ASCII של כל תו וביצוע פעולה מתמטית עליהם - מתקבלים ערכים מסויימים שהם ערך מספרי , וערכים תוויים לכל מספר כזה- נניח שיצא - 3 , ולידו zxc למשל.
המספרים מתווספים בנקודת צירוף לסיסמה המקורית - ABcd12!@zxc ורק אז עושים HASH.
החשוב כאן כמובן שהאורך יהיה מחושב לפי התווים בסיסמה , ואז כל כמות התווים שיש לייצר תתבצע לפי אלגוריתם פרטי שנובע מחישוב על הסיסמה ( כדי שיהיה ניתן לבצע השוואת HASH למתן סיסמה )
מה שקורה הוא שבעצם הקשחנו את הסיסמה , כי כעת במקום 8 בתים , היא עכשיו בת 11 בתים , ובשל המילון לא יוכל לזהות את המילים בגלל כל מיני סיבות - למשל - לא יהיו מילים באורך כזה במילון , ובעצם יצרנו סוג של PRIVATE HASH UNDER PUBLICH HASH - לא מושג רשמי , אלא ככה אני נוהג לתאר זאת. בעצם הוספנו מלח לתבשיל שלנו ...
מאותו רגע , מאחר ואין מילים קבועות , ואין תבנית שפת אדם - הHASH יהיה תמיד שונה מאשר התוצאה שיניב המילון ולא ניתן יהיה להשתמש במילונים בצורה יעילה , אני מניח שמדובר בהורדה של כמעט כל הסיכוי למצוא סיסמה בדרך זו . אגב - במערכות רבות מקובל להשתמש בשיטה זו - למשל SecureSolaris ועוד מערכות בעלות סיווג בטחוני - יש דרישת סף לתצורה זו.
מדהים לגלות לפעמים עד כמה נאיבים יכולים להיות אנשים אשר מגינים על מסדי הנתונים , וקבצי הססמאות או האפליקציות שלהם באמצעות מנגנוני סיסמאות . אז נכון - אני מסכים שצריך לקבוע כל מיני כללים כגון שימוש בתווים מיוחדים , אותיות קטנות וגדולות , וכמובן מספרים - אבל יש סטטיסטיקות מסויימות לגבי חזרה על תווים - פרסמתי בעבר פוסט בנושא ( קישור לפוסט המדובר )
בגדול , לא ניתן להגן בצורה טובה , לפחות לא באמצעים שיש לנו היום - כנגד BRUTEFORCE , אך עם זאת , ניתן להגביל נסיונות הקשה מקבילים וכדומה - בואו נהיה כנים - BF בסופו של דבר מוצא את הסיסמה כ יש ריצה על כל תו בכל תצורה אפשרת , אך עם זאת התהליך יכול לקחת ימים , שבועות , חודשים ולפעמים שנים. ולכן בדיוק קיימות שיטות שונות כגון חישוב לפי טבלאות שייכות ( Rainbow Tables ) ועבודה לפי מילונים , אשר בצורה סטטיסטית מוצאים את רוב התוצאות הרלוונטיות בשלב מוקדם או מאוחר - ויש לכך הגיון צרוף - הרי לכל סיסמה כמעט יש משהו שיוצר טריגר אצל משתמש להשתמש בה - ולכן על ידי בנית מילון עם מילים כאלה חוזרת , או צירופים - ניתן לפצח 85-90 אחוז מהססמאות באופן זה - ולכן שיטות אלו הן היעילות ביותר ביחס של עלות מול תועלת וזמן פעולה , אך מקשות ביותר להגנה כנגדן.
ויש פתרון - SALT.
הקונספט מאחורי עיקרון הSALT הוא פשוט ביותר - בניית תוספים אקראיים למחרוזות הסיסמה בעלי אורך מחושב לפי הסיסמה עצמה - וביצוע HASH רק לאחר התוספת . מה שקורה בעצם הוא הדבר הבא :
מתבצע קלט של סיסמה - נניח - ABcd12!@ שהוא סיסמה מוכרת במילונים רבים ...
על סמך חישוב ערך ASCII של כל תו וביצוע פעולה מתמטית עליהם - מתקבלים ערכים מסויימים שהם ערך מספרי , וערכים תוויים לכל מספר כזה- נניח שיצא - 3 , ולידו zxc למשל.
המספרים מתווספים בנקודת צירוף לסיסמה המקורית - ABcd12!@zxc ורק אז עושים HASH.
החשוב כאן כמובן שהאורך יהיה מחושב לפי התווים בסיסמה , ואז כל כמות התווים שיש לייצר תתבצע לפי אלגוריתם פרטי שנובע מחישוב על הסיסמה ( כדי שיהיה ניתן לבצע השוואת HASH למתן סיסמה )
מה שקורה הוא שבעצם הקשחנו את הסיסמה , כי כעת במקום 8 בתים , היא עכשיו בת 11 בתים , ובשל המילון לא יוכל לזהות את המילים בגלל כל מיני סיבות - למשל - לא יהיו מילים באורך כזה במילון , ובעצם יצרנו סוג של PRIVATE HASH UNDER PUBLICH HASH - לא מושג רשמי , אלא ככה אני נוהג לתאר זאת. בעצם הוספנו מלח לתבשיל שלנו ...
מאותו רגע , מאחר ואין מילים קבועות , ואין תבנית שפת אדם - הHASH יהיה תמיד שונה מאשר התוצאה שיניב המילון ולא ניתן יהיה להשתמש במילונים בצורה יעילה , אני מניח שמדובר בהורדה של כמעט כל הסיכוי למצוא סיסמה בדרך זו . אגב - במערכות רבות מקובל להשתמש בשיטה זו - למשל SecureSolaris ועוד מערכות בעלות סיווג בטחוני - יש דרישת סף לתצורה זו.
Labels: bruteforce, passwords, thesis
| Link 
זה קצת Security by obscurity.
יש שתי דרכים שאני רואה מייד להתגבר על זה:
1. אם התוקף מנסה לאמת את הסיסמא דרך מנגנון האימות שלך, אז תפעיל אל הפונקציה בשבילו.
2. זו פונקציה, אם התוקף מגלה אותה אז היא לא שווה כלום (ולא תוכל לשנות את הפונקציה בעתיד אם תחשוש שגילו אותה כי התוצרים שלה יהיו מפוזרים כפרורי מלח קטנים מאוד בתוך הHASH של הסיסמאות הקיימות).
המקרה היחיד שבו הפונקציה עוזרת היא אם התוקף הצליח לשים את היד על בסיס הנתונים אבל לא על הקוד של הפונקציה.
זה אומנם אפשרי, במיוחד בעולם שבו הזרקת SQL היא כל כך נפוצה, אבל שווה להשתמש בטכניקה רק אם הקוד סגור (שוב, security by obscurity).
Posted by
Omry Yadan |
6:18 AM
בארי, לפי מיטב ידעתי כמעט כל הפצות הלינוקס / יוניקס משתמשות בסוג מסויים של "המלחה" במנגוני ה - shadow .
~עינב
Posted by
Anonymous |
8:17 AM
לעומרי.
לא מדובר במשהו שרלוונטי מבחינת גילוי הפונקציה. הסיבה לכך היא די ברוה - שמה שאנחנו מחפשים בסוף הוא את הHASH ... ובמידה ואנחנו צריכים
הרי כל מנגנון בדיקת הסיסמאות הוא מנגנון של השוואת תוצאות HASH ולא של ססמאות אמיתיות , ולכן לא שנה התוספים לסיסמה - אבל ! ברגע שלמילון אני מוסיף תווים נוספים אז ההשואה שהוא יבצע מול הHASH לא יכולה להתאים כי הוא אינו מודע לתווים הנוספים - וכן , יש כאן גם עניין של מודעות ..
אגב - מקור מידע טוב להתחיל איתו הוא ויקיפדיה
Posted by
barry |
8:47 AM
עינב , נכון לחלוטין.
בניגוד אגב לשיטת שימור הסיסמאות של מערכות חלונות - NTLM אשר אינו ממליח את הסיסמאות
Posted by
barry |
8:48 AM
בארי,
בוודאי שכן:
זו פונקציה, מכאן שעבור קלט מסויים היא מחזירה _תמיד_ את אותו הפלט.
אם אני יודע את הפונקציה, אני יכול להפעיל אותה כחלק מתהליך של פיצוח הסיסמאות בכוח-גס עם מילון וכו', מה שאומר שכל ההמלחה הופכת ללא מועילה אם הפונקציה מתגלה.
Posted by
Anonymous |
11:10 PM
עמרי,
אם אתה יודע את הפונקציה אז אתה צריך לשלב אותה על כל מילה במילון , ועדיין לקבל זמן ריצה משוער של מילון מורכב . אתה יכול להגיד את אותו דבר לגבי כל פונקציה - לכן אגב הפונקציה הזו היא כמובן סודית , ו ויתרה כך - עצם העובדה שמשתמשים בה הוא עניין סודי.
להגיד שכל מה שאני צריך זה פונקציה , זה בערך כמו להגיד - כל מה שאני צריך זה את הסיסמה ... זה נכון , אבל בוא נהיה מציאותיים , זה רחוק שנות אור מלפתוח את הדלת , ויעצור 99 אחוז מהנסיונות המוצלחים
Posted by
barry |
8:34 AM
בארי, זה בדיוק Security by obscurity.
זה עובד לפעמים, אבל אסור שזה יהיה הדבר היחיד שאתה עושה, ואסור להסתמך על זה.
במקרה שהקוד זמין כולם יודעים את הפונקציה, ואז מה הועילו חכמים?
כמובן, אפשר לבחור אקראית (פעם אחת בלבד, לא בכל הרצה) פונקציה מתור רשימה גדולה ולעבוד איתה מאותו רגע ועד קץ הדורות, אבל זה עדיין לא ממש עוזר ומשאיר את הקושי של פיצוח הסיסמא באותה רמת סיבוכיות.
אני מבין את הטעם בזה, אבל לדעתי יותר מהכל זה נותן תחושת ביטחון כוזב.
Posted by
Anonymous |
11:12 AM
ואגב, אחת הדרישות הבסיסיות ביותר ממערכת הצפנה היא שהקוד לא יהיה סוד.
לראיה, כל האלגוריתמים להצפנה ידועים,וזה לא ממש עוזר לאף אחד.
הקושי הוא לא בסודיות אלא בפעולות מתמטיות שלא ידועה דרך מהירה לבצע אותן.
אגב, גוגל האלו ממש נאג'סים.
לא יכולים לזכור את השם והאתר שלי אחרי הפעם הראשונה שאני מכניס אותו?
עצלנים.
Posted by
Anonymous |
11:14 AM
המטרה לא שזה יהיה הדבר היחיד שאתה עושה , ויתכן שפה אני ואתה נמצאים בקצר בתקשורת , מדובר בנדבך נוסף אשר מטרתו לשפר ולהקשיח.
מדובר כמובן אגב , בפתרון שמאושר ונדרש על ידי מערכות EAL5+ כך שאכן נבדקו הדברים במעבדות ונמצאו כיעילים.
Posted by
barry |
12:47 PM
I definitely love this site.
http://sites.google.com
https://www.blogger.com/blogger.g?blogID=7421661549272645002#allposts
https://www.prokr.net/ksa/jeddah-tanks-isolation/
https://www.prokr.net/ksa/jeddah-water-leaks-detection-isolate-companies/
Posted by
lamiss ibrahim |
6:20 PM