שְׁאֵלָה:
האם מחוללי הסיסמאות SS64.com הם גישה טובה?
Benoit
2013-10-24 12:59:57 UTC
view on stackexchange narkive permalink

ישנם שני מחוללי סיסמאות ב- ss64.com :

איך הם עובדים

הכנתי גרסאות עצמאיות שלהן, בתוספת עותק של גרסאות ה- HTML / Javascript המקוריות, אם אתה רוצה ללמוד אותם, אך כך הם פועלים:

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

  • יש לך סיסמת מאסטר, נניח foo
  • אתה מייצר סיסמה לאתר או שירות ספציפי, נניח stackexchange

  • אתה מחשב את סכום SHA1 (גרסה רגילה) או סכום SHA256 (גרסה חזקה) של המחרוזת foo:stackexchange.

      $ echo -n "foo: stackexchange" | sha1sum # גרסה סטנדרטית b99341502484edbc43ec35a5f94be8e5de7ca53a * - $ echo -n "foo: stackexchange" | sha256sum #strong versionc6ac66fdb639821bcc322f186fb1214d241f35ba2a91cb660daf0a284ac19a47 * -

  • אתה מחיל Base64- טרנספורמציה על רצף הבייטים שהייצוג ההקסדצימלי הוא מראש> $ printf "\ xb9 \ x93 \ x41 \ x50 \ x24 \ x84 \ xed \ xbc \ x43 \ xec \ x35 \ xa5 \ xf9 \ x4b \ xe8 \ xe5 \ xde \ x7c \ xa5 \ x3a" | base64uZNBUCSE7bxD7DWl + Uvo5d58pTo = $ printf "\ xc6 \ xac \ x66 \ xfd \ xb6 \ x39 \ x82 \ x1b \ xcc \ x32 \ x2f \ x18 \ x6f \ xb1 \ x21 \ x4d \ x24 \ x1f \ x \ x91 \ xcb \ x66 \ x0d \ xaf \ x0a \ x28 \ x4a \ xc1 \ x9a \ x47 "| base64xqxm / bY5ghvMMi8Yb7EhTSQfNboqkctmDa8KKErBmkc =

  • (גרסה חזקה) אתה מחליף + ב- E ו / עם a, ולוקח 20 תווים ראשונים

  • (גרסה רגילה) אתה לוקח 8 תווים ראשונים ואז מוסיף 1a בסוף הסיסמה כדי להבטיח שיש לפחות ספרה אחת ואות אחת

לכן, עם סיסמת אב foo , ובשביל אתר ספציפי stackexchange , הסיסמה הרגילה שנוצרה היא uZNBACSE1a והסיסמה שנוצרה חזקה היא xqxmabY5ghvMMi8Yb7Eh .

עכשיו השאלות

  • האם הגרסה החזקה באמת חזקה יותר מהגרסה הסטנדרטית? האם זה עדיין יהיה חזק יותר אם הגרסה הסטנדרטית תשתמש גם ב- SHA256?
  • בתנאי שאבחר במפתח ראשי טוב (לא foo, במקום יותר מ -10 תווים אקראיים), האם אני די בטוח עם הסיסמאות שנוצרו? / li>
  • מה יכולות להיות חסרונות אחרים בגישה זו ביחס ליצירת סיסמאות?
1) הזנת הסיסמה באתר לא מהימן היא מסוכנת 2) פונקציית החשיש שלהם מהירה ככל הנראה. עדיף להשתמש בתכנית איטרציה 3) הוספת '1a' היא טיפשית. 4) שימוש בשם המשתמש כמלח יהיה רעיון טוב גם למניעת התקפות מולטי-מטרה.
@CodesInChaos: לענות על זה: 1) בגלל זה ניסיתי להבין מה קוד js עושה - 2) האם תוכל להרחיב על כך בתשובה? 3) כן, כך החלפת + / ב- Ea, אך זה ניתן על ידי הסקריפט על מנת ליצור סיסמאות התואמות את מדיניות הסיסמאות ברוב אתרי האינטרנט. כאשר יש לך 8 תווים אקראיים בין מערכת base64, יש סיכוי שאין ספרה אחת למשל. אך צירוף תווים אינו גורם לסיסמאות להיות פחות מאובטחות. 4) האם תוכל להרחיב על כך בתשובה? תודה.
סיסמאות אלה ייכשלו באותם אתרים שדורשים לפחות סמל אחד. Base64 ייצג רק את a-z, A-Z ומספרים, מכיוון שה- + ו / יוחלפו ב- E ו- a.
שתיים תשובות:
Thomas Pornin
2013-10-24 23:21:01 UTC
view on stackexchange narkive permalink

יש כאן שתי רמות חוזק:

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

הגרסה "הסטנדרטית" מייצרת סיסמאות עם 48 ביטים של אנטרופיה: קידוד Base64 הוא 6 סיביות לכל תו, והגנרטור משתמש בשמונה תווים (הסיומת "1a" קבועה, כך שהיא אינה משנה את האבטחה כלל). 48 פיסות אנטרופיה אינן רעות, במיוחד בהקשר של התקפות מקוונות, שם על התוקף לדבר עם השרת בכל ניסיון. אם השרת נפרץ (dump של מסד נתונים באמצעות הזרקת SQL) ו השרת לא השתמש ב hashing סיסמא תקין, התוקף החרוץ והמוטיבציה עלול לפרוץ דרכו; מהבחינה הזו הגרסה "החזקה" קצת יותר חזקה מהגרסה הסטנדרטית. עם זאת, במקרה הספציפי הזה, הייתי אומר שהחולשה היא בשרת, ולא בסיסמה (אי שימוש בחשיפת סיסמא נכונה זו הנקודה הרעה כאן).

שים לב שהמעבר מ- SHA-1 ל SHA-256 אינו משפר את האבטחה. זה לא רע , אבל הוא מציע רווח מעשי רק במידה ו- SHA-1 אינו מספק עמידות טובה לפני תמונה, וכרגע, SHA-1 עדיין טוב כמו חדש מבחינה זו. / p>

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

גישה גם סובלת מכמה בעיות שימושיות:

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

  • אם שם האתר משתנה, יצירת הסיסמה נשברת.

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

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

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

+1 להצעה להשתמש ב- keepass במקום בתכנית זו.
היכן אתה רואה אנטרופיה בתכנית זו? לקריאה שלי, האנטרופיה היחידה מגיעה מסיסמת האב והסיסמאות הספציפיות לאתר. השאר הוא פשוט טרנספורמציה שלא נראה שהיא מוסיפה שום ערך ממשי למעט סתום.
בהנחה שהסיסמה הראשית היא בעלת אנטרופיה מספיק גבוהה בכדי להביס את הכוח הגס, וכי פונקציית החשיש (SHA-1 או SHA-256) משמשת כאורקל אקראי, אז הסיסמאות הספציפיות לאתר הן "כאילו" הן נוצרו באופן אקראי , מנקודת מבטו של התוקף. אם כן, מדברים על ה"אנטרופיה "האינדיבידואלית שלהם מוצדקת מדעית (הבחנה ביניהם וסיסמאות אקראיות כרוכה בשבירת פונקציית החשיש או בשחזור סיסמת האב).
אני חושב שזו הנחה די גדולה שהשארת ללא אמירה, שם. זה ידרוש זמן רב יותר מסיסמא אלפאנומרית שנוצרה באופן אקראי, וזה לדעתי הרבה מעל הממוצע. הייתי מציע לקבוע בצורה ברורה יותר כי הגישה יוצרת סיסמאות עם * מקסימום * 48 ביט אנטרופיה.
תודה על תשובה זו. כמה מעקב: 1 / אני מבין שגישה זו אינה גמישה. אני מניח שאוכל להכניס מלח בשם האתר על ידי קידומת עם 'שם משתמש @' וסיומת עם ': 2013Q1' למשל אם הסיסמאות יפוגו כל 90 יום. האם זה יפתור את הבעיות שאתה מתאר? 2 / הבעיה שלי עם פתרונות דמויי keepass היא שאני עלול לאבד את החבילה (שום אחסון אינו בטוח באמת) או לשכוח לקחת אותו איתי. האם תוכל להציע מערכת חלופית שאינה מצריכה נשיאת קובץ? 3 / בדרישות מיוחדות לאתר ספציפי, אתה צודק ב 100%.
SS64
2013-10-26 20:14:59 UTC
view on stackexchange narkive permalink

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

אשכול GPU שמסוגל ל -350 מיליארד ניחושים / שנייה
350000000000 * 60 * 60 = 1.26e + 15 ניחושים / שעה
או 1.10376e + 19 ניחושים לשנה

סיסמה אקראית של 8 תו עם 48 ביטים של אנטרופיה
2 ^ 48 = 2.8147498e + 14 שילובים אפשריים
אז הזמן לפצח סיסמא בת 8 תווים:
2.8147498e + 14 / 1.26e + 15 = 0.223 שעות

A 10 סיסמא אקראית עם 59 ביטים של אנטרופיה
2 ^ 59 = 5.7646075e + 17 שילובים אפשריים
זמן לפצח סיסמא של 10 תווים:
5.7646075e + 17 / 1.26e + 15 = 457.50 שעות

סיסמה אקראית ל 15 תווים עם 89 סיביות אנטרופיה
2 ^ 89 = 6.1897002e + 26 צירופים אפשריים
זמן לפיצוח סיסמא בת 15 תווים:
6.1897002e + 26 / 1.10376e + 19 = 56078315.93 שנים

תו 20 תו אקראי ord עם 119 ביטים של אנטרופיה
2 ^ 119 = 6.64614e + 35 שילובים אפשריים
זמן לפיצוח סיסמא של 20 תווים:
6.64614e + 35 / 1.10376e + 19 = 6.0213633e + 16 שנים

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

ערוך: רק להוסיף, אלה הם זמנים מקסימליים, הממוצע יהיה מחצית מהערכים.



ⓘ
שאלה ותשובה זו תורגמה אוטומטית מהשפה האנגלית.התוכן המקורי זמין ב- stackexchange, ואנו מודים לו על רישיון cc by-sa 3.0 עליו הוא מופץ.
Loading...