זה ממש מסוכן.

השימוש באחסון המקומי לאחסון מזהי הפעלות אינו מומלץ לעולם מכיוון ש הנתונים נגישים תמיד על ידי JavaScript.

אנא השתמש בעוגיות כדי למתן סיכון זה באמצעות הדגל httpOnly .

התקפה יחידה של XSS (Cross Site Scripting) תוכל לגנוב את כל הנתונים באובייקטים אלה ו / או לטעון מידע זדוני, לכן אל תחשיב את "האחסון המקומי" למהימן ופחות עבור מזהה הפעלה / סיסמה מגובשת.

Ref: https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#Local_Storage

יש כמה בעיות בנושא זה.

ראשית, הערך המלוח SHA-256 הוא שווה ערך לסיסמה; כל תוקף שמקבל גישה לערך זה יכול פשוט להעביר אותו ישירות לשרת כדי לאמת. אין צורך להכריח את החשיש.

שנית, שימוש באחסון מקומי במקום קובץ cookie המסומן בסימן httpOnly פירושו שערך שווה ערך לסיסמה הוא עלול להיות פגיע לגניבה על ידי התקפות XSS. לכל סקריפט שמופעל באתר שלך יש גישה מלאה לנתונים אלה.

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

מסוכן. לא מומלץ.

כמה סיבות לכך;

1. התקפות MITM. במקרה של התקפה של ערוץ צדדי, ניתן לאלל שדרוג לאחור של צופן, ריפוד או חולשות באלגוריתם ההצפנה ששולח סיסמת גיבוב מעבר לקו.

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

3. DOM המחייב מחדש התקפות & XSS. חולשות בקוד הלקוח יכולות לסייע לתוקפים בגניבת אישורים המאוחסנים בדפדפן.

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

כמה דרכים להגן על הלקוחות שלך;

1. אל תאחסן מידע רגיש ב מזמין הלקוחות.

2. עטוף את מסירת הקודים שלך בחיבור TLS עם צפנים חזקים ושום דבר יותר מגרסה 1.2. זה דורש מפתחות חזקים, ECC / RSA גדול מ -2048 סיביות, לא פחות מאלגוריתם SHA512 עבור אישורי x509.

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

4. ודא שהיישום שלך לא מדליף נתונים רגישים, או אם אתה משתמש במזהה כדי להבטיח ששום דבר רגיש לא יעזוב את השרת.

5. עדכן את השרת שלך טלאי ויישומים מעודכנים כולל קושחה.

גישה זו בהחלט פחות מאובטחת מאחסון אסימון / עוגיית הפעלה רגילה ושליחת הסיסמה בטקסט רגיל.

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

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

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

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

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