Electronic payments over financial networks are reasonably secure, but securing payments over open networks such as the Internet presents challenges of a new dimension. So here’s an overview of the current state of the art in electronic payment systems and their security.
The exchange of goods that takes place between two parties face-to-face dates back to before recorded history began. At some point, as commerce became more complicated, humans invented abstract representations of value. Over time, representations of value became more abstract and evolved from barter to banknotes, money orders, checks, credit cards, and today, electronic payment systems.
In the process, traditional means of payment suffer from several well-known security problems: Money, signatures, and checks can be forged. Electronic means of payment retain the same drawbacks and some additional risks: Unlike paper, digital “documents” can be copied perfectly and as often as desired; digital signatures can be generated by anyone who knows the secret cryptographic key; a buyer’s name can be linked to any payment, further preserving only the anonymity of cash.
Therefore, without new security measures or means of payment such as cryptocurrencies, widespread, fast(!) electronic commerce is not possible. Only a well-designed electronic payment system can provide better security than cash, for example, in addition to flexibility of use.
ELECTRONIC PAYMENT MODELS
In commerce, there is always a payer and a payee who exchange money for goods or services – and at least one financial institution – that connects “bits” to “money.” In most existing payment systems, the latter role is divided into two parts: an issuer (used by the payer) and an acquirer (used by the payee). The electronic payment is realized by a flow of funds from the payer through the issuer and acquirer to the payee. Shown here using the example of a direct debit:
In prepaid, cash-like payment systems, a certain amount of money is withdrawn from the payer (e.g., by debiting the payer’s bank account) before purchases are made. This amount of money can be used for later payments. This category includes smart card-based electronic wallets, electronic cash, and bank checks (e.g., certified checks).
In pay-now payment systems, such as Cashtocode for online casinos, the payer’s account is debited at the time of payment. Cards with automated teller machines (ATMs) fall into this category. In pay-later (credit) payment systems, the payee’s bank account is credited with the sale amount before the payee’s account is debited. Credit card systems fall into this category. In my view, pay-now and pay-later systems are in the same class: since a payment is always made by sending some kind of “form” from the payer to the payee (be it a check, credit card slip, or other form), I call these systems “check-like.”
Both of these payment systems are direct payment systems: a payment requires an interaction between the payer and the payee. There are also indirect payment systems, where either the payer or the payee initiates the payment online without the other party involved. Electronic payments or services such as PayPal are an example of an indirect payment system.
The specific security requirements for electronic payment systems vary depending on both their design and the trust requirements for their operation. In general, however, electronic payment systems should have integrity, authorization, confidentiality, availability, and reliability.
Integrity and authorization
A payment system with integrity does not allow money to be withdrawn from a user without the user’s explicit authorization. It may also prohibit the receipt of payment without explicit consent to prevent the occurrence of events such as unsolicited bribery. Authorization represents the most important relationship in a payment system. Payment authorization can normally be done in three ways: via out-band authorization, passwords, and signatures.
In this approach, the verifying party (typically a bank) notifies the authorizing party (the payer) of a transaction. The authorizing party is required to approve or reject the payment via a secure, out-of-band channel (e.g., mail or telephone).
This is the current approach for credit cards for mail and telephone orders: Anyone who knows a user’s credit card information can initiate transactions, and the authorized user must review the statement and actively complain about unauthorized transactions.
Important Note to You: If the user does not complain within a certain time (usually 90 days), the transaction is considered “approved” by default.
A password-protected transaction requires that each message from the authorizing party contains a cryptographic check value. The verification value is computed using a secret access key known only to the authorizing and verifying parties. This secret access key may be a personal identification number (PIN), a password, or any form of shared secret (known to both parties).
Such shared secret keys known to both parties, such as a six-digit PIN, are inherently vulnerable to various types of attacks. On their own, they cannot provide a high level of security. They should only be used to control access to a physical token such as a smart card (or wallet) that performs the actual authorization via secure cryptographic mechanisms such as digital signatures. An example of this in the cryptocurrency world would be a ledger wallet. Here, access to the wallets is granted via PIN. However, all tokens, etc are only possible via secure signatures.
In the last type of transaction authentication, the verifying party needs a (digital) signature from the authorizing party. Digital signatures provide secure information of origin: only the owner of the secret signing key can “sign” messages. While anyone who knows the person’s corresponding public verification key can verify the authenticity of signatures.
How do you keep it that way with your transactions? Credit card? Cash instead? Let me know in the comments.
The post The state of the art in electronic payment systems appeared first on Technovanguard.