מה הדרישות אבטחה לסליקת אשראי באתר?

[מנצפך]

@nigun
תעשה עם IFRAME או redirect ותשכח מהצרות.
אין שום סיבה לעבוד אחרת, גם אם אתה משרד ממשלתי או ארגון ענק שמכניס הרבה באשראי.
זה אמור לעבוד מעולה, ואתה לא צריך להתעסק עם תקנים שהם מאוד יקרים!
אני אישית לא התנסיתי, אבל זה אמור להיות עניין פשוט.

[upsilon01]

@dovid
חברות האשראי יכולים לקנוס אותך בסכום מסוים על כל יום
שלא היה לך תקן PCI , לא משנה אם דלף המידע או לא
זה בחירה שלהם האם לעשות זאת או לא
ומן הסתם הם לא יקנסו אם לא הייתה דליפה של מידע

עדיף להשתמש ב iframe או redirect
ששם אין לך צורך ב PCI
להבדיל מ API רגיל שחייב ב PCI אפילו אם לא תשמור את הנתונים

[dovid]

@upsilon01 כתבתי בשם @clickone כך שאין לי מה לומר,
אבל אם אתה רוצה לתרום לדיון אתה צריך לומר מנין לך או לסייג שרק ככה זכור לך.

[clickone]

@upsilon01
זה מידיעה?
אני זוכר בבירור אחרת.
שזה לא פלילי ואי אפשר לקנוס רק אם הייתה דליפה.
אא"כ נאמר ששינו את התקנות.

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

[מנצפך]

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

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

[clickone]

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

@מנצפך אמר במה הדרישות אבטחה לסליקת אשראי באתר?:

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

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

יש לך מקור למה שכתבת?

עריכה:
הנה מקור באתר פלאכארד - שם רואים שרק במקרה של דליפה יש חשיפה לקנסות
https://www.pelecard.com/homesites/pageGen.asp?Page=21605

[WWW]

@clickone אמר במה הדרישות אבטחה לסליקת אשראי באתר?:

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

למה חייבים אותה?

[clickone]

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

והחברות סליקה חייבות לתת את זה, אחרת יהיה מאד קשה להתנהל מול הטוקן

[dovid]

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

[clickone]

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

[dovid]

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

[clickone]

@dovid אמר במה הדרישות אבטחה לסליקת אשראי באתר?:

אולי אסור לאחסן את השם והסיסמה בכלל בשרת?

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

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

[WWW]

@clickone אמר במה הדרישות אבטחה לסליקת אשראי באתר?:

בפרקטיקה משתמשים בפונקצייה הזו, לפעמים כדי לעדכן תוקף חדש וכו'

כיום ברוב הכרטיסים מוחלף גם המספר נראה לי.
וגם אם לא, התוקף הוא לא + 3 שנים...

איך באמת מתמודדים עם זה.

או כדי לעשות חיוב מיידי וכשלא רוצים להשתמש בתוקף.

לא הבנתי.

[clickone]

@WWW אמר במה הדרישות אבטחה לסליקת אשראי באתר?:

כיום ברוב הכרטיסים מוחלף גם המספר נראה לי.

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

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

@WWW אמר במה הדרישות אבטחה לסליקת אשראי באתר?:

או כדי לעשות חיוב מיידי וכשלא רוצים להשתמש בתוקף.

לא הבנתי.

סליחה, התכוונתי ללא שימוש בטוקן (כתבתי בטעות בתוקף)

[WWW]

@clickone אמר במה הדרישות אבטחה לסליקת אשראי באתר?:

בפלאכארד למשל הם יכולים לעדכן לך את הטוקן אצלם מהכספת אוטומטית.

איך?
זה מאד יעזור לי!

[nigun]

אני משתמש בסליקת אשראי של יעד שריג
וכיוון שאין להם הגדרה בימות המשיח בניתי API בעצמי
הבעיה היא שהנתונים נשמרים בלוג של ההקשות בימות וכן נשמרים בלוג של הHTTP בשרת שלי
האם זה בעיה? האם יש מעלה בשימוש בPOST במקום GET?

[dovid]

@nigun מה זה קשור לנושא הקיים?
בטח שצריך בפוסט. get מיועד לגשת למידע, שאין לה השפעה של ממש על מקבל הבקשה.
בקשה שמטרתה שהמקבל "יעשה משהו" צריכה להיעשות בpost, ולמוסכמה הזו יש לזה כמה וכמה השלכות מעשיות (כמו זו שהזכרת).

[nigun]

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

לעניינו השאלה היא מה ההשלכות של השימוש בGET חוץ מזה שזה נרשם בלוג (האמת היא שגם POST ירשם אצלי בלוג של ימות כי אני מחזיר את ההקשה לימות כדי שיקריא ללקוח את הפרטים שהוא הקיש)

[dovid]

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

[nigun]

@dovid
איזה בושות
לא השתמשתי בHTTPS
כמובן שעכשיו שיניתי לPOST ולHTTPS
אני מקווה שלא נוצר שום נזק מהטעות הזאת