פתרון אפשרי למניעת בקשות שגויות דרך שלוחת API
-
@פיסטוק-פרווה לא נכון!!
-
-
@פיסטוק-פרווה אתה מתווכח עם מציאות מתמטית, זה שניתן לבצע התקפה של ניסוי ותהיה עד למציאת המחרוזת התואמת לא אומרת שניתן להמיר את זה חזרה, אלא שבהינתן ערך האש זהה שאתה יודע מה הסטרינג המקורי שלו, תוכל לזהות את הסיסמה המגובבת בהאש, אבל עדיין לא תוכל לעשות לזה המרה חוזרת...
כמובן שכל האמור הוא לגבי הצפנה קריפטוגרפית, ולא על הצפנה מול מפתח
-
@פיסטוק-פרווה כתב בפתרון אפשרי למניעת בקשות שגויות דרך שלוחת API:
אני פשוט אחזור שוב
@MGM-IVR כתב בפתרון אפשרי למניעת בקשות שגויות דרך שלוחת API:
האש זה גיבוב.. אפשר לגבב בדרך שיוכלו להחזיר, אבל לא משתמשים בזה כבר היום להצפנה
הצורות של ההצפנה היום זה פונקציה חד כיוונית, שלא ניתן להחזיר אחורה, פעם היו מצפינים מול צופן כלשהוא, והיה ניתן להחזיר אחורה
-
@MGM-IVR
@אביי-ורבא
אוקיי, אז תסבירו לי,
בא נניח שאני רוצה ליצור סיסמה באש של 123456, ואז אני רוצה לבדוק אם מה שהלקוח שולח לי זה נכון, בא נגיד שהוא באמת שלח את 123456 אז אני יוצר שוב סיסמת אש ומתאם, 1. זה אומר שכל הסיסמאות אש זה תמיד יהיה אותו סיסמה,
2. זה אומר שאם אתה מפצח את הקוד איך להמיר מ 123456 ל e10adc3949ba59abbe56e057f20f883e אז אתה גם יכול להחזיר. -
@אביי-ורבא כתב בפתרון אפשרי למניעת בקשות שגויות דרך שלוחת API:
@פיסטוק-פרווה זה שניתן לבצע התקפה של ניסוי ותהיה עד למציאת המחרוזת התואמת לא אומרת שניתן להמיר
כן על זה דיברתי
-
@פיסטוק-פרווה כתב בפתרון אפשרי למניעת בקשות שגויות דרך שלוחת API:
@MGM-IVR
@אביי-ורבא
אוקיי, אז תסבירו לי,
בא נניח שאני רוצה ליצור סיסמה באש של 123456, ואז אני רוצה לבדוק אם מה שהלקוח שולח לי זה נכון, בא נגיד שהוא באמת שלח את 123456 אז אני יוצר שוב סיסמת אש ומתאם, 1. זה אומר שכל הסיסמאות אש זה תמיד יהיה אותו סיסמה,
2. זה אומר שאם אתה מפצח את הקוד איך להמיר מ 123456 ל e10adc3949ba59abbe56e057f20f883e אז אתה גם יכול להחזיר.לא זה הפורום והמקום,
אבל בקצרה,
פונקציית גיבוב רגילה לוקחת מחרוזת שאתה מספק לה, למשל 123456, ועושה מניפולציה כלשהיא(למשל החלפה של 1 ו 0 בכל ביט 5 ) ומחזירה ערך מגובב שללא המפתח (החלפה של 1 ו 0 בכל ביט 5) לא תוכל לדעת מה המקור.פונקציית גיבוב קריפטוגרפית היא פונקציה שאתה נותן מחרוזת למשל 123456, ומגדיר לאיזה אורך היא תוצפן (למשל 256), ויש פונקציה מתמטית מסובכת, שמביאה לך את ההאש המוצפן,
בזה משתמשים היום רב ההצפנות, ובזה אין דרך לחזור אחורה ולדעת לפי האש, מה המחרוזת המקורית (1-6)ככה אני כותב מהזיכרון, אז הגיוני שיהיה טעיות, ניתן לחפש בגוגל כדי להבין יותר טוב
-
@MGM-IVR
אז אש זה פונקצייה אחת שבא נגיד (כמובן, דוגמא) לוקחת את התו הראשון (1) מכפילה אותו ב 10 ואז יוצא 10 את השני ב 20 וכן הלאה.. אז אמור לצאת 104090160250360. ובשביל לבדוק אם הסיסמה שהלקוח שולח נכונה, אני אמור להכפיל את התו הראשון ב 10 והשני ב 20 וכו' ולראות אם התוצאה זה ה hash ששמרתי ממה שיצא לי מקודם? -
@פיסטוק-פרווה כתב בפתרון אפשרי למניעת בקשות שגויות דרך שלוחת API:
@MGM-IVR
אז אש זה פונקצייה אחת שבא נגיד (כמובן, דוגמא) לוקחת את התו הראשון (1) מכפילה אותו ב 10 ואז יוצא 10 את השני ב 20 וכן הלאה.. אז אמור לצאת 104090160250360. ובשביל לבדוק אם הסיסמה שהלקוח שולח נכונה, אני אמור להכפיל את התו הראשון ב 10 והשני ב 20 וכו' ולראות אם התוצאה זה ה hash ששמרתי ממה שיצא לי מקודם?ברגע שיש לך פונקציה שמחזירה משהו מוצפן (ואני לא נכנס לאיך הפונקציה עובדת)
אז אתה שומר ב db את המשהו המוצפן כסיסמה של הלקוח, ואז כשהוא מכניס סיסמה לאימות, אתה מעביר את הקלט שלו בתוך הפונקציה, ומשווה את התוצאה למה שכתוב בdb -
@MGM-IVR
כן, כמו שכתבתי, אוקיי תודה!! -
@פיסטוק-פרווה בקצרה, ההצפנה מתבצעת כך: כאשר מתקבל הקלט שאמור להיות הסיסמה, מוספים לו ערך רנדומלי כלשהו ואז מעבירים אותו פונקציית Hash. בDB שומרים את הערך המגובב שבעצם מורכב מהסיסמה של המשתמש + הערך הרנדומלי שהתווסף.
כנ"ל לאחר מכן כדי לאמת את הסיסמה כשמתקבל קלט סיסמה של משתמש מסוים, מוסיפים את הערך הרנדומלי ומעבירים אותה דרך אלגוריתם הHash ומבצעים השוואה של הגיבוב שהתקבל לסיסמה הקיימת במסד נתונים. -
@yosef-avitan
מאיפה תדע איזה ערך רנדומאלי היה קודם? -
@פיסטוק-פרווה כתב בפתרון אפשרי למניעת בקשות שגויות דרך שלוחת API:
@yosef-avitan
מאיפה תדע איזה ערך רנדומאלי היה קודם?את הערך הרנדומלי אני שומר בDB על שם המשתמש.
-
@MGM-IVR @yosef-avitan @אביי-ורבא @לומד-עס @פיסטוק-פרווה @שואף_גבוה
אז אני מציע רעיון אחר, בכניסה לשלוחה המערכת תבקש מהמשתמש את סיסמת הניהול, תבדוק האם הסיסמה נכונה (כמו פונקציית password=password_admin) ובמידה והיא נכונה, יישלח לשרת הנתון שהמשתמש הקיש (ולא הצורה המוצפנת ששמורה אצל ימות), זה לא יהיה יעיל לגמרי כי סו"ס המשתמש יצטרך להקיש בכל כניסה, אבל פתרון חלקי.
-
@דוד_מלך_ישראל
לא אמור להיות כ"כ הבדל מבחינת ימות.
כי גם אם כתבת בשלוחה זה מראה שאתה מסכים לשתף את זה, ואם אתה רוצה שרק מי שיקיש סיסמה יוכל לשלוח את זה לשרת תוסיף את הסיסמה -
@פיסטוק-פרווה הרווח יהיה שרק סיסמה נכונה תישלח לשרת
-
@דוד_מלך_ישראל
לא משנה, גם אם ימות יוסיפו שאם מגדירים בשלוחה למשל api_send_password=yes
שזה ישלח את הסיסמה של הניהול אז מי שירצה יוסיף שבכניסה לשלוח יצטרכו להקיש את סיסמת הניהול -
@פיסטוק-פרווה נכון, אני רוצה לפתור את מה שדיברו כאן שזה לא מעשי בגלל צורת ההצפנה, מה שאני מציע הוא שאחרי שהמשתמש הקיש את הסיסמה והיא אומתה, מה שיישלח לשרת יהיה מה שהמשתמש הקיש, שזה כמובן הסיסמה בצורתה המקורית, ולא מה ששמור אצל ימות.
-
@דוד_מלך_ישראל כתב בפתרון אפשרי למניעת בקשות שגויות דרך שלוחת API:
@פיסטוק-פרווה נכון, אני רוצה לפתור את מה שדיברו כאן שזה לא מעשי בגלל צורת ההצפנה, מה שאני מציע הוא שאחרי שהמשתמש הקיש את הסיסמה והיא אומתה, מה שיישלח לשרת יהיה מה שהמשתמש הקיש, שזה כמובן הסיסמה בצורתה המקורית, ולא מה ששמור אצל ימות.
הפוך, הסיכום של מה שדברנו זה שהסיסמאות בימות ככל הנראה לא מוצפנות.
עכשיו לעניין הצעה שלך, אם זה היה רלוונטי אפשר היה לבקש שתהיה אפשרות להוסיף בשלוחת API הגדרה ששולחת טוקן התחברות לאותה מערכת.
לכאורה אין סיבה שימות יפתחו את זה, אין שום קשר בין מודל API לAPI של ימות, זה שאתה יוצר חיבור בשרת שלך ששולח בקשות לשרת של ימות בקשר למערכת כזאת או אחרת (בהחברות למערכת אחרת למשל, הפתרון הזה כבר לא רלוונטי) זה עניין שלך. -
@פיסטוק-פרווה כתב בפתרון אפשרי למניעת בקשות שגויות דרך שלוחת API:
בדיוק לכן לא עושים האש עם פרוטוקול MD5 שנפרץ מזמן
