This article examines various systems to ensure security in electronic payment systems. Not all merchants provide a secure payment environment to their customers and, despite having a standard payment policy, adhere to it. Consequently, this exposes a customer’s payment information to risks of being compromised or misused by merchants or stolen by hackers and spammers. In this article we propose a new approach to payment systems in which a customer’s payment information cannot be obtained by a merchant. The systems and protocols explored here offer customers more secure payment systems.

Аннотация статьи
electronic payment
system
security
Verified by Visa
SecureCode
protocol
e-commerce
Ключевые слова

İnternetin ixtirası və elektron ticarətin böyüməsi və inkişafı, təhlükəsiz ödəmə sistemlərinə daha çox ehtiyacı əks etdirdi. İnkişaf etdirilən ən diqqət çəkən ödəniş sistemlərindən biri, SETco tərəfindən hazırlanmış və 1996-cı ildə Visa və MasterCard tərəfindən həyata keçirilmiş Təhlükəsiz Elektron Əməliyyatdır (SET-Secure Electronic Transaction). SET yalnız bir ödəmə sistemi deyildi, İnternet üzərindən kredit kartı əməliyyatlarını təmin etmək üçün standart bir protokol idi. Bununla birlikdə, müştəri tərəfində proqram təminatının quraşdırılması, xərc və mürəkkəblik kimi müxtəlif səbəblərdən baş tutmadı. SET-in uğursuzluğundan sonra, e-rabitə və e-ticarəti təmin etmək üçün Secure Sockets Layer (SSL) və Transport Layer Security (TLS) istifadə edildi. VISA və MasterCard, təhlükəsiz elektron ödənişlər üçün öz protokollarını, yəni Verified by Visa və MasterCard SecureCode kimi 3-D Secure hazırladılar. Visa və MasterCard-a əlavə olaraq American Express SafeKey-dən istifadə edir və JCB (Yaponiya Kredit Bürosu) J / Secure tətbiq edir. Ödənişin təhlükəsizliyini təmin etmək üçün bu provayderlər maliyyə təsdiqini onlayn identifikasiya ilə əlaqələndirirlər, burada onlayn identifikasiya həm müştərinin, həm də serverin şəxsiyyətini təsdiqləmək deməkdir və maliyyə avtorizasiyası ödəmə məlumatının bank və ya kredit kartına bağlı gizli paroldan istifadə etməklə təsdiqlənməsi deməkdir.

SET-in uğursuzluğu ilə e-ticarət şirkətləri İnternet üzərindən təhlükəsiz məlumat axını üçün Secure Sockets Layer (SSL) -ə etibar etməli oldular. SSL, ümumi kanallar üzərindən xüsusi ünsiyyət üçün unikal şəkildə şifrələnmiş bir kanal yaradır və hər hansı bir məlumat göndərilmədən əvvəl serverin sertifikatını həqiqiliyini yoxlayır. SSL üzərindən həssas məlumatların daşınması təhlükəsizliyin təmin olunmasına kömək etdi, lakin istifadə olunan kompleks texnologiyalarla Transport Layer Security (TLS) varisi olaraq tanıdıldı. TLS, əsasən HTTP, FTP, SMTP, NNTP və XMPP kimi tətbiqetmə xüsusi protokollarını əhatə etmək üçün Transmission Control Protocol (TCP) kimi nəqliyyat protokolları üzərində istifadə olunur. TLS-nin vacib bir istifadəsi, HTTPS yaratmaq üçün HTTP tərəfindən daşınan World Wide Web trafikini təmin etməkdir. SSL və TLS hazırda istifadə olunmasına və internet üzərindən məlumatların təhlükəsiz şəkildə daşınmasını təmin etməsinə baxmayaraq, e-ticarət və kredit kartı şirkətləri, müştərilərinin maliyyə məlumatlarını qorumaq üçün daha etibarlı bir ödəmə üsulu və ya sistem tələb etdilər. Bu səbəbdən Visa, Verified by Visa adlı öz təhlükəsiz ödəmə protokolunu, MasterCard isə SecureCode-u inkişaf etdirdi. Verified by Visa ve SecureCode saxta əməliyyatların qarşısını almaq üçün VISA və MasterCard tərəfindən təmin edilən əlavə bir təhlükəsizlik səviyyəsidir. Şifrə əsaslı metoddan istifadə edərək kart sahibinin şəxsiyyətini təsdiqləyirlər. Bu üsulların hər ikisi hazırda istifadə olunur və etibarlıdır. Lakin, digər metodlarda olduğu kimi, bir müştərinin ödəmə məlumatı bir tacir vasitəsi ilə ödəniş şlüzünə göndərilir.

Visa ilə MasterCard-ın təhlükəsizlik tətbiqi arasındakı yeganə fərq, Universal Cardholder Authentication Field (UCAF) yaradılmasıdır: MasterCard the Accountholder Authentication Value (AAV), Visa isə the Cardholder Authentication Verification Value (CAVV) istifadə edir. Həm AAV, həm də CVV, kart sahibinin şəxsiyyətini təsdiqləmək və dolandırıcılığın qarşısını almaq üçün istifadə edilən 3 rəqəmli təhlükəsizlik kodlardır. 3 rəqəmli təhlükəsizlik kodu, kredit kartı şirkətlərinin müvafiq kart sahibinə aid olduğunu təsdiqləmək üçün kredit kartı şirkətləri tərəfindən tətbiq olunan əlavə bir qoruma təbəqəsidir.

Həm Verified by Visa, həm də SecureCode bir əməliyyat, bir əməliyyata icazə vermək üçün satıcı veb saytından emitent bankın veb saytına yönləndirməyə başlayır. Bu protokollarda kart verən bank tərəfindən hansı identifikasiya metodundan istifadə olunduğu nəzərə alınmır, lakin əksər kart verən banklar parol əsaslı metoddan istifadə edirlər. Bu, bankın aşkar edilmiş təhlükəsizlik pozuntularına görə məsuliyyət daşıması üçün edilir. Müştəri tərəfindən banka qeydiyyatdan keçərkən seçdiyi parol səhifəsində Personal Assurance Message (PAM) olması səhifənin həmin bankdan gəldiyinin təsdiqidir. Bununla birlikdə, müştərinin brauzeri parol səhifəsi üçün SSL Server Sertifikatını təsdiqləyə bilmirsə, bu hələ bir tema daxilində bir hücum ehtimalı qalır.

Bir Visa və ya MasterCard üzv bankının Verified by Visa və ya SecureCode xidmətlərindən istifadə etməsi üçün bir bank ən son protokol xüsusiyyətlərini dəstəkləyən uyğun bir proqram çalıştırmalıdır. Uyğun proqram quraşdırıldıqdan sonra üzv bank sistemi işə salmadan əvvəl ödəmə sistemi server ilə məhsul inteqrasiyası testi həyata keçirəcəkdir. Ümumiyyətlə bir bankın tərəfində olan ACS, üçüncü tərəfə bank tərəfindən verilir və bu şərt Visa və MasterCard daxil olmaqla mövcud ödəmə protokolları ilə əhatə olunmur. Ümumiyyətlə, bir müştərinin brauzerində bankın domeni əvəzinə ACS provayderinin domeni göstərilir, lakin bu xüsusiyyət bankın domenini göstərmək üçün yenidən özəlləştirilə bilər. Bu o deməkdir ki, onlayn əməliyyatın bir bank tərəfindən icazə verildiyi deyildikdə, üçüncü tərəfin müştərinin maliyyə məlumatlarının bütün detallarını yoxlaması ola bilər. Üstəlik, Visa və MasterCard bir onlayn əməliyyatın təsdiqlənməsini bir banka buraxdıqda, müştərilər həssas maliyyə məlumatlarını verərkən əslində banklarının identifikasiya metoduna və təhlükəsizliyinə güvənirlər, əksər banklar ACS-i onlar üçün idarə edən üçüncü tərəfə etibar edirlər. Visa və MasterCard satıcılarına ödəmə tələblərini serverlərinə göndərmək üçün lisenziya vermir. Merchant Plug-In (MPI) provayderləri adlanan proqram təminatçıları lisenziyalaşdıraraq serverlərini təcrid edirlər və tacirlər bahalı MPI (quraşdırma haqqı, aylıq ödəniş və əməliyyat haqqı) almaq məcburiyyətindədirlər.

Bu, bu metodlar üçün böyük bir dezavantajdır, çünki bir müştəri bəzi satıcıların MPI tətbiqetmələri və banklar tərəfindən kənar ACS tətbiqetmələri istifadəsi səbəbindən bir tacirin veb saytını xarici domenlərə yönləndirə bilər, bu da kart sahiblərinin fişinq hücumlarını həyata keçirməsini asanlaşdırır.

Bəzi hallarda, Verified by Visa sistemi istifadəçilər tərəfindən fişinq saxtakarlığı ilə səhv salınıb və özü də bəzi fişinq saxtakarlarının hədəfinə çevrilib. Bütün bunlara əlavə olaraq, bankların əksəriyyəti mobil bankçılığı öz xidmətlərinə daxil etdikdə, əksər mobil brauzerlər, xüsusən iframe və pop-up kimi müəyyən xüsusiyyətlərin olmaması səbəbindən 3-D Secure üçün problemlər yaradır. Satıcının mobil veb saytı olsa da, emitent mobil cihazları dəstəkləmirsə, identifikasiya səhifələri düzgün göstərilmir və ya ümumiyyətlə göstərilmir. Sonda bir çox analitik, Activation During Shopping (ADS) protokollarının aradan qaldırılmasından daha çox risk yaratdığına və bu artan riskin müştərilərə ötürüldüyünə qərar verdi.

Onlayn alış-veriş və təhlükəsizlik tələbləri müxtəlif ödəmə şlüzlərinin və sistemlərinin ortaya çıxmasına səbəb oldu. Bunların arasında Skipjack kimi bəzi çox etibarlı ödəmə sistemləri, tacirlərə daha az müştəri ödəmə məlumatı (debit / kredit kartı məlumatları) təqdim edir.

Skipjack, satıcı tərəfindən və alıcı tərəfindən başlatılan iki onlayn ödəmə üsulu təqdim edir. Satıcının təşəbbüs etdiyi metod, satıcıların müştərilərdən ödəniş məlumatlarını topladığı və ödəmə keçidlərinə göndərdiyi davam edən bir ödəmə yanaşmasıdır. Bir satıcı digər satıcının başlatdığı Skipjack metodundan istifadə etdikdə, Skipjack müştərinin ödəniş məlumatlarını satıcının ödəniş formasından şifrələyir və icazə üçün banka göndərir. Skipjack-in müştəri təşəbbüsü metodunda bir tacir Skipjack-də etibarlı bir ödəmə forması yaradır və ödəniş üçün veb saytına yerləşdirir. Bir müştəri ödəmə etmək istədikdə, ödəniş məlumatlarını birbaşa Skipjack-in təhlükəsiz ödəmə formasına daxil edir. Bu metod, təklif etdiyimiz ödəmə yanaşması kimi, müştərinin ödəmə məlumatlarını birbaşa ödəmə qapısına təmin edir. Lakin Skipjack, satıcılarına kredit kartı növü və debit və ya kredit kartının son 4 rəqəmi kimi bir neçə müştəri ödəniş məlumatı təqdim edir və bir tacirə müştərinin debit və ya kredit kartı məlumatlarının bir CCV nömrəsi ilə təsdiqlənib-seçilməməsini seçməsinə imkan verir.

CCV, debit və ya kredit kartında mövcud olan standart təhlükəsizlik kodudur və debit və ya kredit kartını istifadə edən şəxsin istifadə edərkən karta sahib olduğunu yoxlamaq üçün istifadə olunur. CCV təhlükəsizlik kodu, kredit kartı verənə kredit kartı məlumatlarını və kart sahibinin kimliyini təsdiqləməyə kömək edir. Bütün kredit və ya debit kart şirkətləri tərəfindən saxtakarlığa qarşı əlavə bir qoruma olaraq istifadə olunur. Nəticə etibarilə bir satıcı müştərilərindən kredit kartı CCV nömrəsini vermələrini tələb etmədikdə, kart emitentinin kart və kart sahibi məlumatlarını təsdiqləməsinə icazə vermir. Bu günlərdə əksər kredit kartı şirkətləri CCV nömrəsi olmayan əməliyyatı rədd edir və əksər satıcılar CCV nömrəsi olmayan ödəmələri təsdiqləmirlər. Skipjack etibarlı bir yanaşma təmin etsə də, onlayn ödəmə üçün tamamilə etibarlı bir mühit təmin etmir.

Текст статьи
  1. Mohamed Nabeel, Elisa Bertino. CloudMask : Private Access Control in the Cloud, Purdue University, West Lafayette, Indiana, USA
  2. http://www.bestpaymentgateways.com/articles3.html
  3. http://www.psbill.com/3-d-secure-verified-by-visa-mastercard-securecode.html
  4. http://www.informit.com/articles/article.aspx?p=26857&seqNum=3
Список литературы
Ведется прием статей
Прием материалов
c 23 октября по 29 октября
Осталось 2 дня до окончания
Публикация электронной версии статьи происходит сразу после оплаты
Справка о публикации
сразу после оплаты
Размещение электронной версии журнала
02 ноября
Загрузка в eLibrary
02 ноября
Рассылка печатных экземпляров
10 ноября