Igen, értem én, hogy próbáltak rápiggybackelni a meglevő infrára meg sémára valami biztonságosabb megoldást, de az alapkoncepció változatlan: megbízhatatlan harmadik félen/feleken (kereskedő/payment processor/kereskedő oldali bank/kártyatársaság) keresztül jut el a bankomhoz a "megbízás", hogy fizessen a számlámról. Ez a probléma alapja az én szememben. Egy valag security problémát komplett megoldana, ha ezt nem egy ilyen megbízhatatlan csatornán keresztül akarnánk csinálni. Azt értem, hogy ez histórikusan így működött (maga a klasszikus csekkrendszer is így ment)...
A kereskedő normál esetben már rég nem kapja meg a kártyád adatait...
Normál esetben. A rendszerben ilyen-olyan okokból kifolyólag ott figyel benne ez az opció. Mintha a TLS1.2 idejében lenne egy fallback lehetőség az SSLv3-ra...
Való életbeli példa: 2023-ban az USA-ban meglehetősen standard éttermi fizetési metódus, hogy
- nem a terminált hozzák az asztalodhoz, hanem a kártyával sétál el a pincér (ez a megoldás ugye felénk már szerencsére kezd kihalni a köztudatból),
- ha PIN-kódot kér a terminál, még meg is kér, hogy segíts (sétálj te is oda),
- ugyan elektronikus foglalás van, de a foglalás a számlás összegről szól,
- te ezután a sajtfecnin beírhatod kézzel, hogy mennyi borravalót adsz,
- ezután már nincs újabb authorizálás, többet nem is látják a kártyádat, ennek ellenére valahol valaki begépeli az új összeget, és a másnapi terhelésnél már a borravalóval növelt összeget terhelik - ennek az összes alapja a sajtfecnin levő aláírásod (macskakaparásod).
Szóval vagy valaki tárolta a kártyaadatokat, vagy a bank hajlandó többet kifizetni, mint ami elektronikusan be lett foglalva. Egy aláírásra, és a kereskedő bemondására. Ha ennek bármi köze van a securityhoz, akkor én kurtafarkú kismalac vagyok.