למה אתה צריך לדאוג כאשר מסד הנתונים הסיסמה של שירות הוא הודלף

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

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

כיצד יש לאחסן סיסמאות

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

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

כדי למנוע זאת, השירותים צריכים "מלח" שלהם hashes. במקום ליצור חשיש מהסיסמה עצמה, הם מוסיפים מחרוזת אקראית לחזית או לקצה של הסיסמה לפני hashing אותו. במילים אחרות, משתמש היה מזין את הסיסמה "password" והשרות היה מוסיף את המלח ואת הסיסמה hash שנראה יותר כמו "password35s2dg". כל חשבון משתמש צריך מלח ייחודי משלהם, וזה יבטיח כי כל חשבון משתמש היה ערך hash שונה עבור הסיסמה שלהם במסד הנתונים. גם אם חשבונות מרובים השתמשו בסיסמה "password1", הם היו hashes שונים בגלל ערכי מלח שונים. זה היה להביס את התוקף שניסה מראש לחשב hashes עבור סיסמאות. במקום להיות מסוגל לייצר hashes כי להחיל על כל חשבון משתמש במסד הנתונים כולו בבת אחת, הם יצטרכו לייצר hashes ייחודי עבור כל חשבון המשתמש ואת מלח ייחודי. זה ייקח הרבה יותר זמן חישוב וזיכרון.

זו הסיבה שירותים לעתים קרובות אומרים לא לדאוג. שירות באמצעות נהלי אבטחה נאותים צריך לומר שהם השתמשו hashes הסיסמה hasched. אם הם פשוט אומרים את הסיסמאות "hashed," זה יותר מדאיג. LinkedIn יש להשיב את הסיסמאות שלהם, למשל, אבל הם לא מלח אותם, אז זה היה עניין גדול כאשר LinkedIn הפסידה 6.5 מיליון סיסמאות hashed בשנת 2012.

סיסמאות רע

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

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

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

דאגות אחרות

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

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

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

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

עזרה, מה עלי לעשות?

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

ראשית, אל תעשה שימוש חוזר בסיסמאות באתרים מרובים. השתמש במנהל סיסמאות שיוצר סיסמאות ייחודיות עבור כל אתר. אם תוקף מצליח לגלות שהסיסמה שלך לשירות היא "43 ^ tSd% 7uho2 # 3" ואתה משתמש רק בסיסמה באותו אתר ספציפי אחד, הם לא למדו דבר מועיל. אם אתה משתמש באותה סיסמה בכל מקום, הם יכולים לגשת לחשבונות האחרים שלך. זה כמה חשבונות של אנשים רבים להיות "פרוצים".

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

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

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

קרדיט תמונה: מארק פאלרדו על פליקר, ויקיפדיה