EP4074005A1 - Procede, serveur et systeme d'authentification de transaction utilisant deux canaux de communication - Google Patents

Procede, serveur et systeme d'authentification de transaction utilisant deux canaux de communication

Info

Publication number
EP4074005A1
EP4074005A1 EP20845185.6A EP20845185A EP4074005A1 EP 4074005 A1 EP4074005 A1 EP 4074005A1 EP 20845185 A EP20845185 A EP 20845185A EP 4074005 A1 EP4074005 A1 EP 4074005A1
Authority
EP
European Patent Office
Prior art keywords
transaction
terminal
bank
code
communication channel
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP20845185.6A
Other languages
German (de)
English (en)
Inventor
David Naccache
Marc Beunardeau
Aisling CONNOLLY
Rémi GERAUD
Hiba KOUDOUSSI
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Banks and Acquirers International Holding SAS
Original Assignee
Banks and Acquirers International Holding SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Banks and Acquirers International Holding SAS filed Critical Banks and Acquirers International Holding SAS
Publication of EP4074005A1 publication Critical patent/EP4074005A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/45—Structures or tools for the administration of authentication
    • G06F21/46—Structures or tools for the administration of authentication by designing passwords or checking the strength of passwords
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/386—Payment protocols; Details thereof using messaging services or messaging apps
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/067—Network architectures or network communication protocols for network security for supporting key management in a packet data network using one-time keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/082—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying multi-factor authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/102—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measure for e-commerce

Definitions

  • the present invention relates to a transaction authentication method using two communication channels as well as to a server and a bank transaction system implementing the method. More particularly, the invention relates to the use of a second communication channel to secure a transaction carried out from a first communication channel.
  • the electronic payment transactions which are the subject of this document relate to payment transactions carried out online.
  • An online payment is made when selling or purchasing goods or services, whether by businesses, households, individuals, governments or other organizations, public or private, over interconnected networks of computers, such as the internet. Goods and services are ordered over these networks, but payment and final delivery of the good or service can be made online or offline.
  • bank customers regularly carry out wire transfer payment transactions using Internet banking services. More and more consumers are using electronic commerce, to find and purchase goods and services over electronic networks such as, for example, the Internet. Payment is generally made by entering a debit and / or credit card number, or bank card, or using other financial information in the respective fields of a form on the merchant's site. line.
  • Transactions can also be made using online or mobile payment service providers, such as those offered, for example, by PayPal, Inc., of San Jose, California.
  • electronic payment systems often use agglomerated security solutions such as those identified by the “3Dsecure”, “Verified by Visa”, or other brands.
  • Such payment services and payment security solutions can make transactions easier and / or more secure for the parties involved. Buying with the help of a payment service provider from a portable mobile device is one of the main reasons why online and mobile shopping is growing so rapidly.
  • TAN from English Transaction Authentication Numbers
  • a customer uses a device, usually internet-enabled, to select goods, services or other forms of payment transaction on the merchant's website. or online banking, and performs a first step of the payment transaction by completing the forms provided by said websites with required payment information, such as card and / or bank account number, name and address. 'cardholder's address, etc.
  • a bank, payment solution provider, or credit card issuer sends a one-time transaction authentication code to a second cardholder device.
  • the authentication code is entered manually by the cardholder and then sent via the network to the bank, to the payment solution provider or to the credit card issuer, so that the code can be compared with the code. authentication issued. If the comparison is correct, the payment transaction will be successful, otherwise the payment transaction will be refused, possibly with notification to the cardholder.
  • An authentication code is generally an alphanumeric string of a certain length.
  • the length of the chain is defined a priori by a payment scheme and is the same for all transactions.
  • the present invention aims to remedy the inconveniences mentioned above when using an authentication code in a two-factor security procedure.
  • the invention proposes to improve the aforementioned two-factor authentication system by adapting the complexity of the authentication code, in particular its length, to the amount paid during the transaction.
  • the invention provides a transaction authentication method using two data communication channels for a user using a first terminal connected to at least one bank transaction server via a first communication channel and a second terminal connected to the at least one bank transaction server via a second communication channel at least logically distinct from the first communication channel.
  • the process includes:
  • the bank transaction server receives the copied code from the first terminal, and compares the verification code with the copied code and sends to the first terminal a transaction validation message if the codes are identical or a message transaction invalidation if the codes are different.
  • the length of the verification code can increase when the amount of the transaction increases. Short authentication codes can be assigned to transactions involving small payment amounts, while longer and more complex codes, i.e. more difficult for malicious people to guess, can be assigned to payment amounts. larger payments.
  • the length of the verification code can be between a minimum value and a maximum value.
  • the user experience during electronic payment transactions is improved in two ways. First of all, and especially for small amount transactions, the work of manually copying the authentication code from one device to another is lightened, which is faster and reduces the risk of error for the user. . For transactions involving larger sums, longer and more complex authentication codes allow the user to appreciate that second factor authentication, even if it weighs down and slows down the transaction, it increases the security of the transaction, thus playing a reassuring role.
  • the transaction information can include identification information of the account holder and at least one redundant information related to the identification of the bank account to be debited.
  • the second step may include a preliminary step which verifies a concordance between the identification of the bank account to be debited, the identification information of the holder and the at least one redundant information. The second step can only be performed if the match is established.
  • the length of the verification code may also depend on a risk factor determined using one or more parameters included among: the time of the transaction, the date of the transaction, information relating to the card holder, the number of transactions carried out in a predetermined period preceding the transaction.
  • the invention provides a bank transaction server comprising a processing unit, a program memory, at least one communication interface capable of communicating via a first communication channel and via a second channel. communication at least logically distinct from the first communication channel.
  • the program memory contains instructions cooperating with the processing unit so that the server is configured for:
  • the invention provides a bank transaction system comprising at least one bank transaction server, a first terminal of a user connected to the at least one bank transaction server via a first channel communication, and a second terminal of an account holder and / or a bank card connected to the at least one bank transaction server via a second communication channel at least logically distinct from the first communication channel.
  • the first terminal is configured to send, at the user's request, to the at least one bank transaction server, a transaction request comprising at least one transaction amount, and an identification of the account and / or of the card. banking.
  • the bank transaction server is configured to, upon receipt of the transaction request, establish a verification code whose length depends on the amount of the transaction, determine the second terminal according to the identification of the bank account to be debited, then send, on the one hand, a confirmation request requesting the verification code to the first terminal via the first communication channel and, on the other hand, the verification code to the second terminal via the second communication channel.
  • the second terminal is configured to display, to the holder of the bank account, the verification code sent by the bank transaction server.
  • the first terminal is configured to send back to the bank transaction server a code copied by the user from the verification code displayed on the second terminal.
  • the bank transaction server is configured to, upon receipt of the copied code, compare with the verification code with the copied code and send to the first terminal a transaction validation message if the codes are identical or a transaction invalidation message if the codes are different.
  • FIG.1 shows a two-factor authentication bank transaction system
  • FIG.2 shows a commercial transaction system on an open network with two authentication factors
  • FIG.3 illustrates a transaction on the system of Figure 1 according to the invention
  • FIG.4 illustrates a transaction on the system of Figure 2 according to the invention
  • FIG.5 shows an operating flowchart of an authentication server according to the invention
  • Figures 1 and 2 show two transaction systems performed through an open network, such as the internet, for example, using two-factor authentication.
  • the same references correspond to the same elements or to similar elements.
  • These two figures correspond to two-factor security transaction schemes as used in the prior art and according to the invention.
  • Open network By “open network”, it is necessary to understand a communication network allowing interconnections between one or more computer machines accessible to any person wishing to do so.
  • This type of network can be the Internet but could correspond to other types of networks as long as the connection remains open to everyone.
  • Open networks have the advantage of making it easier to connect people, thereby increasing the possibilities for business transactions between people connected to the network.
  • a downside of open networks is the risk of interacting with machines owned by malicious people.
  • FIG. 1 corresponds to a banking transaction system allowing a user to carry out transaction operations with his bank, such as for example to make a bank transfer or to purchase securities online or any other type of operation for which the user transfers money from his bank account.
  • the user 1 interacts with a first terminal 2 connected to an open network 3, such as for example the Internet, in order to communicate with a banking services server 4 to carry out an operation corresponding to a banking transaction that is that is, a money transfer from a bank account.
  • an open network 3 such as for example the Internet
  • the first terminal 2 is for example a fixed or portable personal computer, a tablet or a smartphone having a processing unit, at least one volatile and / or non-volatile memory, a communication interface. making it possible to connect to the open network 3, a man-machine interface making it possible to view and enter information, such as for example a display screen, a touch screen, a keyboard, a mouse or the like.
  • the first terminal has an open network navigation program 3, allowing it to connect to and interact with websites, in particular to consult web pages or to complete and send. forms corresponding to transaction requests.
  • the first terminal 2 can have a specific program allowing it to connect through the open network 3 to the banking services server 4.
  • the banking services server 4 is for example a computer having one or more processing units, at least one volatile and mass memory, and at least one communication interface allowing it to connect to the open network 3.
  • the mass memory stores, among other things, a database containing all the information relating to the bank accounts of the customers of the bank to which it belongs.
  • the banking services server 4 comprises programs stored in memory allowing it to make available to terminals connected, through the open network 3, searchable web pages which make it possible to interact with users via forms contained in said web pages.
  • the forms once completed and returned by the user, are then processed by the processing unit for validation.
  • the processing unit uses the first terminal 2 to connect to the banking services server 4.
  • a web page is then transmitted to the first terminal 2 by the banking services server 4.
  • the web page can include information to be displayed on the first terminal 2, as well as commands to be executed as a function of the choice made by the user via the man-machine interface.
  • a transaction for example a bank transfer
  • a transaction form is presented to user 1, the form being able to be included in the web page or transmitted by the banking services server 4 after receipt of a message indicating the user's choice. 1 from the first terminal 2.
  • the user 1 then fills out the form with the information necessary for the transaction which may include the identification of the bank account to be credited, the identification of the bank account to be debited, the amount of the transaction.
  • a lot of other information may also be required, such as redundant identifiers of the user and / or of the bank account or of its holder, a secret known only to the bank and the holder, a transaction identifier or any other information that is in connection with the transaction.
  • user 1 sends the completed form to the banking services server 4 via the first terminal 2.
  • the form can be accompanied by the time and date of sending and also identifiers specific to the first one. terminal 2.
  • the banking services server 4 verifies the information contained in the form and in particular whether the requested transaction can be authorized or not. To this end, the banking services server 4 queries its database to check whether the account to be debited is still in service and whether the credit of the account to be debited can make it possible to authorize the transaction. Optionally, the server can verify the correctness of redundant identifiers or information on the holder of the bank account. This first check corresponds to a first safety factor. However, the transaction was transmitted by the open network 3 and, despite this first check, it is possible that this transaction came from a misappropriation of the form and / or information relating to the bank account by a malicious third party.
  • the communications on the open network 3 can be intercepted and possibly replayed in a modified manner.
  • any encrypted message can be decrypted after a certain period of time, making it possible to retrieve an exchanged form and reuse the information it contains.
  • the fact that the network is open allows malicious people to spread viruses on the machines connected to it and in particular the first terminal 2. Among the viruses, some can intercept the information exchanged on the man-machine interfaces. and send them back to another machine, also rendering the confidentiality of encrypted messages inoperative.
  • a second security factor can be added by using a second communication channel to send a one-time code.
  • the banking services server 4 has a second communication interface capable of communicating via the second communication channel with a second terminal 5 which belongs to a bank account holder.
  • the second terminal 5 is identified in the database of the banking services server 4 in relation to the bank account to be debited.
  • the second terminal 5 can be, conventionally, a mobile telephone of the holder of the bank account, but can also be any other type of device connected to a communication network, such as, for example, a box connected to a supplied mobile telephone network. by the bank or even a tablet or a computer connected to the Internet.
  • the important thing is that the second communication channel is at least logically distinct from the first communication channel used for sending the transaction form.
  • the banking services server 4 retrieves, in its database, the identifier of the second terminal 5 to send it a one-time verification code.
  • the identifier of the second terminal 5 is, for example, a mobile telephone number and the message is, for example, sent by a short message of the SMS type (English Short Message Service).
  • the message can also indicate the amount of the transaction and / or the beneficiary of the transaction, so that the account holder can verify that the current transaction conforms to a desired transaction.
  • the banking services server 4 sends to the first terminal 2 a confirmation request requesting the single-use code.
  • User 1 if he corresponds to the holder of the bank account, can then read the one-time code on the second terminal 5 and copy it into a response form attached to the confirmation request in order to send it back to the service server. banking 4.
  • the banking services server 4 compares the code present in the form with the one-time code sent to the second terminal 5. If the two codes are identical, then the banking services server 4 validates the transaction and sends a message to the first terminal 2 to inform it of the acceptance of the transaction. If the two codes are different, then the transaction is refused and the banking services server 4 sends a message to the first terminal indicating that the transaction is refused. Optionally, the banking service server 4 can reiterate the sending of a new one-time verification code to the second terminal 5 and a request to the first terminal 2.
  • FIG. 2 corresponds to a commercial transaction system allowing a user 1 to make a purchase on a merchant site 6.
  • the merchant site 6 is a server-type computer which is connected to the open network 3 in order to provide web pages which offer products and / or services to users connecting to them using an appropriate terminal.
  • the user 1 connects to the merchant site 6 using the first terminal 2 via the open network 3.
  • the merchant site 6 sends a transaction form to the first terminal 2.
  • the transaction form is pre-filled by the merchant site 6 with the identification of the seller, his bank account and the amount of the transaction.
  • the transaction form is presented to user 1 by the first terminal 2, asking the latter to complete with an account or bank card identification.
  • user 1 sends the form to the merchant site 6 via the first terminal 2.
  • the form can be accompanied by the time and date of sending and also identifiers specific to the first terminal 2 such that, for example, its address on the open network 3.
  • the merchant site 6 receives the form and transmits it to an acquirer service server 7 which corresponds to its bank.
  • the acquirer services server 7 is a computer having one or more processing units, at least one volatile and mass memory, at least one communication interface allowing it to connect with the merchant site 6 and 'at least one communication interface for connecting to a secure network dedicated to banking services.
  • the communication interface communicating with the merchant site 6 can correspond to a specific secure link or to an open network implementing encrypted communication.
  • the acquirer services server 7 then transmits the transaction form, via the secure network, to a debtor services server 4 ’which corresponds to the issuer of the bank card.
  • Debit service server 4 "is similar to bank service server 4.
  • Debit service server 4" can be the cardholder's bank server or the server of a credit card issuer.
  • the debtor service server 4 On receipt of the transaction form, the debtor service server 4 'checks the information contained in the form and, in particular, whether the requested transaction can be authorized or not. To this end, the debtor services server 4 'queries its database to check whether the account or the bank card is still in service, if any redundant information is in conformity with the card or the bank account and if the amount of the payment. transaction corresponds to an authorized amount. This first level of security verification having been carried out, the debtor services server 4 'carries out a verification according to a second security level similar to that described in relation to FIG. 1 with some differences.
  • the debtor service server 4 ' identifies in its database the second terminal 5 in relation to the card or the bank account to be debited and a second communication channel distinct, at least logically, from the communication channel with the first terminal 2.
  • the debtor services server 4 ′ sends a message comprising a one-time verification code to the second terminal 5.
  • the message can also indicate the amount of the transaction and / or the beneficiary of the transaction, so that the holder of the account can verify that the current transaction conforms to a desired transaction.
  • the debtor service server 4 sends to the first terminal 2 a confirmation request requesting the one-time code.
  • This request can be sent to the first terminal 2 via the acquirer service server 7 and the merchant site 6 via the open network 3 or directly by the debtor service server 4 ′ via the open network 3.
  • the user 1 if it corresponds to the card or bank account holder can then read the single-use code on the second terminal 5 and copy it into a response form attached to the confirmation request, in order to send it back to the debtor services server 4 'using the same communication channel.
  • the debtor service server 4 On receipt of the response form, the debtor service server 4 'compares the code present in the form with the one-time code sent to the second terminal 5. If the two codes are identical, then the banking services server 4 validates the transaction and sends a message to the acquirer services server 7 which records the transaction and transmits a validated payment message to the merchant site 6. The merchant site 6 then informs the first terminal 2 that the payment is accepted and delivers the service or initiates a procedure for delivering product (s) which will not be detailed in this document. If the two codes are different, then the transaction is refused and the debtor service server 4 'sends a message to the acquirer service server 7 which is retransmitted to the merchant site 6, then to the first terminal 2 indicating that the transaction is refused and therefore not completed.
  • the debtor services server 4 ′ can reiterate the sending of a new one-time verification code to the second terminal 5 and of a new request to the first terminal 2 via one of the paths indicated above.
  • FIGS. 3 and 4 illustrate the steps of the transaction methods carried out according to the invention respectively on the transaction systems described in relation to FIGS. 1 and 2.
  • the flowchart of FIG. 5 details the steps of the processing method. transaction verification performed according to the invention by the banking services server 4 or the debtor services server 4 'during the exchanges carried out in accordance with FIG. 3 or FIG. 4.
  • the steps common between FIGS. 3, 4 and 5 bear the same references and the description of FIG. 5 is made in conjunction with the descriptions of FIGS. 3 and 4.
  • the steps prior to a choice of transaction by user 1 are not detailed in Figures 3 and 4 which begin after a transaction decision, corresponding to the making of a payment, has been validated by the user 1 of the first terminal 2.
  • the banking services server 4 sends to the first terminal 2 a transaction form corresponding to the choice of user 1 in a first step 301 of the transaction process.
  • the user 1 takes note of the form received by the first terminal 2, for example using a display screen of the first terminal 2.
  • the user fills in the form with the information requested during a third step 303 of the transaction method, for example using a keyboard of the first terminal 2.
  • the user validates the form in order to send it.
  • a fourth step 304 of the transaction method corresponds to the sending of the form by the first terminal 2 to the banking services server 4 via the open network 3.
  • This fourth step 304 of the transaction method corresponds to a first verification step 501 of the banking services server 4.
  • the banking services server 4 receives an incoming message R1 arriving via the first communication channel.
  • the incoming message R1 contains credentials ID of a bank account and a transaction amount TA.
  • the identification information ID includes at a minimum the bank account number, but may include redundant information such as, for example, one or more of: a password, a PIN code, one or more information of the identity of the user. Bank account owner.
  • the identification information ID can also include parameters specific to the transaction, such as for example the time, date or place where the first terminal 2 is located, as well as an identifier of said first terminal 2.
  • a second verification step 502 the banking services server 4 verifies that the bank account exists and that it is not blocked. Optionally, other checks can be performed to verify that any redundant information complies with that corresponding to the bank account. Further, the banking service server 4 can also verify that the amount to be debited is consistent with an authorized debit from the bank account.
  • the banking services server 4 calculates a length L of verification code in a third verification step 503 where the length L corresponds to a number of digits of said code.
  • the length L is determined as a function of the amount of the transaction TA, so that the verification code takes into account the amount of the transaction as a risk factor.
  • the following formula can be used:
  • identification information ID can be taken into account in determining the number of digits.
  • the parameters A and B can be stored in the database of the bank service server 4 and accessed using the identification of the account number.
  • the parameters A and B can be defined according to a risk accepted by the user or by his account manager, B corresponding to a minimum number of digits and A being determined according to an amount for which a financial risk seems acceptable.
  • the verification code length L being determined, the banking service server 4 then calculates a verification code AC during a fourth verification step 504.
  • the verification code AC can be generated in different ways, preferably using a random or pseudo-random number generated by the processing unit of the banking service server 4. A As a simple example, the following formula can be used to determine the verification code:
  • H corresponding to a cryptographic hash function, for example a SHA-3, performed on the concatenation of the random number Seed, the amount of the transaction TA and one or more identification information IDs.
  • a cryptographic hash function for example a SHA-3
  • a fifth verification step 505 is performed by the banking services server 4.
  • the fifth verification step 505 consists in sending an outgoing message S1, by the first communication channel, to the destination from the first terminal 2, the outgoing message containing a Req request asking the user 1 of the first terminal 2 to return a verification code in a response form.
  • the banking services server 4 performs a sixth verification step 506.
  • the sixth verification step 506 consists of send an outgoing message S2 by the second communication channel to the second terminal 5.
  • the second terminal 5 is, prior to sending, identified in the database of the banking services server 4 in association with the bank account to be debited.
  • the outgoing message S2 contains the verification code AC calculated during the fourth verification step.
  • the fifth verification step 505 corresponds to a fifth step 305 of the transaction method and the sixth verification step 506 corresponds to a sixth step 306 of the transaction method.
  • the first terminal 2 having received the request Req, it is presented to the user 1 during a seventh step 307 of the transaction method, the response form being to be completed by the user 1.
  • an eighth step 308 of the transaction method consists in the presentation of the verification code AC by the second terminal 5 to the user 1.
  • the copied verification code AC ′ is sent to the banking services server 4 in a tenth step 310 of the transaction process.
  • the tenth step 310 of the transaction method corresponds to a seventh verification step 507 carried out by the banking services server 4.
  • the banking services server 4 receives an incoming message R1 arriving from the first communication channel having for content the copied code AC ' .
  • An eighth verification step 508 then consists in comparing the copied code AC ’with the verification code AC calculated during the fourth verification step 504.
  • the banking services server 4 performs a ninth verification step 509 during which it validates and records the completion of the transaction. Then, a tenth verification step 510 is carried out to send an outgoing message S1 via the first communication channel to the first terminal 2 to indicate that the transaction has been carried out.
  • the banking services server 4 performs an eleventh step 511 during which it cancels the transaction. If, during the second verification step 502, the banking services server 4 has not found the bank account or has found the bank account but that it is blocked or even if other verifications have shown that any redundant information is not not in accordance with those corresponding to the bank account, the second verification step 502 can lead directly to the eleventh verification step 511 and also cancel the transaction. After the eleventh verification step 511, a twelfth verification step 512 is performed to send an outgoing message S1 via the first communication channel to the first terminal 2 to indicate that the transaction is canceled.
  • the tenth verification step 510 or the twelfth verification step 512 corresponds to an eleventh step 311 of the transaction method in which the first terminal 2 receives the outgoing message S1 to display it to the user 1 during a twelfth step 312 of the transaction method.
  • user 1 is informed of the completion or cancellation of the requested transaction.
  • Figure 4 discloses a transaction process carried out from the merchant site 6. After the user has chosen to make a purchase, the merchant site 6 sends to the first terminal 2 a transaction form in a first step 401 of the transaction process. In a second step 402 of the transaction method, the user 1 takes note of the form received by the first terminal 2. The user 1 fills in the form with the information requested during a third step 403 of the transaction method.
  • the form contains ID credentials of a card or bank account and a TA transaction amount.
  • the identification information ID includes at a minimum the number of card or bank account but can include redundant information such as, for example, one or more elements among: a password, a PIN code, a CW code, one or more. several identity information of the account holder.
  • the identification information ID can also include parameters specific to the transaction such as, for example, the time, date or place where the first terminal 2 is located or else an identifier of said first terminal 2.
  • a fourth step 404 of the transaction method corresponds to the sending of the form by the first terminal 2 to the merchant site 6 via the open network 3.
  • the merchant site 6 retransmits the form to the acquirer service server 7 during a fifth step 405 of the transaction method.
  • the acquirer service server 7 determines a corresponding debit service server 4 ′, in order to retransmit the form to it during a sixth step 406 of the transaction method. .
  • This sixth step 406 of the transaction method corresponds to the first verification step 501, performed by the debtor service server 4 ′, corresponding to the reception of the incoming message R1 arriving from the first communication channel.
  • the debtor services server 4 ′ then performs the second verification step 502, in order to verify that the account or the bank card exists and that it is not blocked.
  • other checks can be carried out to verify that any redundant information complies with that corresponding to the account or the bank card.
  • the debtor service server 4 ’ can also verify that the amount to be debited complies with an authorized debit from the account or bank card.
  • the debtor service server 4 ’performs the third verification step 503 and calculates a length L of verification code AC corresponding to a number of digits of said code.
  • the length L is determined as a function of the amount of the transaction TA so that the verification code AC takes into account the amount of the transaction as a risk factor as previously described.
  • the length L of the verification code may also incorporate other risk factors such as a transaction hour and / or a number of recently completed transactions. For example, such an integration can result in the following formula:
  • Nb representing the number of transactions carried out in the last twenty-four hours with the same account number or the same bank card
  • T representing the time of the transaction
  • R (T) being a risk coefficient depending on the time T
  • the coefficient R (T) being for example read in a correspondence table produced from statistics on the time of execution of fraudulent transactions.
  • the debtor services server 4 ’then calculates the verification code AC during the fourth verification step 504 as previously described.
  • the fifth and sixth verification steps 505 and 506 are then performed in parallel.
  • the fifth verification step 505 consists in sending an outgoing message S1 via the first communication channel to the first terminal 2 which contains a confirmation request Req asking the user 1 of the first terminal 2 to send back a verification code in a response form.
  • the sixth verification step 506 consists in sending an outgoing message S2 via the second communication channel, to the second terminal 5, the second terminal 5 having been previously identified from the database of the debtor services server 4 'in association with the account or bank card to be debited.
  • the outgoing message S2 contains the verification code AC calculated during the fourth verification step 504.
  • the fifth verification step 505 corresponds to a seventh step 407 of the transaction method.
  • the debtor service server 4 ′ transfers an outgoing message containing the request S1 (Req) to the acquirer service server 7.
  • the acquirer service server 7 transfers this message to the merchant site 6 during the process.
  • an eighth step 408 of the transaction method The merchant site 6 then retransmits the request to the first terminal 2 in a ninth step 409 of the transaction method.
  • the sixth verification step 506 corresponds to a tenth step 410 of the transaction method during which the second terminal 5 receives the verification code AC.
  • the first terminal 2 having received the request Req, it is presented to the user 1 during an eleventh step 411 of the transaction method, the response form being to be completed by the user 1.
  • a twelfth step 412 of the transaction method consists in the presentation of the verification code AC, by the second terminal 5, to the user 1.
  • User 1 having the verification code AC, fills out the response form by copying the verification code AC into the response form during a thirteenth step 413 of the transaction process.
  • the copied verification code AC ′ is sent to the merchant site 6 in a fourteenth step 414 of the transaction process.
  • the merchant site 6 transmits the response form to the acquirer service server 7.
  • the acquirer service server 7 transmits the completed form to the debtor services server 4 '.
  • the sixteenth step 416 of the transaction method corresponds to the seventh verification step 507 performed by the debtor services server 4 ′.
  • the debtor services server 4 ’ receives an incoming message R1 arriving by the first channel, having for content the copied code AC’.
  • the debtor service server 4 "compares the copied code AC" with the verification code AC calculated during the fourth verification step 504.
  • the debtor service server 4 ’performs the ninth step 509 during which it validates and records the completion of the transaction. Then, the tenth verification step 510 is carried out to send an outgoing message S1 via the first communication channel, to the first terminal 2, to indicate that the transaction has been carried out.
  • the debtor service server 4 ′ performs the eleventh step 511 during which it cancels the transaction. If, during the second verification step 502, the debtor services server 4 'has noted that the account or the bank card is blocked or if other verifications have shown that any redundant information does not comply with that corresponding to the account or the bank card, the second verification step 502 can lead directly to the eleventh verification step 511 and also cancel the transaction. After the eleventh verification step 511, a twelfth verification step 512 is performed to send an outgoing message S1, via the first communication channel, to the first terminal 2 to indicate that the transaction is canceled.
  • the tenth verification step 510 or the twelfth verification step 512 correspond to a seventeenth step 417 of the transaction method in which the acquiring service server 7 receives the outgoing message S1.
  • the acquirer service server 7 records the completion or cancellation of the transaction and transmits the outgoing message to the merchant site 6 during an eighteenth step 418 of the transaction process.
  • the merchant site 6 notes the validation or cancellation of the transaction. If the transaction is validated, the merchant site 6 delivers the service or triggers the delivery of the purchased product.
  • the merchant site 6 sends a transaction confirmation or cancellation message to the first terminal 2.
  • the first terminal 2 displays the confirmation message to the user 1 during a transaction.
  • twentieth step 420 of the transaction process Thus, user 1 is informed of the completion or cancellation of the purchase made.
  • the seventh to ninth steps 407 to 409 of the transaction method described in relation to FIG. 4 can be replaced by a first alternative step 421 which directly transmits the request for a confirmation code from the debtor services server 4 ′ to the first terminal 2 via the open network 3.
  • a second alternative step 422 can replace the fourteenth to sixteenth steps 414 to 416 of the transaction method to directly transmit the verification code copied AC 'from the first terminal 2 to the debtor services server 4 '.
  • the first terminal 2 is a computer connected to the Internet and the second terminal 5 is a mobile telephone.
  • the first and second terminals 2 and 5 can be any type of connected device which can exchange data with a remote server. According to one variant, the first and second terminals 2 and 5 can be one and the same physical terminal. The important thing is that the first and second communication channels are at least logically separated from each other so that malicious interception of the first channel does not automatically lead to malicious interception of the second channel.
  • the first and second terminals can be one and the same personal computer with a first communication channel comprising internet browsing software and a second communication channel comprising messaging software, the identification of the second communication channel using an email address.
  • the first and second communication channels are logically distinct from each other, although the physical connection of the terminals uses the same communication interface, namely the same network connection card.
  • the verification code sent by the second channel is not directly accessible by the navigation software and it is necessary for the user to act on a man-machine interface of the personal computer to view and copy said code.
  • only software that intercepts actions performed on the human-machine interface can intercept the verification code.
  • this type of interception can also be achieved when the two communication channels are physically distinct and therefore the logical differentiation constitutes the same level of security as a physical differentiation of the communication channels.
  • an electronic transaction is carried out between two bank accounts belonging to two different holders who have two banks. different each having their own server.
  • the seller and the buyer have a bank account in the same bank.
  • the debtor 4 ′ and acquirer 7 service servers form one and the same server, which makes it possible to reduce the number of exchanges.
  • one or more intermediary service providers can also be interposed between the debtor 4 ’and acquirer service servers 7. This is particularly the case when credit cards are used. The link is not made directly from bank to bank, but goes through a card provider who can replace the cardholder's bank or simply act as an intermediary in an online transaction.
  • the banking service servers 4, debtors 4 ’and acquirers 7 can be distributed servers. Given the volume of banking data and the number of transaction requests, several independent computers connected to a network can perform the role of each of the banking services 4, debtors 4 'and acquirers 7 servers. Each computer constituting one of the servers can perform all the operations of a transaction or only a part, the different transaction operations being performed on different computers.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Technology Law (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Software Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Computer And Data Communications (AREA)
  • Communication Control (AREA)

Abstract

L'invention concerne un procédé de transaction pour un utilisateur 1 utilisant un premier et un deuxième terminal 2 et relié à un serveur 4 via respectivement un premier et un deuxième canal de communication. Le premier terminal 2 envoie 304 au serveur 4 un montant de transaction TA. Le serveur 4 établit 502 à 504 un code de vérification AC dont une longueur L est fonction du montant de la transaction TA puis envoie 505 et 506 une requête Req au premier terminal 2 et le code de vérification AC au deuxième terminal 5. L'utilisateur renvoie 310 ladite requête remplie avec un code recopié AC' au serveur 4 à l'aide du premier terminal 2. Le serveur 4 compare 508 le code de vérification AC avec le code recopié AC' et envoie 510, 512 au premier terminal 2 un message de validation ou d'invalidation de transaction en fonction de la comparaison.

Description

Description
Titre de l'invention : PROCEDE, SERVEUR ET SYSTEME D’AUTHENTIFICATION DE TRANSACTION UTILISANT DEUX CANAUX DE COMMUNICATION
[0001] Domaine Technique
[0002] La présente invention se rapporte à un procédé d’authentification de transaction utilisant deux canaux de communication ainsi qu’à un serveur et un système de transaction bancaire mettant en œuvre le procédé. Plus particulièrement, l’invention se rapporte à l’utilisation d’un deuxième canal de communication pour sécuriser une transaction réalisée à partir d’un premier canal de communication.
[0003] Arrière-Plan Technologique
[0004] Les transactions de paiement électronique faisant l’objet de ce document concernent les opérations de paiement réalisées en ligne. Un paiement en ligne est réalisé lors de la vente ou l’achat de biens ou de services, aussi bien par des entreprises, des ménages, des particuliers, des gouvernements ou d’autres organisations, publiques ou privées, sur des réseaux interconnectés d’ordinateurs, tel que par exemple internet. Les biens et services sont commandés sur ces réseaux, mais le paiement et la livraison finale du bien ou du service peuvent être effectués en ligne ou hors ligne. De plus, les clients des banques effectuent régulièrement des opérations de paiement par virement en utilisant les services bancaires par Internet. De plus en plus de consommateurs utilisent le commerce électronique, pour rechercher et acheter des biens et des services sur des réseaux électroniques tels que, par exemple, Internet. Le paiement s'effectue généralement par la saisie d'un numéro de carte de débit et/ou de crédit, ou carte bancaire, ou à l’aide d'autres informations financières dans les champs respectifs d’un formulaire du site du commerçant en ligne. Les transactions peuvent également être effectuées à l'aide de fournisseurs de services de paiement en ligne ou mobiles, tels que ceux proposés par exemple par la société PayPal, Inc., de San José, en Californie. Pour assurer une meilleure sécurité, les systèmes de paiement électronique utilisent souvent des solutions de sécurité agglomérées telles que celle identifiées par les marques « 3Dsecure », « Verified by Visa », ou autre. De tels services de paiement et solutions de sécurité de paiement peuvent rendre les transactions plus faciles et/ou plus sûres pour les parties impliquées. Acheter avec l'aide d'un fournisseur de services de paiement depuis un terminal mobile portable est l'une des principales raisons pour lesquelles les achats en ligne et sur mobile se développent très rapidement.
[0005] Les systèmes de paiement en ligne traditionnels exposent les utilisateurs à des risques de sécurité. Par exemple, taper des numéros d’un identifiant de carte de crédit dans un champ d'un formulaire de paiement en ligne expose un utilisateur au vol de ce numéro par une tierce personne qui regarde son écran, par un virus informatique de journalisation de frappe, etc. Bien que le stockage des numéros de carte de crédit par un détaillant en ligne puisse éviter d’obliger l’utilisateur à saisir manuellement à chaque achat les informations au cours de la transaction de paiement, il expose le détaillant en ligne à ses propres risques et responsabilités en matière de sécurité. Les informations sur les cartes de crédit peuvent également être capturées par des moyens simples, par exemple, en prenant une photo d'une carte exposée par inadvertance, sans oublier que des cartes de crédit peuvent être perdues ou volées, ce qui permet à une personne malintentionnée d’en faire un mauvais usage.
[0006] Par conséquent, les systèmes de paiement électroniques modernes, tels que les opérations bancaires en ligne et le commerce électronique, utilisent souvent une procédure dite d'authentification à deux facteurs de sécurité, ci-après désigné 2FA, pour authentifier en toute sécurité un client titulaire de carte bancaire lors de la transaction de paiement. Les procédures d'authentification à deux facteurs sont bien connues de l'homme du métier. L'une des formes les plus anciennes d'authentification à deux facteurs de sécurité, généralement utilisée par des banques pour les transactions bancaires par Internet, consiste à émettre aux clients titulaires de carte, avec la carte bancaire, une liste numérotée de nombres d’authentification de transaction, communément nommée TAN (de l’anglais Transaction Authentication Numbers), afin que, après la saisie des informations de carte dans un formulaire de demande de paiement sur un site Web d’une banque, dans une deuxième étape de la transaction, la banque demande à l'utilisateur de saisir manuellement la valeur TAN correspondant à un numéro choisi aléatoirement par la banque parmi la liste TAN.
[0007] Les inconvénients et la sécurité limitée de la solution 2FA susmentionnée conduisent à des formes plus avancées de procédures d’authentification à deux facteurs qui peuvent exiger, de nos jours, qu’un client dispose, outre la carte de paiement et/ou d’autres informations d’identité du client et d’un code PIN (de l’anglais Personnal Identification Number), d’un deuxième appareil personnel, enregistré par le système de paiement ou par la banque auprès de ce client, ledit appareil personnel étant utilisé comme second facteur d'authentification du client lors des transactions de paiement. Généralement, un tel appareil est un téléphone mobile ou un jeton sécurisé connecté à Internet ou à un autre réseau et qui est émis par la banque ou tout autre fournisseur de solution de paiement. Dans le cas d’une procédure 2FA, lors d'une transaction de paiement, un client utilise un appareil, généralement compatible avec Internet, pour sélectionner des biens, des services ou d'autres formes de transaction de paiement sur le site Web du marchand ou de la banque en ligne, et réalise une première étape de la transaction de paiement en remplissant les formulaires fournis par lesdits sites Internet avec des informations de paiement requises, telles que le numéro de carte et/ou de compte bancaire, le nom et l'adresse du titulaire de la carte, etc. Une fois le formulaire envoyé, une banque, un fournisseur de solution de paiement ou un émetteur de carte de crédit envoie à un deuxième appareil du titulaire un code d’authentification de transaction à usage unique. Dans une deuxième étape, le code d’authentification est saisi manuellement par le titulaire puis envoyé via le réseau à la banque, au fournisseur de solution de paiement ou à l’émetteur de carte de crédit, afin que le code soit comparé au code d’authentification émis. Si la comparaison est correcte, l’opération de paiement sera réalisée avec succès, sinon, la transaction de paiement sera refusée, éventuellement avec notification au titulaire de la carte.
[0008] Bien que cette procédure d’authentification à deux facteurs augmente la sécurité globale des transactions de paiement électronique, elle augmente également le temps de transaction et d’abandon de panier d’achat. En effet, la saisie manuelle du code d’authentification prend non seulement un temps supplémentaire, mais plus important encore, elle est source d’erreur, ce qui crée une mauvaise expérience utilisateur qui peut entraîner l’abandon de la transaction à ce stade.
[0009] Un code d'authentification est généralement une chaîne alphanumérique d'une certaine longueur. La longueur de la chaîne est définie a priori par un schéma de paiement et elle est la même pour toutes les transactions.
Aujourd'hui, les implémentations de schémas à deux facteurs sont confrontées au dilemme suivant : soit le code d'authentification est court, ce qui est mieux pour l'expérience utilisateur, mais sa sécurité est médiocre car les codes courts peuvent être facilement devinés ; soit le code est long, ce qui est préférable pour la sécurité du système de paiement, mais augmente le risque d’erreur pour l’utilisateur.
[0010] La présente invention vise à remédier aux désagréments évoqués précédemment lors de l’utilisation de code d’authentification dans une procédure à deux facteurs de sécurité.
[0011] Résumé de l’Invention
[0012] L'invention propose d’améliorer le système d’authentification à deux facteurs susmentionné en adaptant la complexité du code d'authentification, en particulier sa longueur, au montant payé lors de la transaction.
[0013] Selon un mode de réalisation, l’invention propose un procédé d’authentification de transaction utilisant deux canaux de communication de données pour un utilisateur utilisant un premier terminal relié à au moins un serveur de transaction bancaire via un premier canal de communication et un deuxième terminal relié à l’au moins un serveur de transaction bancaire via un deuxième canal de communication au moins logiquement distinct du premier canal de communication. Le procédé comporte :
- une première étape au cours de laquelle le premier terminal envoie à l’au moins un serveur de transaction bancaire des informations de transaction comprenant au moins un montant de la transaction, et une identification d’un compte et/ou d’une carte bancaire à débiter, - une deuxième étape au cours de laquelle le serveur de transaction bancaire établit un code de vérification dont une longueur est fonction du montant de la transaction, détermine le deuxième terminal en fonction de l’identification du compte et/ou de la carte bancaire à débiter, puis envoie, d’une part, une requête de confirmation demandant le code de vérification au premier terminal via le premier canal de communication et, d’autre part, le code de vérification au deuxième terminal via le deuxième canal de communication,
- une troisième étape au cours de laquelle l’utilisateur copie le code de vérification reçu sur le deuxième terminal dans la requête de confirmation reçue par le premier terminal et renvoie ladite requête ainsi remplie avec le code recopié au serveur de transaction bancaire à l’aide du premier terminal via le premier canal de communication,
- une quatrième étape au cours de laquelle le serveur de transaction bancaire reçoit du premier terminal le code recopié, et compare le code de vérification avec le code recopié et envoie au premier terminal un message de validation de transaction si les codes sont identiques ou un message d’invalidation de transaction si les codes sont différents.
[0014] Ainsi, la longueur du code de vérification peut croître lorsque le montant de la transaction croît. Des codes d’authentification courts peuvent être attribués aux transactions impliquant de faibles montants de paiement, tandis que des codes plus longs et plus complexes, c’est-à-dire plus difficiles à deviner par des personnes malveillantes, peuvent être attribués aux montants de paiements plus importants. De manière préférée, la longueur du code de vérification peut être comprise entre une valeur minimale et une valeur maximale.
[0015] L'expérience utilisateur lors des transactions de paiement électronique est améliorée de deux manières. Tout d’abord, et surtout pour les transactions de faible montant, le travail de copie manuelle du code d’authentification d’un périphérique à un autre est allégé, ce qui est plus rapide et diminue le risque d’erreur pour l’utilisateur. Pour les transactions impliquant des sommes plus importantes, des codes d’authentification plus longs et plus complexes permettent à l’utilisateur d’apprécier que l’authentification par le second facteur, même si elle alourdit et ralentit la transaction, accroît la sécurité de la transaction, jouant ainsi un rôle rassurant.
[0016] En variante, les informations de transaction peuvent comprendre des informations d’identification du titulaire du compte et au moins une information redondante liée à l’identification du compte bancaire à débiter. La deuxième étape peut comporter une étape préliminaire qui vérifie une concordance entre l’identification du compte bancaire à débiter, les informations d’identification du titulaire et la au moins une information redondante. La deuxième étape peut n’être réalisée que si la concordance est établie.
[0017] Considérant qu’un facteur de risque lors de la transaction peut dépendre d’autres paramètres que le montant de la transaction, la longueur du code de vérification peut dépendre en outre d’un facteur de risque déterminé à l’aide d’un ou plusieurs paramètres compris parmi : l’heure de la transaction, la date de la transaction, des informations relatives au titulaire de la carte, le nombre de transactions effectuées dans une période prédéterminée précédant la transaction.
[0018] Selon un deuxième mode de réalisation, l’invention propose un serveur de transaction bancaire comprenant une unité de traitement, une mémoire de programmes, au moins une interface de communication apte à communiquer via un premier canal de communication et via un deuxième canal de communication au moins logiquement distinct du premier canal de communication. La mémoire de programme comporte des instructions coopérant avec l’unité de traitement de sorte que le serveur soit configurer pour :
- à réception depuis le premier canal de communication d’une demande de transaction comprenant au moins un montant de la transaction et une identification d’un compte bancaire à débiter, calculer une longueur d’un code de vérification en fonction du montant de la transaction, déterminer le code de vérification à partir de la longueur de code calculée, déterminer un deuxième canal de communication en fonction de l’identification du compte bancaire à débiter, envoyer une requête de confirmation demandant le code de vérification via le premier canal de communication, et envoyer le code de vérification via le deuxième canal de communication, - à réception d’un code reçu via le premier canal de communication en réponse à la requête de confirmation, comparer ledit code reçu avec le code de vérification et envoyer via le premier canal de communication un message de validation de transaction si lesdits codes sont identiques ou un message d’invalidation de transaction si lesdits codes sont différents.
[0019] Selon un autre mode de réalisation, l’invention propose un système de transaction bancaire comprenant au moins un serveur de transaction bancaire, un premier terminal d’un utilisateur relié à l’au moins un serveur de transaction bancaire via un premier canal de communication, et un deuxième terminal d’un titulaire d’un compte et/ou d’une carte bancaire relié à l’au moins un serveur de transaction bancaire via un deuxième canal de communication au moins logiquement distinct du premier canal de communication. Le premier terminal est configuré pour envoyer, sur demande de l’utilisateur, à l’au moins un serveur de transaction bancaire, une demande de transaction comprenant au moins un montant de la transaction, et une identification du compte et/ou de la carte bancaire. Le serveur de transaction bancaire est configuré pour, à réception de la demande de transaction, établir un code de vérification dont la longueur est fonction du montant de la transaction, déterminer le deuxième terminal en fonction de l’identification du compte bancaire à débiter, puis envoyer, d’une part, une requête de confirmation demandant le code de vérification au premier terminal via le premier canal de communication et, d’autre part, le code de vérification au deuxième terminal via le deuxième canal de communication. Le deuxième terminal est configuré pour afficher, au titulaire du compte bancaire, le code de vérification envoyé par le serveur de transaction bancaire. Le premier terminal est configuré pour renvoyer au serveur de transaction bancaire un code recopié par l’utilisateur à partir du code de vérification affiché sur le deuxième terminal. Le serveur de transaction bancaire est configuré pour, à réception du code recopié, comparer avec le code de vérification avec le code recopié et envoyer au premier terminal un message de validation de transaction si les codes sont identiques ou un message d’invalidation de transaction si les codes sont différents.
[0020] Brève Description des figures [0021] L’invention sera mieux comprise et d’autres caractéristiques et avantages de celle-ci apparaîtront à la lecture de la description suivante de modes de réalisation particuliers de l’invention, donnés à titre d’exemples illustratifs et non limitatifs, et faisant référence aux dessins annexés, parmi lesquels :
[0022] [Fig.1] montre un système de transaction bancaire à deux facteurs d’authentification,
[0023] [Fig.2] montre un système de transaction commerciale sur un réseau ouvert à deux facteurs d’authentification,
[0024] [Fig.3] illustre une transaction sur le système de la figure 1 selon l’invention,
[0025] [Fig.4] illustre une transaction sur le système de la figure 2 selon l’invention,
[0026] [Fig.5] montre un organigramme de fonctionnement d’un serveur d’authentification selon l’invention,
[0027] Description détaillée
[0028] Les figures 1 et 2 montrent deux systèmes de transaction réalisée au travers d’un réseau ouvert, tel que par exemple internet, en utilisant une authentification à deux facteurs d’authentification. Sur ces deux figures, les mêmes références correspondent aux mêmes éléments ou à des éléments similaires. Ces deux figures correspondent à des schémas de transaction à deux facteurs de sécurité tel qu’utilisés dans l’état de la technique et selon l’invention.
[0029] Par « réseau ouvert », il faut comprendre un réseau de communication permettant des interconnexions entre une ou plusieurs machines informatiques accessible à tout personne souhaitant le faire. Ce type de réseau peut être internet mais pourrait correspondre à d’autre types de réseaux dès lors que la connexion reste ouverte à tout le monde. Les réseaux ouverts ont l’avantage de faciliter une mise en relation des personnes permettant ainsi d’augmenter les possibilités de transactions commerciales entre personnes connectées audit réseau. Un inconvénient des réseaux ouverts est le risque d’interaction avec des machines appartenant à des personnes malveillantes.
[0030] La figure 1 correspond à un système de transaction bancaire permettant à un utilisateur de réaliser des opérations de transaction auprès de sa banque, tel que par exemple pour réaliser un virement bancaire ou pour réaliser un achat de titres en ligne ou tout autre type d’opération pour laquelle l’utilisateur réalise un transfert d’argent depuis son compte bancaire. Sur cette figure 1 , l’utilisateur 1 interagit avec un premier terminal 2 connecté à un réseau ouvert 3, tel que par exemple internet, afin de communiquer avec un serveur de services bancaires 4 pour réaliser une opération correspondant à une transaction bancaire c’est-à-dire un transfert d’argent depuis un compte bancaire.
[0031] Le premier terminal 2 est par exemple un ordinateur personnel fixe ou portable, une tablette ou un smartphone disposant d’une unité de traitement, d’au moins une mémoire volatile et/ou non volatile, d’une interface de communication lui permettant de se connecter au réseau ouvert 3, d’une interface homme- machine permettant de visualiser et de rentrer des informations, tel que par exemple un écran de visualisation, un écran tactile, un clavier, une souris ou autre. Parmi les programmes stockés dans sa mémoire, le premier terminal dispose d’un programme de navigation sur le réseau ouvert 3, lui permettant de se connecter sur et d’interagir avec des sites web, notamment pour consulter des pages web ou pour remplir et envoyer des formulaires correspondant à des requêtes de transaction. De manière alternative, le premier terminal 2 peut disposer d’un programme spécifique lui permettant de se connecter au travers du réseau ouvert 3 au serveur de services bancaires 4.
[0032] Le serveur de services bancaires 4 est par exemple un ordinateur disposant d’une ou plusieurs unités de traitement, d’au moins une mémoire volatile et de masse, et d’au moins une interface de communication lui permettant de se connecter au réseau ouvert 3. La mémoire de masse mémorise entre autres une base de données contenant toutes les informations relatives aux comptes bancaires des clients de la banque à laquelle il appartient. Le serveur de services bancaires 4 comporte des programmes stockés en mémoire lui permettant de mettre à disposition de terminaux connectés, au travers du réseau ouvert 3, des pages web consultables qui permettent d’interagir avec des utilisateurs via des formulaires contenus dans lesdites pages web. Les formulaires, une fois remplis et renvoyés par l’utilisateur, sont ensuite traités par l’unité de traitement pour validation. [0033] Lorsqu’une transaction est souhaitée par un utilisateur 1, celui-ci utilise le premier terminal 2 pour se connecter au serveur de services bancaires 4. Une page web est alors transmise au premier terminal 2 par le serveur de services bancaires 4. La page web peut comporter des informations à visualiser sur le premier terminal 2, ainsi que des commandes à exécuter en fonction de choix fait par l’utilisateur par l’intermédiaire de l’interface homme-machine. Parmi les choix offerts à l’utilisateur 1 , une transaction, par exemple un virement bancaire, peut être réalisée. En choisissant de réaliser un virement, un formulaire de transaction est présenté à l’utilisateur 1 , le formulaire pouvant être inclus dans la page web ou transmis par le serveur de services bancaires 4 après réception d’un message indiquant le choix de l’utilisateur 1 provenant du premier terminal 2. L’utilisateur 1 remplit alors le formulaire avec les informations nécessaires à la transaction qui peuvent comprendre l’identification du compte bancaire à créditer, l’identification du compte bancaire à débiter, le montant de la transaction. De nombreuses autres informations peuvent également être requises, telles que des identifiants redondants de l’utilisateur et/ou du compte bancaire ou de son titulaire, un secret connu uniquement de la banque et du titulaire, un identifiant de transaction ou toute autre information qui soit en relation avec la transaction. Une fois le formulaire rempli, l’utilisateur 1 envoie le formulaire rempli au serveur de services bancaires 4 via le premier terminal 2. Le formulaire peut être accompagné de l’heure et de la date d’envoi et également d’identifiants propres au premier terminal 2.
[0034] Ayant reçu le formulaire de transaction rempli, le serveur de services bancaires 4 vérifie les informations contenues dans le formulaire et notamment si la transaction demandée peut être autorisée ou non. A cet effet, le serveur de services bancaires 4 interroge sa base de données pour vérifier si le compte à débiter est toujours en service et si le crédit du compte à débiter peut permettre d’autoriser la transaction. Eventuellement, le serveur peut vérifier la justesse d’identifiants redondants ou d’informations sur le titulaire du compte bancaire. Cette première vérification correspond à un premier facteur de sécurité. Cependant, la transaction a été transmise par le réseau ouvert 3 et, malgré cette première vérification, il est possible que cette transaction provienne d’un détournement du formulaire et/ou des informations relatives au compte bancaire par un tiers malveillant.
[0035] En effet, les communications sur le réseau ouvert 3 peuvent être interceptées et rejouées éventuellement de manière modifiée. Afin de garantir un minimum de sécurité, il est connu d’encrypter les messages sensibles entre deux machines, tel que par exemple le terminal 2 et le serveur de services bancaires 4, à l’aide de clefs de sessions ou de clefs spécifiques. Cependant, tout message encrypté peut être décrypté au bout d’un certain temps, ce qui permet de récupérer un formulaire échangé et de réutiliser les informations qu’il contient. De plus, le fait que le réseau soit ouvert permet à des personnes malintentionnées de diffuser des virus sur les machines qui y sont connectées et notamment le premier terminal 2. Parmi les virus, certains peuvent intercepter les informations échangées sur l’interfaces homme-machine et les renvoyer vers une autre machine rendant également inopérante la confidentialité de messages encryptés. [0036] Afin de rajouter un niveau de sécurité, un deuxième facteur de sécurité peut être rajouté en utilisant un deuxième canal de communication pour envoyer un code à usage unique. A cet effet, le serveur de services bancaires 4 dispose d’une deuxième interface de communication apte à communiquer via le deuxième canal de communication avec un deuxième terminal 5 qui appartient à un titulaire de compte bancaire. Le deuxième terminal 5 est identifié dans la base de données du serveur de services bancaires 4 en relation avec le compte bancaire à débiter. Le deuxième terminal 5 peut être, classiquement, un téléphone mobile du titulaire du compte bancaire, mais peut également être tout autre type de dispositif connecté à un réseau de communication, tel que, par exemple, un boîtier connecté à un réseau de téléphonie mobile fourni par la banque ou encore une tablette ou un ordinateur relié à internet. L’important est que le deuxième canal de communication soit au moins logiquement distinct du premier canal de communication utilisé pour l’envoi du formulaire de transaction.
[0037] Après avoir fait la première vérification, le serveur de services bancaires 4 récupère, dans sa base de données, l’identifiant du deuxième terminal 5 pour lui envoyer un code de vérification à usage unique. L’identifiant du deuxième terminal 5 est, par exemple, un numéro de téléphone mobile et le message est, par exemple, envoyé par un message court de type SMS (de l’anglais Short Message Service). Le message peut également indiquer le montant de la transaction et/ou le bénéficiaire de la transaction, de sorte que le titulaire du compte puisse vérifier que la transaction en cours est conforme à une transaction désirée.
[0038] En parallèle, le serveur de services bancaires 4 envoie au premier terminal 2 une requête de confirmation demandant le code à usage unique. L’utilisateur 1 , s’il correspond au titulaire du compte bancaire, peut alors lire le code à usage unique sur le deuxième terminal 5 et le recopier dans un formulaire de réponse joint à la requête de confirmation afin de le renvoyer au serveur de services bancaires 4.
[0039] A réception du formulaire de réponse, le serveur de services bancaires 4 compare le code présent dans le formulaire avec le code à usage unique envoyé au deuxième terminal 5. Si les deux codes sont identiques, alors le serveur de services bancaires 4 valide la transaction et envoie un message au premier terminal 2 pour l’informer de l’acceptation de la transaction. Si les deux codes sont différents, alors la transaction est refusée et le serveur de services bancaires 4 envoie un message au premier terminal indiquant que la transaction est refusée. De manière optionnelle, le serveur de services bancaires 4 peut réitérer l’envoi d’un nouveau code de vérification à usage unique au deuxième terminal 5 et d’une requête au premier terminal 2.
[0040] La figure 2 correspond à système de transaction commerciale permettant à un utilisateur 1 de réaliser un achat sur un site marchand 6. Le site marchand 6 est un ordinateur de type serveur qui est connecté au réseau ouvert 3 afin de fournir des pages web qui proposent des produits et/ou services à des utilisateurs s’y connectant à l’aide d’un terminal approprié. L’utilisateur 1 se connecte au site marchand 6 à l’aide du premier terminal 2 via le réseau ouvert 3. Une fois un choix de produits ou services réalisé par l’utilisateur 1 , le site marchand 6 envoie un formulaire de transaction au premier terminal 2. Le formulaire de transaction est pré-rempli par le site marchand 6 avec l’identification du vendeur, de son compte bancaire et du montant de la transaction. Le formulaire de transaction est présenté à l’utilisateur 1 par le premier terminal 2, demandant à celui-ci de le compléter avec une identification de compte ou de carte bancaire. D’autres informations peuvent également être requises, telles que, par exemple, le fournisseur de la carte bancaire, le code CW (de l’anglais Cardholder Vérification Value) qui constitue un identifiant redondant de la carte, l’identification du titulaire de la carte bancaire ou toute autre information redondante qui soit en relation avec la carte ou son titulaire. Une fois le formulaire rempli, l’utilisateur 1 envoie le formulaire au site marchand 6 via le premier terminal 2. Le formulaire peut être accompagné de l’heure et de la date d’envoi et également d’identifiants propres au premier terminal 2 tel que, par exemple, son adresse sur le réseau ouvert 3.
[0041] Le site marchand 6 reçoit le formulaire et le transmet à un serveur de services acquéreurs 7 qui correspond à sa banque. Le serveur de services acquéreurs 7 est un ordinateur disposant d’une ou plusieurs unités de traitement, d’au moins une mémoire volatile et de masse, d’au moins une interface de communication lui permettant de se connecter avec le site marchand 6 et d’au moins une interface de communication pour se connecter à un réseau sécurisé dédié aux services bancaires. L’interface de communication communicant avec le site marchand 6 peut correspondre à une liaison spécifique sécurisée ou à un réseau ouvert mettant en œuvre une communication encryptée.
[0042] Le serveur de services acquéreurs 7 transmet ensuite le formulaire de transaction, via le réseau sécurisé, à un serveur de services débiteurs 4’ qui correspond à l’émetteur de la carte bancaire. Le serveur de services débiteurs 4’ est similaire au serveur de services bancaires 4. Le serveur de services débiteurs 4’ peut être le serveur de la banque du titulaire de carte ou le serveur d’un organisme émetteur de carte de crédit.
[0043] A réception du formulaire de transaction, le serveur de services débiteurs 4’ vérifie les informations contenues dans le formulaire et, notamment, si la transaction demandée peut être autorisée ou non. A cet effet, le serveur de services débiteurs 4’ interroge sa base de données pour vérifier si le compte ou la carte bancaire est toujours en service, si les éventuelles informations redondantes sont conformes avec la carte ou le compte bancaire et si le montant de la transaction correspond à un montant autorisé. Ce premier niveau de vérification de sécurité étant effectué, le serveur de services débiteurs 4’ réalise une vérification selon un deuxième niveau de sécurité similaire à celui décrit en relation avec la figure 1 avec quelques différences.
[0044] Le serveur de services débiteurs 4’ identifie dans sa base de données le deuxième terminal 5 en relation avec la carte ou le compte bancaire à débiter et un deuxième canal de communication distinct, au moins logiquement, du canal de communication avec le premier terminal 2. Le serveur de services débiteurs 4’ envoie un message comportant un code de vérification à usage unique au deuxième terminal 5. Le message peut également indiquer le montant de la transaction et/ou le bénéficiaire de la transaction, de sorte que le titulaire du compte puisse vérifier que la transaction en cours est conforme à une transaction désirée.
[0045] En parallèle, le serveur de services débiteurs 4’ envoie au premier terminal 2 une requête de confirmation demandant le code à usage unique. Cette requête peut être envoyer au premier terminal 2 par l’intermédiaire du serveur de services acquéreurs 7 et du site marchand 6 via le réseau ouvert 3 ou directement par le serveur de services débiteurs 4’ via le réseau ouvert 3. L’utilisateur 1 , s’il correspond au titulaire de la carte ou du compte bancaire peut alors lire le code à usage unique sur le deuxième terminal 5 et le recopier dans un formulaire de réponse joint à la requête de confirmation, afin de le renvoyer au serveur de services débiteurs 4’ en utilisant le même canal de communication.
[0046] A réception du formulaire de réponse, le serveur de services débiteurs 4’ compare le code présent dans le formulaire avec le code à usage unique envoyé au deuxième terminal 5. Si les deux codes sont identiques, alors le serveur de services bancaires 4 valide la transaction et envoie un message au serveur de services acquéreurs 7 qui enregistre la transaction et transmet un message de paiement validé au site marchand 6. Le site marchand 6 informe ensuite le premier terminal 2 que le paiement est accepté et délivre le service ou lance une procédure de livraison de produit(s) qui ne sera pas détaillée dans le présent document. Si les deux codes sont différents, alors la transaction est refusée et le serveur de services débiteurs 4’ envoie un message au serveur de services acquéreurs 7 qui est retransmise au site marchand 6, puis au premier terminal 2 indiquant que la transaction est refusée et donc non réalisée. De manière optionnelle, le serveur de services débiteurs 4’ peut réitérer l’envoi d’un nouveau code de vérification à usage unique au deuxième terminal 5 et d’une nouvelle requête au premier terminal 2 via l’un des chemins indiqués précédemment.
[0047] L’invention vise à améliorer les vérifications de transaction utilisant deux facteurs de sécurité telles qu’indiquées précédemment et utilisant notamment un deuxième canal de communication avec le titulaire du compte ou de la carte bancaire. A cet effet, les figures 3 et 4 illustrent des étapes de procédés de transaction réalisés selon l’invention respectivement sur les systèmes de transaction décrit en relation avec les figures 1 et 2. L’organigramme de la figure 5 détaille des étapes du procédé de vérification de transaction effectuée selon l’invention par le serveur de services bancaires 4 ou le serveur de services débiteurs 4’ au cours des échanges effectués en conformité avec la figure 3 ou la figure 4. Les étapes communes entre les figures 3, 4 et 5 portent les mêmes références et la description de la figure 5 est faite conjointement avec les descriptions des figures 3 et 4. Afin de mettre l’accent sur l’invention, les étapes préalables à un choix de transaction par l’utilisateur 1 ne sont pas détaillées sur des figures 3 et 4 qui commencent après qu’une décision de transaction, correspondant par à la réalisation d’un paiement, ait été validé par l’utilisateur 1 du premier terminal 2.
[0048] Sur la figure 3, le choix de la transaction ayant été réalisé par l’utilisateur 1, le serveur de services bancaires 4 envoie au premier terminal 2 un formulaire de transaction correspondant au choix de l’utilisateur 1 dans une première étape 301 du procédé de transaction. Dans une deuxième étape 302 du procédé de transaction, l’utilisateur 1 prend connaissance du formulaire reçu par le premier terminal 2, par exemple à l’aide d’un écran de visualisation du premier terminal 2. L’utilisateur remplit le formulaire avec les informations demandées au cours d’une troisième étape 303 du procédé de transaction, par exemple à l’aide d’un clavier du premier terminal 2. Une fois le formulaire rempli, l’utilisateur valide le formulaire pour l’envoyer.
[0049] Une quatrième étape 304 du procédé de transaction correspond à l’envoi du formulaire par le premier terminal 2 au serveur de services bancaires 4 via le réseau ouvert 3. Cette quatrième étape 304 du procédé de transaction correspond à une première étape de vérification 501 du serveur de services bancaires 4. Le serveur de services bancaires 4 reçoit un message entrant R1 arrivant par le premier canal de communication. Le message entrant R1 contient des informations d’identification ID d’un compte bancaire et d’un montant de transaction TA. Les informations d’identification ID comprennent au minimum le numéro de compte bancaire, mais peuvent comprendre des informations redondantes telles que, par exemple, un ou plusieurs éléments parmi : un mot de passe, un code PIN, une ou plusieurs informations d’identité du titulaire du compte bancaire. Les informations d’identification ID peuvent aussi comprendre des paramètres propres à la transaction, tels que par exemple l’heure, la date ou le lieu où se situe le premier terminal 2 ainsi qu’un identifiant dudit premier terminal 2.
[0050] Dans une deuxième étape de vérification 502, le serveur de services bancaires 4 vérifie que le compte bancaire existe et que celui-ci n’est pas bloqué. De manière optionnelle, d’autres vérifications peuvent être réalisées pour vérifier que d’éventuelles informations redondantes sont bien conformes avec celles correspondant au compte bancaire. En outre, le serveur de services bancaires 4 peut également vérifier que le montant à débiter est conforme avec un débit autorisé du compte bancaire.
[0051] Cette vérification préliminaire de compte bancaire effectuée, le serveur de services bancaires 4 calcule ensuite une longueur L de code de vérification dans une troisième étape de vérification 503 où la longueur L correspond à un nombre de digits dudit code. De manière préférée, la longueur L est déterminée en fonction du montant de la transaction TA, de sorte que le code de vérification prenne en compte le montant de la transaction comme facteur de risque. A titre d’exemple simple, la formule suivante peut être utilisée :
[0052] [Math 1]
[0053] L = A * TA + B
[0054] Les paramètres A et B peuvent être fixés arbitrairement par la banque en fonction d’une acceptation de risque. Si A= 0,1 et B = 2 avec le résultat L arrondi à l’entier le plus proche, un paiement d’un euro aura pour résultat un code L de deux digits très simples à recopier pour une somme représentant un risque minime. Avec, ces mêmes paramètres un paiement de dix euros correspond à un code à trois digits et un paiement de cent euros correspond un code de douze digits.
[0055] De manière préférée, des informations d’identification ID peuvent être prises en compte dans la détermination du nombre de digit. A titre d’exemple, les paramètres A et B peuvent être mémorisés dans la base de données du serveur de services bancaires 4 et accessibles à l’aide de l’identification du numéro de compte. Ainsi, il est possible de définir les paramètres A et B en fonction d’un risque accepté par l’utilisateur ou par son gestionnaire de compte, B correspondant à un nombre de digits minimal et A étant déterminé en fonction d’un montant pour lequel un risque financier paraît acceptable. Afin d’éviter d’avoir des codes trop longs, il est également possible de fixer un nombre de digits maximal.
[0056] En variante, il est également possible d’avoir une croissance non linéaire du nombre de digits afin d’éviter d’avoir à limiter le nombre de digits. A titre d’exemple, la formule suivante peut également être utilisée :
[0057] [Math 2]
[0058] L = A * log10(TA ) + B
[0059] L’utilisation d’une fonction logarithmique permet d’avoir une croissance de la longueur L du code de vérification proportionnelle au nombre de digits du montant de la transaction. A titre d’exemple, si A = 0,3 et B = 3, un montant de moins de dix euros produit une longueur de code de vérification de trois digits, un montant de cent euros correspond à une longueur de code de six digits et un montant de mille euros correspond à une longueur de code de neuf digits.
[0060] La longueur L de code de vérification étant déterminée, le serveur de services bancaires 4 calcule ensuite un code de vérification AC lors d’une quatrième étape de vérification 504. Le code de vérification AC peut être généré de différentes manières, de préférence en utilisant un nombre aléatoire ou pseudo aléatoire généré par l’unité de traitement du serveur de services bancaires 4. A titre d’exemple simple, la formule suivante peut être utilisée pour déterminer le code de vérification :
[0061] [Math 3]
[0062] AC = Seed mod L
[0063] avec Seed correspondant à un nombre aléatoire ou pseudo aléatoire généré par l’unité de traitement du serveur de services bancaires 4, mod à la fonction modulo et L à la longueur de code calculée lors de la troisième étape de vérification 503. De très nombreuses variantes sont possibles en intégrant le montant de la transaction TA et une ou plusieurs informations d’identification de la transaction ID, tel que par exemple l’heure ou la date de la transaction. A titre d’exemple, la formule suivante peut également être utilisée :
[0064] [Math 4]
[0065] AC = H(Seed,TA, ID) mod L
[0066] avec H correspondant à une fonction de hachage cryptographique, par exemple un SHA-3, réalisée sur la concaténation du nombre aléatoire Seed, du montant de la transaction TA et d’une ou plusieurs informations d’identification ID.
[0067] Le code de vérification AC étant calculé, une cinquième étape de vérification 505 est réalisée par le serveur de services bancaires 4. La cinquième étape de vérification 505 consiste à envoyer un message sortant S1 , par le premier canal de communication, à destination du premier terminal 2, le message sortant contenant une requête Req demandant à l’utilisateur 1 du premier terminal 2 de renvoyer un code de vérification dans un formulaire de réponse.
[0068] En parallèle avec la cinquième étape de vérification 505, c’est-à-dire avant ou après cette cinquième étape 505, le serveur de services bancaires 4 effectue une sixième étape de vérification 506. La sixième étape de vérification 506 consiste à envoyer un message sortant S2 par le deuxième canal de communication à destination du deuxième terminal 5. Le deuxième terminal 5 est, préalablement à l’envoi, identifié dans la base de données du serveur de services bancaires 4 en association avec le compte bancaire à débiter. Le message sortant S2 contient le code de vérification AC calculé lors de la quatrième étape de vérification.
[0069] La cinquième étape de vérification 505 correspond à une cinquième étape 305 du procédé de transaction et la sixième étape de vérification 506 correspond à une sixième étape 306 du procédé de transaction.
[0070] Le premier terminal 2 ayant reçu la requête Req, celle-ci est présentée à l’utilisateur 1 au cours d’une septième étape 307 du procédé de transaction, le formulaire de réponse étant à remplir par l’utilisateur 1. Parallèlement à la septième étape 307, c’est-à-dire avant ou après cette septième étape 307, une huitième étape 308 du procédé de transaction consiste en la présentation du code de vérification AC par le deuxième terminal 5 à l’utilisateur 1.
[0071] L’utilisateur 1, disposant du code de vérification AC, remplit le formulaire de réponse en recopiant le code de vérification AC dans le formulaire au cours d’une neuvième étape 309 du procédé de transaction. Le code de vérification recopié AC’ est envoyé au serveur de services bancaires 4 dans une dixième étape 310 du procédé de transaction. La dixième étape 310 du procédé de transaction correspond à une septième étape de vérification 507 réalisée par le serveur de services bancaires 4. Le serveur de services bancaires 4 reçoit un message entrant R1 arrivant du premier canal de communication ayant pour contenu le code recopié AC’. Une huitième étape de vérification 508 consiste ensuite à comparer le code recopié AC’ avec le code de vérification AC calculé lors de la quatrième étape de vérification 504.
[0072] Si le code de vérification recopié AC’ est identique au code de vérification AC, alors le serveur de services bancaires 4 effectue une neuvième étape de vérification 509 au cours de laquelle il valide et enregistre la réalisation de la transaction. Puis, une dixième étape de vérification 510 est réalisée pour envoyer un message sortant S1 par le premier canal de communication à destination du premier terminal 2 pour indiquer que la transaction est réalisée.
[0073] Si le code de vérification recopié AC’ n’est pas identique au code de vérification AC, alors le serveur de services bancaires 4 effectue une onzième étape 511 au cours de laquelle il annule la transaction. Si, au cours de la deuxième étape de vérification 502, le serveur de services bancaires 4 n’a pas trouvé le compte bancaire ou a trouvé le compte bancaire mais que celui-ci est bloqué ou encore si d’autres vérifications ont montré que d’éventuelles informations redondantes ne sont pas conformes avec celles correspondant au compte bancaire, la deuxième étape de vérification 502 peut aboutir directement à la onzième étape de vérification 511 et également annuler la transaction. Après la onzième étape de vérification 511 , une douzième étape de vérification 512 est réalisée pour envoyer en message sortant S1 par le premier canal de communication à destination du premier terminal 2 pour indiquer que la transaction est annulée.
[0074] La dixième étape de vérification 510 ou la douzième étape de vérification 512 correspond à une onzième étape 311 du procédé de transaction dans laquelle le premier terminal 2 reçoit le message sortant S1 pour l’afficher à l’utilisateur 1 au cours d’une douzième étape 312 du procédé de transaction. Ainsi, l’utilisateur 1 est informé de la réalisation ou de l’annulation de la transaction demandée.
[0075] La figure 4 divulgue un procédé de transaction réalisé à partir du site marchand 6. Après que l’utilisateur ait choisi de faire un achat, le site marchand 6 envoie au premier terminal 2 un formulaire de transaction dans une première étape 401 du procédé de transaction. Dans une deuxième étape 402 du procédé de transaction, l’utilisateur 1 prend connaissance du formulaire reçu par le premier terminal 2. L’utilisateur 1 remplit le formulaire avec les informations demandées au cours d’une troisième étape 403 du procédé de transaction. Le formulaire contient des informations d’identification ID d’une carte ou d’un compte bancaire et d’un montant de transaction TA. Les informations d’identification ID comprennent au minimum le numéro de carte ou de compte bancaire mais peuvent comprendre des informations redondantes telles que, par exemple, un ou plusieurs éléments parmi : un mot de passe, un code PIN, un code CW, une ou plusieurs informations d’identité du titulaire du compte. Les informations d’identification ID peuvent aussi comprendre des paramètres propres à la transaction tels que, par exemple, l’heure, la date ou le lieu où se situe le premier terminal 2 ou encore un identifiant dudit premier terminal 2. Une fois le formulaire rempli, l’utilisateur 1 valide le formulaire pour l’envoyer. [0076] Une quatrième étape 404 du procédé de transaction correspond à l’envoi du formulaire par le premier terminal 2 au site marchand 6 via le réseau ouvert 3. Le site marchand 6 retransmet le formulaire au serveur de services acquéreurs 7 au cours d’une cinquième étape 405 du procédé de transaction. A partir des informations d’identification ID de la carte ou du compte bancaire, le serveur de services acquéreurs 7 détermine un serveur de services débiteurs 4’ correspondant, afin de lui retransmettre le formulaire au cours d’une sixième étape 406 du procédé de transaction.
[0077] Cette sixième étape 406 du procédé de transaction correspond à la première étape de vérification 501 , réalisée par le serveur de services débiteurs 4’, correspondant à la réception du message entrant R1 arrivant du premier canal de communication. Le serveur de services débiteurs 4’ réalise ensuite la deuxième étape de vérification 502, afin de vérifier que le compte ou la carte bancaire existe et que celui-ci ou celle-ci n’est pas bloqué. De manière optionnelle, d’autres vérifications peuvent être réalisées pour vérifier que d’éventuelles informations redondantes sont bien conformes à celles correspondant au compte ou à la carte bancaire. En outre, le serveur de services débiteurs 4’ peut également vérifier que le montant à débiter est conforme avec un débit autorisé du compte ou de la carte bancaire.
[0078] Le serveur de services débiteurs 4’ réalise la troisième étape de vérification 503 et calcule une longueur L de code de vérification AC correspondant à un nombre de digits dudit code. La longueur L est déterminée en fonction du montant de la transaction TA de sorte que le code de vérification AC prenne en compte le montant de la transaction comme facteur de risque comme précédemment décrit.
[0079] De plus, la transaction étant réalisée sur un site marchand et non sur un serveur bancaire, le risque se trouve être plus important. La longueur L du code de vérification peut également intégrer d’autres facteurs de risque tels qu’une heure de transaction et/ou un nombre de transactions effectuées récemment. A titre d’exemple, une telle intégration peut se traduire par la formule suivante :
[0080] [Math 5] [0081] L = A * log2(Nb) * R(T) * log10(TA ) + B
[0082] avec Nb représentant le nombre de transactions effectuées dans les dernières vingt-quatre heures avec le même numéro de compte ou la même carte bancaire, T représentant l’heure de la transaction et R(T) étant un coefficient de risque dépendant de l’heure T, le coefficient R(T) étant par exemple lu dans une table de correspondance réalisée à partir de statistiques sur l’heure de réalisation de transactions frauduleuses.
[0083] Le serveur de services débiteurs 4’ calcule ensuite le code de vérification AC lors de la quatrième étape de vérification 504 comme précédemment décrit. Les cinquième et sixième étapes de vérification 505 et 506 sont ensuite réalisées en parallèle. La cinquième étape de vérification 505 consiste à envoyer un message sortant S1 par le premier canal de communication à destination du premier terminal 2 qui contient une requête de confirmation Req demandant à l’utilisateur 1 du premier terminal 2 de renvoyer un code de vérification dans un formulaire de réponse. La sixième étape de vérification 506 consiste à envoyer un message sortant S2 par le deuxième canal de communication, à destination du deuxième terminal 5, le deuxième terminal 5 ayant été préalablement identifié à partir de la base de données du serveur de services débiteurs 4’ en association avec le compte ou la carte bancaire à débiter. Le message sortant S2 contient le code de vérification AC calculé lors de la quatrième étape de vérification 504.
[0084] La cinquième étape de vérification 505 correspond à une septième étape 407 du procédé de transaction. Au cours de la septième étape 407, le serveur de services débiteurs 4’ transfère un message sortant contenant la requête S1(Req) au serveur de services acquéreurs 7. Le serveur de services acquéreurs 7 transfère ce message au site marchand 6 au cours d’une huitième étape 408 du procédé de transaction. Le site marchand 6 retransmet ensuite la requête au premier terminal 2 dans une neuvième étape 409 du procédé de transaction.
[0085] La sixième étape de vérification 506 correspond à une dixième étape 410 du procédé de transaction au cours de laquelle le deuxième terminal 5 reçoit le code de vérification AC. [0086] Le premier terminal 2 ayant reçu la requête Req, celle-ci est présentée à l’utilisateur 1 au cours d’une onzième étape 411 du procédé de transaction, le formulaire de réponse étant à remplir par l’utilisateur 1. Parallèlement à la onzième étape 411 , une douzième étape 412 du procédé de transaction consiste en la présentation du code de vérification AC, par le deuxième terminal 5, à l’utilisateur 1.
[0087] L’utilisateur 1 , disposant du code de vérification AC, remplit le formulaire de réponse en recopiant le code de vérification AC dans le formulaire de réponse au cours d’une treizième étape 413 du procédé de transaction. Le code de vérification recopié AC’ est envoyé au site marchand 6 dans une quatorzième étape 414 du procédé de transaction. Au cours d’une quinzième étape 415 du procédé de transaction, le site marchand 6 retransmet le formulaire de réponse au serveur de services acquéreurs 7. Dans une seizième étape 416 du procédé de transaction, le serveur de services acquéreurs 7 transmet le formulaire rempli au serveur de services débiteurs 4’.
[0088] La seizième étape 416 du procédé de transaction correspond à la septième étape de vérification 507 réalisée par le serveur de services débiteurs 4’. Le serveur de services débiteurs 4’ reçoit un message entrant R1 arrivant par le premier canal, ayant pour contenu le code recopié AC’. Au cours de la huitième étape de vérification 508, le serveur de services débiteurs 4’ compare le code recopié AC’ avec le code de vérification AC calculé lors de la quatrième étape de vérification 504.
[0089] Si le code de vérification recopié AC’ est identique au code de vérification AC, alors le serveur de services débiteurs 4’ effectue la neuvième étape 509 au cours de laquelle il valide et enregistre la réalisation de la transaction. Puis, la dixième étape de vérification 510 est réalisée pour envoyer un message sortant S1 par le premier canal de communication, à destination du premier terminal 2, pour indiquer que la transaction est réalisée.
[0090] Si le code de vérification recopié AC’ n’est pas identique au code de vérification AC, alors le serveur de services débiteurs 4’ effectue la onzième étape 511 au cours de laquelle il annule la transaction. Si, au cours de la deuxième étape de vérification 502, le serveur de services débiteurs 4’ a constaté que le compte ou la carte bancaire est bloqué ou encore si d’autres vérifications ont montré que d’éventuelles informations redondantes ne sont pas conformes avec celles correspondant au compte ou à la carte bancaire, la deuxième étape de vérification 502 peut aboutir directement à la onzième étape de vérification 511 et également annuler la transaction. Après la onzième étape de vérification 511 , une douzième étape de vérification 512 est réalisée pour envoyer un message sortant S1 , par le premier canal de communication, à destination du premier terminal 2 pour indiquer que la transaction est annulée.
[0091] La dixième étape de vérification 510 ou la douzième étape de vérification 512 correspondent à une dix-septième étape 417 du procédé de transaction dans laquelle le serveur de services acquéreurs 7 reçoit le message sortant S1. Le serveur de services acquéreurs 7 enregistre la réalisation ou l’annulation de la transaction et transmet le message sortant au site marchand 6 au cours d’une dix-huitième étape 418 du procédé de transaction. Le site marchand 6 constate la validation ou l’annulation de la transaction. Si la transaction est validée, le site marchand 6 délivre le service ou déclenche la livraison du produit acheté. Au cours d’une dix-neuvième étape 419, le site marchand 6 envoie un message de confirmation ou d’annulation de transaction au premier terminal 2. Le premier terminal 2 affiche le message de confirmation à l’utilisateur 1 au cours d’une vingtième étape 420 du procédé de transaction. Ainsi, l’utilisateur 1 est informé de la réalisation ou de l’annulation de l’achat effectué.
[0092] De nombreuses variantes de réalisation sont possibles tout en restant en conformité avec le procédé de vérification faisant l’objet de l’invention. A titre d’exemple, les septième à neuvième étapes 407 à 409 du procédé de transaction décrit en relation avec la figure 4 peuvent être remplacées par une première étape alternative 421 qui transmet directement la requête de code de confirmation du serveur de services débiteurs 4’ au premier terminal 2 via le réseau ouvert 3. Egalement, une deuxième étape alternative 422 peut remplacer les quatorzième à seizième étapes 414 à 416 du procédé de transaction pour transmettre directement le code de vérification recopié AC’ du premier terminal 2 au serveur de services débiteurs 4’. [0093] Dans le présent document, le premier terminal 2 est un ordinateur connecté à internet et le deuxième terminal 5 est un téléphone mobile. Comme indiqué précédemment dans la description, les premier et deuxième terminaux 2 et 5 peuvent être n’importe quel type d’appareil connecté qui puisse échanger des données avec un serveur distant. Selon une variante, les premier et deuxième terminaux 2 et 5 peuvent être un seul et même terminal physique. L’important est que les premier et deuxième canaux de communication soient séparés au moins logiquement l’un de l’autre de sorte qu’une interception malveillante du premier canal n’entraine pas automatiquement une interception malveillante du deuxième canal.
[0094] A titre d’exemple, les premier et deuxième terminaux peuvent être un seul et même ordinateur personnel avec un premier canal de communication comprenant un logiciel de navigation sur internet et un deuxième canal de communication comprenant un logiciel de messagerie, l’identification du deuxième canal de communication se faisant à l’aide d’une adresse de courriel. Dans cet exemple, les premier et deuxième canaux de communication sont logiquement distincts l’un de l’autre, bien que la connexion physique des terminaux utilise une même interface de communication à savoir une même carte de connexion au réseau. Cependant, le code de vérification envoyé par le deuxième canal n’est pas directement accessible par le logiciel de navigation et il est nécessaire que l’utilisateur agisse sur une interface homme-machine de l’ordinateur personnel pour visualiser et recopier ledit code. Ainsi, seul un logiciel interceptant les actions réalisées sur l’interface homme-machine peut intercepter le code de vérification. Or, ce type d’interception peut également être réalisé lorsque les deux canaux de communication sont physiquement distincts et par conséquent la différentiation logique constitue un même niveau de sécurité qu’une différentiation physique des canaux de communication.
[0095] En référence aux figures 2 et 4, il est décrit un serveur de services débiteurs 4’ et un serveur de services acquéreurs 7. Typiquement, une transaction électronique est réalisée entre deux comptes bancaires appartenant à deux titulaires différents qui disposent de deux banques différentes ayant chacune leur serveur. Cependant, il est possible que le vendeur et l’acheteur dispose d’un compte bancaire dans une même banque. Dans ce cas, les serveurs de services débiteurs 4’ et acquéreurs 7 ne forment qu’un seul et même serveur, ce qui permet de réduire le nombre d’échanges.
[0096] A l’inverse, un ou plusieurs prestataires de services intermédiaires peuvent également être interposés entre les serveurs de services débiteurs 4’ et acquéreurs 7. C’est notamment le cas lorsque des cartes de crédit sont utilisées. La liaison n’est pas faite directement de banque à banque, mais passe par un fournisseur de cartes qui peut se substituer à la banque du titulaire de carte ou simplement servir de relais intermédiaire lors d’une transaction en ligne. [0097] De même, les serveurs de services bancaires 4, débiteurs 4’ et acquéreurs 7 peuvent être des serveurs distribués. Vu le volume de données bancaire et le nombre de requêtes de transaction, plusieurs ordinateurs indépendants et reliés en réseau peuvent assurer le rôle de chacun des serveurs de services bancaires 4, débiteurs 4’ et acquéreurs 7. Chaque ordinateur constituant l’un des serveurs peut effectuer la totalité des opérations d’une transaction ou seulement une partie, les différentes opérations de transaction étant réalisée sur différents ordinateurs.

Claims

Revendications
[Revendication 1] procédé d’authentification de transaction utilisant deux canaux de communication de données pour un utilisateur (1) utilisant un premier terminal (2) relié à au moins un serveur de transaction bancaire (4, 4’) via un premier canal de communication et un deuxième terminal (5) relié à l’au moins un serveur de transaction bancaire (4, 4’) via un deuxième canal de communication au moins logiquement distinct du premier canal de communication, caractérisé en ce que le procédé comporte :
- une première étape (304, 404, 405, 406, 501) au cours de laquelle le premier terminal (2) envoie à l’au moins un serveur de transaction bancaire (4, 4’) des informations de transaction comprenant au moins un montant de la transaction (TA), et une identification (ID) d’un compte et/ou d’une carte bancaire à débiter,
- une deuxième étape (502 à 506) au cours de laquelle le serveur de transaction bancaire (4, 4’) établit un code de vérification (AC) dont une longueur (L) est fonction du montant de la transaction (TA), détermine le deuxième terminal en fonction de l’identification (ID) du compte et/ou de la carte bancaire à débiter, puis envoie, d’une part, une requête de confirmation (505) demandant le code de vérification au premier terminal (2) via le premier canal de communication et, d’autre part, le code de vérification (506) au deuxième terminal (5) via le deuxième canal de communication,
- une troisième étape (307, 308, 309, 411, 412, 413) au cours de laquelle l’utilisateur (1) copie le code de vérification (AC) reçu sur le deuxième terminal (5) dans la requête de confirmation reçue par le premier terminal (2) et renvoie (309, 413) ladite requête ainsi remplie avec le code recopié (AC’) au serveur de transaction bancaire (4, 4’) à l’aide du premier terminal (2) via le premier canal de communication,
- une quatrième étape (507 à 512) au cours de laquelle le serveur de transaction bancaire (4, 4’) reçoit (507) du premier terminal (2) le code recopié (AC’), et compare (508) le code de vérification (AC) avec le code recopié (AC’) et envoie (510, 512) au premier terminal (2) un message de validation de transaction si les codes sont identiques ou un message d’invalidation de transaction si les codes sont différents.
[Revendication 2] Procédé selon la revendication précédente, dans lequel les informations de transaction comprennent en outre des informations d’identification du titulaire du compte et au moins une information redondante liée à l’identification du compte bancaire à débiter, dans laquelle, la deuxième étape (502 à 506) comporte une étape préliminaire (502) qui vérifie une concordance entre l’identification du compte bancaire à débiter, les informations d’identification du titulaire et la au moins une information redondante et dans laquelle la deuxième étape n’est réalisée que si la concordance est établie.
[Revendication 3] Procédé selon l’une des revendications précédentes dans lequel la longueur (L) du code de vérification (AC) dépend en outre d’un facteur de risque déterminé à l’aide d’un ou plusieurs paramètres compris parmi : l’heure de la transaction, la date de la transaction, des informations relatives au titulaire de la carte, le nombre de transactions effectuées dans une période prédéterminée précédant la transaction.
[Revendication 4] Procédé selon l’une des revendications précédentes dans lequel la longueur (L) du code de vérification (AC) croît lorsque le montant (TA) de la transaction croît.
[Revendication 5] Procédé selon l’une des revendications précédentes dans lequel la longueur (L) du code de vérification (AC) est comprise entre une valeur minimale et une valeur maximale.
[Revendication 6] Serveur de transaction bancaire (4, 4’) comprenant une unité de traitement, une mémoire de programmes, au moins une interface de communication apte à communiquer via un premier canal de communication et via un deuxième canal de communication au moins logiquement distinct du premier canal de communication caractérisé en que la mémoire de programme comporte des instructions coopérant avec l’unité de traitement de sorte que le serveur soit configurer pour :
- à réception (501) depuis le premier canal de communication d’une demande de transaction comprenant au moins un montant de la transaction (TA) et une identification (ID) d’un compte bancaire à débiter, calculer (503) une longueur (L) d’un code de vérification (AC) en fonction du montant de la transaction (TA), déterminer le code de vérification (AC) à partir de la longueur (L) de code calculée, déterminer un deuxième canal de communication en fonction de l’identification (ID) du compte bancaire à débiter, envoyer (505) une requête (Req) de confirmation demandant le code de vérification via le premier canal de communication, et envoyer (506) le code de vérification (AC) via le deuxième canal de communication,
- à réception (507) d’un code reçu (AC’) via le premier canal de communication en réponse à la requête de confirmation, comparer ledit code reçu (AC’) avec le code de vérification (AC) et envoyer via le premier canal de communication un message de validation (510) de transaction si lesdits codes sont identiques ou un message d’invalidation (512) de transaction si lesdits codes sont différents.
[Revendication 7] Système de transaction bancaire comprenant au moins un serveur de transaction bancaire (4, 4’), un premier terminal (2) d’un utilisateur (1) relié à l’au moins un serveur de transaction bancaire (4,4’) via un premier canal de communication, et un deuxième terminal (5) d’un titulaire d’un compte et/ou d’une carte bancaire relié à l’au moins un serveur de transaction bancaire (4, 4’) via un deuxième canal de communication au moins logiquement distinct du premier canal de communication caractérisé en ce que :
- le premier terminal (2) est configuré pour envoyer (304, 404, 405, 406), sur demande de l’utilisateur (1), à l’au moins un serveur de transaction bancaire (4, 4’), une demande de transaction comprenant au moins un montant de la transaction (TA), et une identification (ID) du compte et/ou de la carte bancaire,
- le serveur de transaction bancaire (4, 4’) est configuré pour, à réception (501) de la demande de transaction, établir (503, 504) un code de vérification
(AC) dont la longueur (L) est fonction du montant de la transaction (TA), déterminer le deuxième terminal (5) en fonction de l’identification du compte bancaire à débiter, puis envoyer, d’une part, une requête (505) de confirmation demandant le code de vérification au premier terminal (2) via le premier canal de communication et, d’autre part, le code de vérification (506) au deuxième terminal (5) via le deuxième canal de communication
- le deuxième terminal (5) est configuré pour afficher, au titulaire (1) du compte bancaire, le code de vérification envoyé par le serveur de transaction bancaire (4, 4’), - le premier terminal (2) est configuré pour renvoyer (309, 413) au serveur de transaction bancaire (4, 4’) un code recopié (AC’) par l’utilisateur (1) à partir du code de vérification (AC) affiché sur le deuxième terminal (5),
- le serveur de transaction bancaire (4, 4’) est configuré pour, à réception (507) du code recopié (AC’), comparer (508) avec le code de vérification (AC) avec le code recopié (AC’) et envoyer au premier terminal un message de validation (510) de transaction si les codes sont identiques ou un message d’invalidation (512) de transaction si les codes sont différents.
EP20845185.6A 2019-12-13 2020-12-11 Procede, serveur et systeme d'authentification de transaction utilisant deux canaux de communication Pending EP4074005A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1914346A FR3104760B1 (fr) 2019-12-13 2019-12-13 Procede, serveur et systeme d’authentification de transaction utilisant deux canaux de communication
PCT/FR2020/052398 WO2021116627A1 (fr) 2019-12-13 2020-12-11 Procede, serveur et systeme d'authentification de transaction utilisant deux canaux de communication

Publications (1)

Publication Number Publication Date
EP4074005A1 true EP4074005A1 (fr) 2022-10-19

Family

ID=70228146

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20845185.6A Pending EP4074005A1 (fr) 2019-12-13 2020-12-11 Procede, serveur et systeme d'authentification de transaction utilisant deux canaux de communication

Country Status (5)

Country Link
US (1) US20230009385A1 (fr)
EP (1) EP4074005A1 (fr)
CA (1) CA3161325A1 (fr)
FR (1) FR3104760B1 (fr)
WO (1) WO2021116627A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220217136A1 (en) * 2021-01-04 2022-07-07 Bank Of America Corporation Identity verification through multisystem cooperation

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SK5232001A3 (en) * 2001-04-18 2002-03-05 Blue Orange S R O Method of safety transactions by means of public networks
WO2005114886A2 (fr) * 2004-05-21 2005-12-01 Rsa Security Inc. Systeme et procede permettant de reduire la fraude
US7657489B2 (en) * 2006-01-18 2010-02-02 Mocapay, Inc. Systems and method for secure wireless payment transactions
US20090307140A1 (en) * 2008-06-06 2009-12-10 Upendra Mardikar Mobile device over-the-air (ota) registration and point-of-sale (pos) payment
US8661258B2 (en) * 2009-10-23 2014-02-25 Vasco Data Security, Inc. Compact security device with transaction risk level approval capability
US9800574B2 (en) * 2013-12-31 2017-10-24 Vasco Data Security, Inc. Method and apparatus for providing client-side score-based authentication
US11151568B2 (en) * 2018-05-09 2021-10-19 Capital One Services, Llc Real-time selection of authentication procedures based on risk assessment

Also Published As

Publication number Publication date
WO2021116627A1 (fr) 2021-06-17
US20230009385A1 (en) 2023-01-12
CA3161325A1 (fr) 2021-06-17
FR3104760B1 (fr) 2023-05-26
FR3104760A1 (fr) 2021-06-18

Similar Documents

Publication Publication Date Title
US20220129866A1 (en) Method and system for a secure registration
US6847953B2 (en) Process and method for secure online transactions with calculated risk and against fraud
US8738457B2 (en) Methods of facilitating merchant transactions using a computerized system including a set of titles
US6529885B1 (en) Methods and systems for carrying out directory-authenticated electronic transactions including contingency-dependent payments via secure electronic bank drafts
EP1153376B1 (fr) Procede de telepaiement et systeme pour la mise en oeuvre de ce procede
US20070162300A1 (en) Methods of facilitating contact management using a computerized system including a set of titles
US6941282B1 (en) Methods and systems for carrying out directory-authenticated electronic transactions including contingency-dependent payments via secure electronic bank drafts
JP2004511028A (ja) 情報を安全に収集、格納、及び送信する方法及びシステム
FR2733068A1 (fr) Procede de paiement electronique permettant d'effectuer des transactions liees a l'achat de biens sur un reseau informatique
EP2619941A1 (fr) Procede, serveur et systeme d'authentification d'une personne
WO2021116627A1 (fr) Procede, serveur et systeme d'authentification de transaction utilisant deux canaux de communication
WO2001073706A1 (fr) Systeme de paiement permettant de ne pas divulguer d'information bancaire sur le reseau public et quasi-public
EP1978479A1 (fr) Cryptogramme dynamique
FR2823882A1 (fr) Procede et systeme de validation de paiement
FR3008518A1 (fr) Méthode de réalisation, terminal et programme d'ordinateur correspondant.
US20230394471A1 (en) Facilitating cryptocurrency-based transactions with time constraint
WO2023274979A1 (fr) Procédé d'authentification de transaction utilisant deux canaux de communication
EP4348459A1 (fr) Procédé de traitement d'une transaction, dispositif et programme correspondant
WO2005088568A1 (fr) Procede et systeme de micropaiement
FR3138541A1 (fr) Procédé de création d’un avatar d’un utilisateur
FR2831361A1 (fr) Jeton informatique
FR2830100A1 (fr) Systeme de paiement securise entre particuliers permettant de ne pas divulguer d'information bancaire sur le reseau public et quasi public
FR2912579A1 (fr) Procede de transfert securise via un reseau de communication d'un flux monetaire, systeme de transfert et produit programme correspondants
FR2814261A1 (fr) Billet electronique de valeur fiduciaire, protocole de paiement d'achats par commerce electronique et systeme serveur correspondant
FR2808144A1 (fr) Procede et systeme de paiement electronique

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20220705

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)