שְׁאֵלָה:
האם זה בטוח לשלוח שמות משתמש / סיסמאות ברורים בחיבור https כדי לאמת משתמשים?
Emiliano
2014-08-04 18:56:32 UTC
view on stackexchange narkive permalink

אני מגדיר שרת HTTP ביתי שיוכל לשלוח ולקבל נתוני JSON אל / מלקוחות שונים (אפליקציות אנדרואיד ואייפון).

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

כמובן שאיני יכול לשלוח סיסמאות ברורות מהלקוח לשרת. ב- HTTP רגיל, אחרת כל מי שהתקין wireshark / tcpdump יכול לקרוא אותו. אז אני חושב על המנגנון הבא:

  1. ניתן להגדיר את שרת ה- HTTP כשרת HTTPS
  2. לשרת יש גם בסיס נתונים של שם משתמש / סיסמה (סיסמאות יכולות להיות נשמר באמצעות bcrypt)
  3. הלקוח פותח את חיבור HTTPS, הוא מאמת את השרת (כך שיש צורך באישור שרת) ולאחר החלפת מפתח הראשי, החיבור צריך להיות מוצפן.
  4. הלקוח שולח את שם המשתמש / הסיסמה בצורה ברורה לשרת
  5. השרת מריץ bcrypt על הסיסמה ומשווה אותה לזו המאוחסנת במסד הנתונים

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

רק כדי להוסיף לתשובות שקיבלת כבר, במערך מסוג זה אני ממליץ להסתכל על תעודת הצמדה המסייעת בהפגת התקפות MITM ...
אולי שקול לגבות את הסיסמה במקום (או בנוסף) להצפין אותה.
למרות שזה עשוי להיות בטוח אם אתה משתמש ב- https.בעיה אחת שקראתי בשאלות אחרות היא ששם המשתמש והסיסמה ייכתבו ביומני השרת אם הם מועברים ישירות בכתובות האתר.זה יכול להיות מסוכן אם אבטחת היומנים תיפגע.
שמונה תשובות:
AJ Henderson
2014-08-04 21:23:04 UTC
view on stackexchange narkive permalink

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

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

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

@AJHenderson +1, אם הלקוח ישלח את החשיש יהיה בהחלט רע, שכן המטרה של פרוטוקול האימות היא להבטיח שהמבקר יודע את * הסיסמה * הנכונה, ולא את הסיסמה הנכונה * hash *. אם צד זדוני יכול להשיג את החשיש (מאגר סיסמאות גנוב, איש באמצע, מה שלא יהיה) והמערכת הסתמכה על המבקר שישלח את החשיש במקום הסיסמה, כל מושג של אבטחה אמיתית יהיה מחוץ לחלון.
לפעמים יש יתרון לחשיש אצל הלקוח ואז לחשיש עוד קצת בשרת. זה יכול לעזור להבטיח שהסיסמה מעורפלת בכל יומני טקסט ברורים אצל הלקוח, השרת וברשת.
@Craig מתן אפשרות ללקוח לחשב את החשיש המלוח היקר הוא בסדר גמור, כל עוד אתה מחיל חשיש זול ולא מלוח על השרת לפני אחסונו (או סוג אחר של פונקציה חד כיוונית, כמו אקספוננציאל מודולרי).
@AndyBoura - אם אתה מתכנן את המערכת כך שתוכל לתמוך בחשיפה בצד הלקוח, יש לך שליטה על התנהגות הרשת והשרת עבור חלקים שתהיה להם גישה לטקסט הברור. נכון, אתה לא נפגע מכך שאתה מחייב אותו על הלקוח (מלבד זמן אבוד), כל עוד אתה לא משפיע משמעותית על כמות הגיבוב שאתה עושה בשרת.
@CodesInChaos - הייתי הולך רק שזה יהיה פחות פחות רע. אפילו באמצעות חשיש מורכב כדי לבצע קלט "ארוך יותר", זה רק סיומת מפתח ותוקף יוכל לייצר הרבה חשיפות זולות בקלות רבה. מעשית, אולי לא משנה אם תפוקת החשיש בצד הלקוח ארוכה ואין פגיעות בשני הגיבויים המגבילים את ההרחבה מערכים פשוטים. חשוב גם לציין שבמקרה כזה תצטרך להמליח את חשיפת צד הלקוח והן את צד השרת. אני עדיין קצת מפוקפק מהעלות לעומת התועלת.
@AJHenderson ישנם מספר יתרונות לחשיפה בצד הלקוח: 1) מגבלת זמן ארוכה יותר מכיוון שהלקוח אינו צריך לטפל בכניסות רבות בו זמנית. 2) נמנע מ- DoS מכיוון שהשרת אינו צריך לחשב חשיש יקר. 3) השרת אינו לומד את הסיסמה. | החיסרון העיקרי הוא שלקוחות לעיתים קרובות יש מעבד איטי יותר מאשר השרת. | אני לא מבין מדוע ה- hash בצד השרת צריך להשתמש במלח כאשר ה- hash בצד הלקוח כבר משתמש בכזה.
@CodesInChaos - מכיוון ששום דבר מהלקוח אינו מהימן. תוקף יכול לדלג על כל התהליך האיטי על ידי עקיפת הלקוח לחלוטין. עליכם לוודא שלא תוכלו לבנות שולחן קשת בערכי חשיש זולים ומהירים. זה לא אפשרי אם ממליחים כל אחד ובתנאי שהחשיש הבינוני מספיק ארוך. אחרת, אתה פשוט מכין טבלת קשת של ערכי חשיש שניתן ליצור בקצב מהיר מאוד, אם הם זולים.
@AJHenderson ברור שערך הביניים צריך להיות גדול מספיק כדי למנוע ספירה, לפחות 128 סיביות רצוי 160-256 בכדי להסביר התקפות יעד מרובות. מכיוון ששימוש בחשיש תקין כמו SHA-256 הוא כל כך קל, אני לא רואה סיבה להוסיף סיבוכים מיותרים כמו מלח.
@CodesInChaos - כן, אם אתה משתמש בחשיש ביניים גדול מספיק ובטוח שהוא מתנהג היטב (התפלגות אקראית באמת) אז זה צריך להיות בסדר כל עוד החשיש הראשוני מומלח ונמשך זמן רב בכדי לכפות שימוש בספירה מלאה של שטח חשיש ביניים (או לפחות ליד מלא).
בסיכון של אמירת המובן מאליו, ודא שאתה משדר באמצעות POST, ולא באמצעות GET :-) GETs יהיו ברורים.
כמו כן, בזמן שאנחנו מדברים על סוגיות כמו POST לעומת GET, הקפד ליישם סודיות קדימה כדי שלא ניתן יהיה לפענח את ההפעלות המאובטחות שלך מאוחר יותר על ידי מישהו שמשיג את המפתח הפרטי של השרת שלך.
סיסמא / שיחת חשיש [המשך בצ'ט] (http://chat.stackexchange.com/rooms/16227/discussion-between-aj-henderson-and-craig).
במיוחד עם יישום בצד הלקוח, כנראה שעדיין הייתי משתמש בגרסת סיסמה מסוימת על הסף, מכיוון שלדעתי זה אפשרי, שמשום מה ניתן ליצור חיבור לא מוצפן (על ידי שגיאת תכנות כלשהי, עדכון אפליקציה פגום , הגדרות שגויות של הספרייה הבסיסית, כך שמתקבלת הפניה מחדש לשרת http ...) * הכל במקרה של אותה סיסמה למספר חשבונות, יתר על כן אתה בטוח ממישהו שיש לו גישה לשרת שלך מלקבל סיסמאות בטקסט ברור ...
@Falco - ושגיאת תכנות עלולה לגרום גם לחשיש לא בטוח. עליכם לאמת התנהגות של קוד שקשור לאבטחה, ולא רק לקוות שהוא יעבוד נכון. ככל שמוסיפים למערכת מורכבות רבה יותר, קשה יותר לאמת אותה וסבירות להופיע שגיאה או פגיעות. עליכם לשפוט כמה תועלת אתם מקבלים עבור סכום מאמץ נוסף נתון. בסופו של דבר הסיכון הנוסף לטעות ביישום אינו שווה את הרווח המינימלי בהתנגדות נוספת.
@AJHenderson: אתה קובע "כן, זה הנוהג הרגיל." האם יש לך הפניה להצהיר את ההצהרה הזו? אני מחפש שיטות עבודה מומלצות ממקור סמכותי ידוע, כמו אולי NIST או אפילו ספר של אוריילי.
האם "נוהג סטנדרטי" זה מבטיח גם אבטחה מלאה אם ​​יש לנו 'נכשל נכשל' או 'פריק HTTPS' כחלק מהתקשורת שלנו? ואם שתי גרסאות SSL נשברות, האם אנו בטוחים שהגרסה האחרונה בטוחה?
@h22 אני מניח שאנחנו לא יכולים להיות בטוחים במאת האחוזים, אבל אם לא, סיסמאות הן החששות שלנו. כמו כן, אנו בטוחים הרבה יותר לגבי TLS מאשר לגבי הגדרת גיבוב או הצפנה של צד הלקוח הביתי. אם נגיד שנופל תחת הנוהג "אל תגלגל בעצמך".
"הצפנה ביתית" אמנם לא נשמע טוב אבל יש גם ספריות קריפטוגרפיה סטנדרטיות.
@h22 ההצפנה הביתית אינה חלה רק על אלגוריתמים או ספריות, אלא גם על פרוטוקולים. ישנן הרבה דרכים בהחלפת סיסמאות יכולה להתקלקל. לדוגמא, אם ביצעת הצפנה בצד הלקוח ללא אתגר שונה שנשלח ללקוח בכל פעם, ההצפנה לא תעשה דבר משום שהיא מסתירה רק את האמצעים ליצירת סיסמה שתוגן רק על ידי SSL. ערך שנוצר על ידי הלקוח יהיה זהה כל הזמן, מה שהופך אותו לסיסמה "האמיתית") ישנם כל מיני מלכודות פוטנציאליות, ברורות ולא ברורות.
העובדה נותרה כי יש הרבה יותר בדיקות וניתוח של פרוטוקולים כמו ssl מכל מה שאתה מרכיב כסוויטה משלך. אם הדברים שלך מרובדים על גבי דברים אחרים זה עלול לייצר התקפות ערוץ צדדיות. העובדה שלקח כל כך הרבה זמן עד שהתגלו נושאים ב- ssl צריכה להיות בונה אמון. זה אומר שגם עם המון עיניים קשה למצוא פגיעות. בנוסף, פירוש הדבר כי נושאים נמצאים ומוכרזים על ידי חוקרים הבוחנים דברים מסוג זה.
האם זו עדיין תשובה טובה?הייתי מצפה שלא;במקומות מסוימים מתקינים אישורים נוספים ועושים התקפות MitM של HTTPS, למשל.ראיתי דיון אחר במקומות אחרים על מה צריך להיות תוכנית טובה יותר, אבל לא מספיק בשביל לשפוט אם זה היה על ידי אנשים שהבינו באמת ביטחון.
@DanielH אם למישהו יש גישה להתקנת אישורי שורש, יש לו גישה ליומן המפתחות.אם אינך סומך על מחשב, אל תזין את הסיסמה שלך, נקודה.הגנה מפני לקוחות שנפגעו דורשת מנגנון שונה לחלוטין כגון כרטיסים חכמים שיכולים לאמת מבלי לחשוף את הסוד, אך דורש חומרה נוספת עבור הלקוח ואינו מעשי עבור מרבית היישומים.
@AJHenderson יש דרכים לגרום ללקוח לקבל אישור שנפגע שלא מאפשר לך להתקין מפתח מפתח, אבל בכל מקרה אני מסיר את החלק הזה בהתנגדות שלי כי הם גם יאפשרו לך לשנות את מסך הכניסה ומעטים אם לקוחות כלשהם יבדקושבכל פעם לשינויים.זה יגן רק מפני פשרות שרתים חלקיות אך לא מוחלטות (שאולי מתקבלות על הדעת בהתאם לאדריכלות ולנהלי האבטחה הארגוניים) או התקפות שאפשרו הפסקה פסיבית אך לא הפרעה פעילה ב- HTTPS (כנראה יכולה להתקיים, אך נדירה מאוד).
@AJHenderson למרות שרוב מה ששכנע אותי הוא שכמה חברות שאני סומך עליהן שיש להן אבטחה טובה מהממוצע, כולן נראות כאילו הן שולחות את הסיסמה שהוזנה באופן שאינו מוצפן מעבר ל- HTTPS.אני מופתע;הייתי מצפה ששיטה שלא תעשה זאת תהפוך לסטנדרט לשיפור אולי הקטן שהיא כן מציעה, במיוחד בהתחשב בכך שנלחם נגד שימוש חוזר בסיסמה הוא מאבק מאבד.
@DanielH כיצד תתקין אישור שורש מהימן מבלי שתהיה לך גישה של מנהל התיבה לזמן קצר לפחות?אם יש לך רמת גישה כזו, אתה יכול להיות רעוע בכל מספר דרכים אחרות גם אם אתה רוצה להיות.וכפי שציינת בצדק, רק היכולת של MitM פירושה שכל מנגנון בצד הלקוח יכול להיות מנוצח אלא אם כן הוא נבנה באפליקציה ולא באתר.
@AJHenderson אתה יכול להתפשר על אישור, מבלי לשים לב אליך או לבצע את ההתקפה לפני שהיא מבוטלת.אתה יכול למקד ללקוחות שעדיין יש להם תעודת [Superfish] (https://en.wikipedia.org/wiki/Superfish), או שווה ערך מאחת ממספר השירותים האחרים שעושים משהו דומה.אתה יכול למכור תיבת אמצע או סינון תוכן לסינון תוכן שיש להם סיבה חוקית ל- MitMing, ואז לא תצליח לשמור על האישור או להשתמש בו למטרות מזויפות.אתה יכול להערים על רשות אישורים להנפיק לך אישור לאתר שאתה שולט בו באופן חלקי בלבד.וכו.
@DanielH בסדר, זה הקשר שונה לחלוטין מהתגובה הראשונית שלך שמדברת על מקומות שמתקינים סרטי יישום ל- MitM.המקרים שתיארת זה עתה הם הרבה פחות שכיחים, ולרובם קיימת הפחתה כעת או שהם מקרים נדירים מאוד או חלים רק על מערכות שפגיעות אחרת להתקפה נגד הלקוח עצמו.
תן לנו [להמשיך את הדיון הזה בצ'ט] (https://chat.stackexchange.com/rooms/90709/discussion-between-daniel-h-and-aj-henderson).
Neil McGuigan
2014-08-04 22:26:15 UTC
view on stackexchange narkive permalink

לא בהכרח.

עליך גם לוודא את הדברים הבאים:

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

  2. האתר שלך מוגן מפני התקפות קיבוע של הפעלות. שנה את מזהה ההפעלה בעת ההתחברות.

  3. אם אתה משתמש בעוגיות הפעלה, שכל האתר שלך הוא HTTPS, ולא רק כתובת ה- URL להתחברות, וכי קובץ ה- cookie של הפגישה שלך מסומן כמאובטח ו- http בלבד. (אין גישה ל- JavaScript). הדפדפן ישלח קובץ cookie ללא הצפנה אם המשתמש מקליד http: // yourecuresite (באותה הפעלת דפדפן).

  4. אתה משתמש בפרוטוקול עדכני. SSL 1 ו- 2 שבורים, וייתכן שגם 3. נסה להשתמש ב- TLS 1.1 או 1.2.

  5. אתה משתמש בצופן חזק.

  6. אינך משתמש בדחיסת HTTP (GZip) או בדחיסת TLS. אם האתר שלך מציג קלט משתמש (כמו קלט חיפוש), אני יכול להבין את אסימוני ה- CSRF ואת מספר חשבון הבנק שלך אם אתה משתמש בדחיסה.

  7. השרת שלך לא אפשר משא ומתן מחודש על לקוח לא מאובטח.

  8. אתה משתמש במפתח RSA של 2048 סיביות (או שווה ערך למפתח EC), ושאף אחד אחר לא מכיר את המפתח הפרטי שלך.

  9. אתה משתמש ב- HSTS כך שהדפדפן עובר ישירות ל- https גם אם המשתמש מקליד http

  10. אתה משתמש בסודיות קדימה מושלמת אז התקשורת ההיסטורית שלך מאובטחת גם אם המפתח הפרטי שלך דולף

אם האתר כולו https, האם אני עדיין זקוק לעוגיה המסומנת כמאובטחת? הם עדיין היו מוצפנים "בחינם" בגלל שכבת TLS, נכון?
אתה יכול להסביר את נקודה 6? מדוע דחיסה תגרום לחיבור להיות פחות מאובטח?
אתה עדיין רוצה עוגיה מאובטחת, http בלבד, שכן היא עדיין ניתנת לגניבה אם לא. ראה xss. דחיסה הורגת הצפנה. ראה התקפות BEAST ו- CRIME.
@Emiliano: אפילו האתר שלך הוא HTTPS בלבד, תוקף יכול להגדיר אדם בהתקפה האמצעית ולהקים שרת מזויף המשתמש ב- HTTP רגיל, ומבצע מה שמכונה הפשטת SSL. הדפדפן ישלח לשרת המזויף את קובץ ה- cookie של המשתמש. כדי למתן זאת, אתה זקוק למדיניות Cookie מאובטחת ומדיניות HSTS.
9. העסיקו PFS כדי להפחית את הסיכון שמישהו (למשל ממשלה רעה כלשהי) יגנוב את המפתחות הפרטיים שלכם.
8. זה כל העניין של HTTPS ... 1. לא רלוונטי ללקוח סלולרי, אין זה סביר שיש עוגיות והפעלות. 6. מה רע בלחיצות? - בדרך כלל שרת המשרת שירותי json ידרוש לאמת את כל הבקשות.
@njzk 1. ניתן עדיין לגלוש בכתובות אתרים בדפדפן, ולכן זה רלוונטי. 3. תלוי ביישום שלו, שווה להזכיר בכל מקרה. 6. ראה התקפות BEAST ו- CRIME.
@NeilMcGuigan: האם ניתן לנחש את אורך הסיסמה אם היא נשלחת ברורה באמצעות HTTPS?
@user2284570 "בבהירות" ומעלה "HTTPS" הם הפכים.
@NeilMcGuigan: רציתי להתכוון בכך שאינני משדר אותם באמצעות חשיש או הצפנה נוספת.
mricon
2014-08-04 19:07:11 UTC
view on stackexchange narkive permalink

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

kasperd
2014-08-04 19:15:11 UTC
view on stackexchange narkive permalink

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

הייתי ממליץ נגד גישה פחות בטוחה מזו שאתה מזכיר. (בין אם ה- bcrypt טוב יותר או גרוע יותר מאשר חשיש מלוח אחר הוא דיון שלא אכנס אליו. פשוט אל תשתמש בשום דבר חלש יותר מאשר חשיש מלוח.)

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

אזורים הנוגעים לאימות סיסמאות שעשויים להיות מאובטחים יותר כוללים:

  • הגנה על השרת מפני DoS. התקפות על ידי הורדת מרבית החישוב במהלך האימות ללקוח. כְּלוֹמַר. אל תבצע איטרציה של גיבוב בצד השרת, רק בצע איטרציה בצד הלקוח ובצע את השלב האחרון של גיבוב בשרת.
  • הגנה מפני דליפות סיסמאות אם השרת נפגע על ידי הפקת זוג מפתחות ציבורי מהסיסמה ולעולם לא תן לשרת לראות סיסמה או מפתח סודי.
Andy Boura
2014-08-05 12:46:40 UTC
view on stackexchange narkive permalink

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

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

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

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

קצת אני לא רוצה שכולם יצטרפו: אני רוצה לתת אישור רק למשתמשים מסוימים (למשל החברים שלי).
כן, אתה זקוק לרשימת הודעות דוא"ל המותרות עדיין. לאחר מכן תבדוק זאת מול מזהה המאוחד.
אה, אז אוכל ליישם רשימה לבנה, אתה מתכוון? זה מעניין, אני אבדוק גם גישה זו.
זה נכון. אתה יכול אפילו להשתמש ברשימת החברים שלך בפייסבוק או בקבוצה עבור Auth, אבל אני לא מכיר פרטים על איך היית עושה את זה.
נוסף מידע על הרשאות לתשובה.
200_success
2014-08-05 21:33:55 UTC
view on stackexchange narkive permalink

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

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

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

  • אל תגיש את הסיסמה במחרוזת השאילתה של HTTP GET. שרתים מוגדרים בדרך כלל לרשום כתובות אתרים של בקשות, שיכללו את החלק של מחרוזת השאילתה של כתובת האתר. במקום זאת, הכניס את הסיסמה לגוף POST. (אתה יכול גם להשתמש ב- RFC 2617 אימות HTTP, אך תמיכת התנתקות היא נקודתית.)

אה כן, אני תמיד זוכר ש- GET הוא רעיון רע כי הוא גלוי במערכת הלקוח ועלול להסתיים בהיסטוריית הלקוחות, אך תשכח שגם שרתים עשויים לרשום את הפרמטרים.
h22
2015-10-27 17:39:55 UTC
view on stackexchange narkive permalink

ויקיפדיה הכוללת את העמוד המלא של בעיות אבטחה היסטוריות ב- HTTPS.

באגי אבטחה של HTTPS קרו בעבר (מדוע שתי הגרסאות הישנות נשברות? ומה זה 'הולך להיכשל מה זה 'https freak'?).

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

D.H.
2015-10-28 18:16:09 UTC
view on stackexchange narkive permalink

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



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