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