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

[dovid]

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

[ש.ב.ח.]

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

אני לא מתכנן לשמור את הנתוני אשראי במסד נתונים

ואם כן?
האם מותר? אם כן מה הקרטיריונים?

[dovid]

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

[אבי 203]

ואם אני מקבל את פרטי האשראי באייפרם מאובטח של חברת סליקה יש בזהה איזה חשש?

[dovid]

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

[מנצפך]

@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 אמר במה הדרישות אבטחה לסליקת אשראי באתר?:

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

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