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

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

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

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

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

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

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

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

רע סיסמאות Practices

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

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

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

דאגות אחרות

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

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

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

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

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

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

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

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

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

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

תמונה אשראי: מארק Falardeau על Flickr, ויקיפדיה