תאר לעצמך שאני מכניס את סיסמאות המשתמשים למלח אקראי, מספיק ארוך, באמצעות מתיחת מקשים וחשיש מאובטח. האם יהיה בטוח יותר להצפין סוף סוף את החשיש באמצעות מפתח סימטרי?
מהו מודל האיום? זה יכול להיות מועיל להגן על אחסון הסיסמה באמצעות סוד בצד היישום, אך רק אם אתה חושב שזה תרחיש ריאלי שמסד הנתונים שלך ייפגע - בלי שרת היישומים שלך, המחזיק את סודי, גם לאחר שנפגע.
בדרך כלל שכבת היישום נחשבת לחלק הפגיע יותר ושכבת מסד הנתונים מוגנת יותר, ומסיבה זו אין זה נחשב שימושי להגן על הנתונים באמצעות צד יישום סוֹד. אבל זה לא יכול להיות המקרה של כל אפליקציה, ובאופן אישי הייתי מטיל ספק בהנחה זו בהתחשב בשכיחותה של הזרקת SQL.
החיסרון של הצגת סוד בצד האפליקציה הוא שעכשיו אתה צריך לדאוג תהליכי ניהול מפתח. מה המנגנון שלך להחלפת המפתח אם הוא נפגע? האם אתה מתכוון לסובב את זה כמובן מאליו? כיצד מאחסנים את המפתח שלך כדי שתוכל להעביר שרתים ולא לאבד אותו (שעלול להפוך את כל הנתונים שלך לחסרי תועלת)? למפתחות קצרי מועד (המשמשים למשל לחתימת אסימונים בהפעלה) אולי לא אכפת לך אבל לאחסון סיסמאות לטווח הארוך זה הופך להיות חשוב.
החיסרון הנוסף בצפנים סימטריים (במיוחד צופני חסימות) הוא הטמעתם כהלכה. . מכיוון שאתה גיבוב ואינך זקוק לשחזור, במקום זאת תוכל לכלול את הסוד בחשיש (כ'פלפל ') ... אך אז לא תוכל לחדש את כל נתוני הסיסמה בשינוי מפתח אז תצטרך להשתמש בשיטה מרובת מקשים להפעלה.
תגובה ETA מחדש @ Pacerier:
Hashing אינו מונע התקפת ניחוש לא מקוונת של מישהו שהשיג את מאגר הסיסמאות. זה רק מגדיל את משך הזמן שלוקח לאותה התקפה לשאת פרי; עם תוכנית hashing של קושי מתאים (כלומר סיבובי גזירת מפתח ולא אורך מלח גולמי כשלעצמה), בתקווה זה יגדיל את פרק הזמן הזה מספיק זמן כדי שתוכל להבחין שנפרצת ולשנות את הסיסמאות של כולם לפני רבים מדי החשבונות שלהם אבדו.
הגנה על התוכן באמצעות מפתח סודי (באמצעות הצפנה או כולל המפתח הסודי בחומר הגיבוב) מונעת את התקפת הניחוש הלא מקוון, אך רק כל עוד המפתח הסודי עצמו לא הודלף. אם המפתח הסודי נמצא בשרת האפליקציה בנפרד משרת מסד הנתונים, ניתן לתקוף את הסיסמאות רק אם שתי המכונות נפגעות. מעל להתפשר על שניהם, במיוחד אם שרת האפליקציות ושרת מסד הנתונים הם אותה מכונה. כמו כן יש מחיר לשלם ביכולת הניהול. אז אם יש תועלת נטו צריך להישפט על בסיס כל מקרה לגופו תוך התייחסות למודל האיום.
אני מעריץ גדול של הוספת שכבות הגנה על גבי מערכת מאובטחת כחלק ממדיניות הגנה לעומק. עם זאת, במקרה הספציפי הזה, שימוש בהצפנה סימטרית למשימה זו יוצר בעיה נוספת במערכת; תצטרך לדאוג לניהול המפתח. המפתח חייב להיות מאוחסן איפשהו, ואם ליישום שלך יש גישה אליו, אז לתוקף שפגע במערכת שלך סביר מאוד ש תהיה גישה למפתח.
הליך כזה מוסיף תוספת מורכבות למערכת. המורכבות היא אחד מאויבי הביטחון. אני מאוד ממליץ על זה.
הצפנת חשיפות הסיסמה יכולה להגן על הסיסמאות במצב מאוד ספציפי.
ישנם תרחישים כאשר תוקף מקבל גישה לקריאה למסד הנתונים שלך, הזרקת SQL היא אפשרות אחת, גיבוי דולף או שרת מסולק אחר. במקרה זה, הוא יכול להכריח את חשיפת הסיסמה. עם אלגוריתם חשיש מתאים (פונקציית גזירת מפתח), סיסמאות חזקות יהיו בטוחות, סיסמאות חלשות אם כי ניתן לאחזר פחות או יותר במהירות עם התקפה במילון (נסה את 1000 הסיסמאות הנפוצות ביותר ...).
עם הצפנת חשיפות הסיסמה שלך, אתה מוסיף סוד בצד השרת לחשיפות שלך. כלומר, בנוסף למסד הנתונים, תוקף זקוק כעת להרשאות בשרת (כדי לקבל את המפתח). זהו אותו יתרון שפלפל יכול להעניק לך, אך יש לו את היתרון שאתה יכול להחליף את המפתח בכל פעם שזה נראה הכרחי.
אם המפתח מאוחסן בבטחה לא כל כך חשוב, חשוב הם התוספת הרשאות שהתוקף זקוק להן. במקרה הגרוע ביותר, התוקף יקבל את חשיפות הסיסמה ויש לך את אותו המצב כמו ללא קידוד.
אני חושב שיש מקרה להצפנת עיכול מאובטח.
נראה שמקובל באופן כללי כי השיטה הטובה ביותר כיום היא להשתמש ב- bcrypt, PBKDF2 או אלגוריתמים דומים כדי להמליח ולהחיל גורם עבודה לייצור עיכול הסיסמה. השימוש בפלפל הוא גם דרך מצוינת למתן סיסמאות גרועות או ידועות מכפי שנכפות על עצמם בקלות ללא קשר לאלגוריתם / גורם העבודה בו משתמשים. כדי להתעדכן ככל שישתפר ביצועי הצבא הקשיח ויש לבחור בו כדי למתן התקפות כוח אכזרי, אך לא לאט לאמת את אימות הסיסמה למשתמשים הנכנסים למערכת שלך. על ידי שימוש בהצפנה סימטרית של חשיש סיסמא הן דרישת העומס והן הפלפל אינן נדרשות עוד. בתנאי שהמפתח הסימטרי מוגן היטב (באמצעות HSM למשל) והוקמו תהליכי ניהול מפתחות טובים אני לא יכול לראות חסרון לגישה זו. הקושי במתקפת כוח אכזרי זהה לזה של אכיפת המפתח ללא קשר לשאלה אם הסיסמה איכותית או לא.
אני בהחלט לא אצור תשתית לעשות זאת כמו כל ההערות הקודמות לגבי ניהול המפתח ושמירת המפתח בנפרד משרת היישומים תחול. אבל אם התשתית כבר קיימת ומבוססת היטב, יש בהחלט חסרונות בהצפנת חשיש סיסמא מלוחה.
הייתי אומר שלא. מהסיבות שאדנן אמר, המפתח צריך להיות נגיש, וצעד זה הוא כנראה רק הוספת מורכבות למערכת שהיא מיותרת.
גישה טובה יותר ל- IMO תהיה לראות את ההצפנה כמחשוב שתוכל. להרשות לעצמך, אך לא להשתמש, ולשקול אם תוכל להשתמש במחשוב זה לגישה אחרת של גיבוב.
קיימת תפיסה מוטעית כי שכבת שיטות קריפטו שונות מביאה למצב בטוח יותר מכל פרקטיקה בפני עצמה. עם זאת זה לעתים רחוקות המקרה.
חשיפת סיסמה המיושמת כהלכה עם מלח ארוך מאובטחת באופן קריפטוגרפי. מטרת הגיבוש והמלחת הסיסמאות היא הגנה על הנתונים במנוחה. המשמעות היא שאיש שלא יתפוס את מאגר הסיסמאות שלך צריך לדעת מהן הסיסמאות וגם אם הם מצליחים לפצח סיסמא אחת או יותר שלא אמורות לתת שום יתרון לפיצוח אחר.
כפי ש- Adobe הראתה לנו בשבועות האחרונים צופי חסימות סימטריים אינם מעולים במשימה זו. חשיפה עם מלח נמנעת מבעיה זו לחלוטין.
אחרים ציינו כי הצפנה נוספת של סיסמאות הגיבוב שלך מציגה את בעיית ניהול המפתחות ואינה מציעה אבטחה / חוסן נוסף לנתונים המאוחסנים. ההצפנה טובה כדי להבטיח שרק בעלי האישורים המתאימים יוכלו לגשת לנתונים. ההצפנה הפיכה מסיבה זו. זו לא פרדיגמת אימות.
כאשר אנו מאמתים אנו רוצים שהשרת ישתמש במשהו שהוא יודע (המלח) ובסוד שרק המשתמש שלך מכיר (הסיסמה) כדי ליצור באופן עקבי את אותה כתם ייחודי של נתונים. אנו יודעים שהמשתמש הוא מי שהם אומרים כי הוא יכול לשחזר את כתם הענק הזה שוב ושוב. המלח מבטיח שגם לשתי סיסמאות זהות אין אותו חשיש במסד הנתונים. הצפנה נוספת אינה מציעה עזרה גם בחזית זו.