איך מיישמים שמירת סיסמאות ב DB עם הצפנה המבוססת על אלגוריתם SHA256 ?

קראתי קצת על HASH, MD5, CRYPT ,SALT ,PADDING .

הבנתי שפונק' גיבוב עושות כיווץ בצורה יעילה לקלט בגודל משתנה ,
ותמיד מחזירות פלט באורך אחיד .
ושימוש בפונק' גיבוב עם אלגוריתם הצפנה כגון : MD5 , SHA1 ו SHA256
הופכות את הקלט לפלט מוצפן באורך אחיד .

לא הבנתי האם אני אמור להשתמש ב HASH או ב CRYPT לצורך המשימה .

http://roe25m.co.il

אלגורתמי ההצפנה חד כיוונית הנפוצים ביותר ב-PHP הם MD5 ו- SHA1, העדפה אישית שלי היא SHA1.

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

קוד PHP:

<?php
$hash = hash('sha256', '123456');
?>

מבחינת רמת ההצפנה ומבחינת מהירות ביצוע .
(הכוונה לשימוש באלגוריתם SHA256 עם HASH )

א) קבלת הסיסמא שהזין המשתמש כקלט .
ב) יצירת SALT באופן אקראי .
ג) שרשור של ה SALT לסיסמא .
ד) ביצוע HASH על התוצר של סעיף ג' ושמירתו ב DB ברשומה של המשתמש.
ה) במקביל לסעיף ד' לשמור בטבלה נפרדת את ה SALT ,עם POINTER ל ID של המשתמש .

בעת ביצוע הבדיקות :
א) קבלת שם המשתמש והסיסמא שהזין המשתמש כקלט .
ב) איתור ה SALT המתאים ב DB ע"פ שם המשתמש .
ג) שרשור של ה SALT לסיסמא שנתקבלה מהמשתמש .
ד) ביצוע HASH על התוצר של סעיף ג'
ה) השוואה בין ה סיסמא השמורה ב DB לאותו משתמש לבין הפלט שיצרנו בסעיף ד'

הערה : שם המשתמש במקרה זה יהיה UNIQUE כגון אימייל או משהו דומה ,
כך שלא יווצר מצב שניתן להשיג 2 SALT ים שונים לאותו שם משתמש .

ושאלה נוספת : האם עבודה עם 2 טבלאות מהווה יתרון או חיסרון ?

http://roe25m.co.il

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

על הסיסמא שהמשתמש הזין כקלט בלבד .
לרוב המשתמשים בוחרים סיסמא אסוציאטיבית שקלה לזיהוי .
השימוש ב SALT אמור להוסיף רמת אבטחה גבוהה יותר .

קבל לינק בנושא :
שימוש ב SALT

יש מצב שעשיתי קצת מישמש באלגוריתם שכתבתי פה אבל הכוונה הייתה טובה ..

http://roe25m.co.il

מה זה משנה אם הסיסמא שלו קלה או לא בהקשר של האלגוריתם?
תריץ MD5 / SHA מה שלא יהיה על הסיסמא ותכניס אותה למסד נתונים.

את פיצוח הסיסמא לאחר שעברה גיבוב ולא הרצה של brute force attack .

את brute force attack אני אנסה למנוע באמצעות הוספת CAPTCHA ,
לאחר 3 ניסיונות כניסה כושלים.

במקרה של שימוש ב MD5 / SHA :
אם סיסמא שהוצפנה ככה מגיעה לידי האקרים
אז יש להם מספיק כלים כדי למצוא את המקור שלה .

http://roe25m.co.il

עבודה עם 2 טבלאות במצב שאתה תיארת לא נותנת שום ייתרון.

אבל אני לא רואה צורך לשמור SALT ב- DB לכל משתמש

לבצע הפרדה בין ה SALT של המשתמש לבין ה PASS שעברה גיבוב .

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

http://roe25m.co.il

אתה שואל אותנו שאלה, עונים לך, ואז אתה אומר שזה לא נכון?

ההפרדה פיסית, של 2 טבלאות, היא מיותרת מבחינת תכנון DB.
אני גם חושב שזה הגזמה לשמור את ה- SALT ב- DB בגלל שאפשר גם בלי זה.
הנה דוגמא למשהו שראיתי ב- php.net

קוד PHP:

 function doubleSalt($toHash,$username){ 
$password = str_split($toHash,(strlen($toHash)/2)+1); 
var_dump($password); 
$hash = hash('md5', $username.$password[0].'centerSalt'.$password[1]); 
return $hash; 
} 


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

רק הצגתי את הגורמים שהביאו אותי להשתמש ב 2 טבלאות ושמירת SALT פר יוזר .

הרי יצא לי להרהר בנושא לפני שכתבתי את השאלה .
ברור לי ששימוש ב 2 טבלאות גורר חוסר יעילות מבחינת זמן ביצוע השאילתות .
היתרון שאני ראיתי היה בהפרדת ה SALT מה PASS המגובב .

השאלה פה בעצם הייתה האם היתרון מפצה על החיסרון .

ד"א שמתי לב שאתה מציין בתגובות שלך את האלגוריתמים של MD5 ו SHA1 בלבד.
יש סיבה לכך שאתה לא מציין גם את SHA256 ?

http://roe25m.co.il

כשאתה משתמש ב-2 טבלאות אין הבדל בין זה לבין בטבלה אחת לשמור בעמודה אחת את ה- hash ובעמודה שניה את ה- salt

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

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

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

erformance test results on my laptop:
Results are here shorten to fit php web notes ...
This was tested with 1024000 bytes (1000 KB) of random data, md4 always gets the first place, and md2 always get the last place

Results: (in microseconds)
1. md4 5307.912
2. md5 6890.058
3. crc32b 7298.946
4. crc32 7561.922
5. sha1 8886.098
6. tiger128,3 11054.992
7. haval192,3 11132.955
8. haval224,3 11160.135
9. tiger160,3 11162.996
10. haval160,3 11242.151
11. haval256,3 11327.981
12. tiger192,3 11630.058
13. haval128,3 11880.874
14. tiger192,4 14776.945
15. tiger128,4 14871.12
16. tiger160,4 14946.937
17. haval160,4 15661.954
18. haval192,4 15717.029
19. haval256,4 15759.944
20. adler32 15796.184
21. haval128,4 15887.022
22. haval224,4 16047.954
23. ripemd256 16245.126
24. haval160,5 17818.927
25. haval128,5 17887.115
26. haval224,5 18085.002
27. haval192,5 18135.07
28. haval256,5 18678.903
29. sha256 19020.08
30. ripemd128 20671.844
31. ripemd160 21853.923
32. ripemd320 22425.889
33. sha384 45102.119
34. sha512 45655.965
35. gost 57237.148
36. whirlpool 64682.96
37. snefru 80352.783
38. md2 705397.844

sha256 לוקח פי 2.14 יותר זמן מ- sha1, ופי 2.76 יותר זמן מ- md5.
עוד חיסרון שיכול להיות זה ש- sha256 לוקח יותר מקום ב- db.

יכול להיות גם שזה לא כזה נורא, אני לא יודע. תעשה את השיקולים שלך

עם HASH באלגוריתם SHA256 ועמודה נפרדת ל SALT .
לא רציתי לבנות טבלה במיוחד בשביל ה SALT .

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

מבחינת מיקום ב DB אני לא רואה בעייה בהתחשב במבנה שלו .

תודה

http://roe25m.co.il

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

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