מה הדרישות אבטחה לסליקת אשראי באתר?
-
@מנצפך
השאלה איך עקצת את הטוקן.
אם זה בדגימת הבקשה, אז יש את השם משתמש והסיסמא שם.
אם זה דליפת DB, אז ברוב המוחלט של המקרים יש את שם המשתמש והסיסמא בטבלה אחרת.@מנצפך אמר במה הדרישות אבטחה לסליקת אשראי באתר?:
(ולדעתי לא צריך להאמין לכל מילה שאדם מכל תחום אומר, לפעמים יש הגזמות או אי הבנות).
מי שאמר לי את זה מכהן כיום כסמנכ"ל באחת מחברות הסליקה, ובעבר היה יועץ לוועדות הכנסת בנושא אבטחת סליקת אשראי.
כך שאני נוטה כן לקבל את דבריו, ולפחות להתייחס להם באמינות.יש לך מקור למה שכתבת?
עריכה:
הנה מקור באתר פלאכארד - שם רואים שרק במקרה של דליפה יש חשיפה לקנסות
https://www.pelecard.com/homesites/pageGen.asp?Page=21605
-
@clickone אמר במה הדרישות אבטחה לסליקת אשראי באתר?:
ומכאן הדרך זריזה לקבל את מספר האשראי ע"י פונקציית convertTokenToCc
בעבר אמר לי מישהו מתוך אחת חברות הסליקה, שהפונקצייה הזו היא הפרת התקן בצורה הכי גסה שיש, אבל אין ברירה וחייבים את הפונקצייה הזו, ולכן היא נמצאת.למה חייבים אותה?
-
@WWW החברות סליקה חייבים לתת אותה בשביל לקוחות הקצה של הבתי תוכנה (שזה אומר הסולקים בפועל)
בפרקטיקה משתמשים בפונקצייה הזו, לפעמים כדי לעדכן תוקף חדש וכו'
או כדי לעשות חיוב מיידי וכשלא רוצים להשתמש בתוקף.והחברות סליקה חייבות לתת את זה, אחרת יהיה מאד קשה להתנהל מול הטוקן
-
-
@dovid צודק.
ולכן לכאורה יש עדיפות לטוקן.
מצד שני, אם אני שם את עצמי במקום של תוקף, והצלחתי לשים את היד על DB כזה
עד שישימו לב שיש דליפה, יש לי את כל מספרי האשראי שלו....
ואז לא יעזור שיבטלו את הטוקנים
אגב לכאורת בעת דליפה לא צריך לבטל את הטוקנים, רק להחליף סיסמא...... -
-
@dovid אמר במה הדרישות אבטחה לסליקת אשראי באתר?:
אולי אסור לאחסן את השם והסיסמה בכלל בשרת?
בפרקטיקה אין מצב לזה....
נניח שיש לך תוכנה (שכתובה כאתר / אקסס / WPF מה שתרצה....) שמקבלת אשראי כתרומות
עכשיו, בכל פעם שמתקבלת תרומה, הנציג לא יודע מה באמת קורה מאחורי הקלעים. הוא פשוט מזין את הפרטים וזה מעביר. (ז"א, גם אם זה בתצורת רידיירקט שהיא הכי בטוחה, מישהו פונה לפני לשרת כדי לקבל כתובת לבקשת כרטיס)
השם משתמש והסיסמא חייב להיות שמור איפשהוא, גם מבחינה פרקטית, וגם מבחינת אבטחה, א"א שהסיסמא של הטוקנים תהיה אצל כל פקיד / מזכירה
זה גם ישגע אותם, וגם מסוכן.ובמקסימום, תוכל במצב כזה על המחשב לראות פתק שעליו כתוב : הסיסמא של האשראי היא XXXXX
ראיתי בעבר משהו כזה אצל אחד הלקוחות שלי על הסיסמא של מנב"ס.
צחקתי המון כשראיתי את זה. אבל זה עצוב
-
@clickone אמר במה הדרישות אבטחה לסליקת אשראי באתר?:
בפרקטיקה משתמשים בפונקצייה הזו, לפעמים כדי לעדכן תוקף חדש וכו'
כיום ברוב הכרטיסים מוחלף גם המספר נראה לי.
וגם אם לא, התוקף הוא לא + 3 שנים...איך באמת מתמודדים עם זה.
או כדי לעשות חיוב מיידי וכשלא רוצים להשתמש בתוקף.
לא הבנתי.
-
@WWW אמר במה הדרישות אבטחה לסליקת אשראי באתר?:
כיום ברוב הכרטיסים מוחלף גם המספר נראה לי.
לפי ידיעתי לא מוחלף המספר במקרה של תוקף חדש.
וכדי לעדכן טוקן בתוקף, אתה צריך לתת גם את המספר כרטיס. א"א לעדכן תוקף בלבד. (ברוב החברות...)וכמובן יש כאלו שיש להם עידכונים מהכספתת ששם מקבלים את התוקף החדש או את מספר הכרטיס החדש במקרה גניבה/אובדן, ובזה זה תלוי איזה תוכנה יש להם ואיזה סולק.
בפלאכארד למשל הם יכולים לעדכן לך את הטוקן אצלם מהכספת אוטומטית.@WWW אמר במה הדרישות אבטחה לסליקת אשראי באתר?:
או כדי לעשות חיוב מיידי וכשלא רוצים להשתמש בתוקף.
לא הבנתי.
סליחה, התכוונתי ללא שימוש בטוקן (כתבתי בטעות בתוקף)
-
-
-
@dovid
אצלי זה קשור אחד לשני כי פתחתי את האשכול הזה
בגלל אותו פרוייקט וזה עדיין ממשיך את השאלה של "איך מאבטחים סליקת אשראי"
אבל אם זה לא קשור אין לי בעיה לפתוח את זה בנושא חדשלעניינו השאלה היא מה ההשלכות של השימוש בGET חוץ מזה שזה נרשם בלוג (האמת היא שגם POST ירשם אצלי בלוג של ימות כי אני מחזיר את ההקשה לימות כדי שיקריא ללקוח את הפרטים שהוא הקיש)
-
@nigun זה לא קשור. פעם הבאה תשתדל שיהיה נושא לכל נושא - זה מאוד טוב בשביל מי שקורא/מחפש.
ההשלכות שעולות לי בראש בשימוש בGET הם מטמון לאורך הרשת (לא רלוונטי במקרה שלך בגלל שאני מקוה שאתה עובד עם SSL-https), הגבלת גודל הURL (הפרמטרים מוגבלים באורכם), פגיעות להתקפה ע"י שתילת הכתובת בצד לקוח במגוון דרכים.
בכל מקרה מוסכמה צריך לכבד גם בלי השלכות כי יכולות להיוולד השלכות בעתיד, והסיבה היחידה להשתמש בGET זו עצלות.
