WO2023274979A1

WO2023274979A1 - Transaction authentication method using two communication channels

Info

Publication number: WO2023274979A1
Application number: PCT/EP2022/067612
Authority: WO
Inventors: Michel Leger; Marc Beunardeau; Aisling CONNOLLY; Rémi GERAUD; David Naccache; Elena Trichina
Original assignee: Banks And Acquirers International Holding
Priority date: 2021-06-28
Filing date: 2022-06-27
Publication date: 2023-01-05
Also published as: FR3124624B1; FR3124624A1

Abstract

The invention relates to a dual-factor authentication method (100). A terminal is connected to a bank transaction server via first and second communication channels that are logically separate from one another. It implements the following steps: - the server determines a verification code for the transaction and sends a message containing the code to the terminal via the second channel, - the server sends a request asking the terminal to return the code via the first channel to the terminal via the first channel, - the terminal receives the request over the first channel, - the terminal automatically detects (102) receipt of the message over the second channel and automatically identifies (104) the verification code for the transaction in the message, - the terminal returns (108) a response to the request, comprising the identified code, to the server via the first channel.

Description

Title of the invention: Transaction authentication method using two communication channels The present invention relates to a transaction authentication method using two communication channels. 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 covered by this document concern payment transactions carried out online. An online payment is made when goods or services are sold or purchased, whether by businesses, households, individuals, governments or other organizations, public or private, on interconnected networks of computers, such as the internet. Goods and services are ordered on these networks, but payment and final delivery of the good or service can be done online or offline. In addition, bank customers regularly carry out wire transfer payment transactions using Internet banking. More and more consumers are using e-commerce to search for and purchase goods and services over electronic networks such as, for example, the Internet. Payment is usually made by entering a debit and/or credit or bank card number or other financial information into the respective fields of a form on the merchant's website. line. Transactions may also be made using online or mobile payment service providers, such as those offered by, for example, PayPal, Inc., of San Jose, California. To ensure better security, electronic payment systems often use agglomerated security solutions such as those identified by the marks "3Dsecure", "Verified by Visa", or other. Such payment services and payment security solutions can make transactions easier and/or safer for the parties involved. Buying with the help of a payment service provider from a portable mobile terminal is one of the main reasons why online and mobile shopping is growing very quickly.

Traditional online payment systems expose users to security risks. For example, typing numbers from a credit card ID into a field of an online payment form exposes a user to the theft of that number by a third party looking at their screen, by a keystroke logging computer virus. , etc. Although the storage of credit card numbers by an online retailer can avoid requiring the user to manually enter information with each purchase during the payment transaction, it exposes the online retailer to its own security risks and responsibilities. Credit card information can also be captured by simple means, such as taking a photo of an inadvertently exposed card, not to mention that credit cards can be lost or stolen, allowing a person malicious to misuse it.

In order to improve the security of electronic transactions, modern electronic payment systems often use a so-called two-factor authentication procedure, hereinafter referred to as 2FA. Early 2FA procedures used additional passwords. On bank payment terminals, this has resulted in the use of a PIN code (Personal Identification Number) verified on the chip of a bank card. For Internet banking transactions, one of the oldest forms of security two-factor authentication, one method is to issue cardholder customers, along with the bank card, a numbered list of transaction authentication numbers , commonly called TAN (from the English "Transaction Authentication Numbers"), so that, during a transaction, the bank can ask the user to manually enter an authentication number corresponding to a number chosen randomly from the list TAN. The development of transactions on the Internet and the proliferation of mobile phones has led to the generalization of a 2FA procedure using the mobile phone as a second communication channel to send an authentication code, such as a one-time password or OTP (of English "One-Time Password"), by short message or SMS (English "Short Message Service"). Alternatively, the authentication code can be transmitted by email.

However, the use of a short message has a drawback when the transaction is carried out entirely on an intelligent telephony device of the smartphone or ordiphone type. Indeed, the user cannot view the short message when entering the authentication code on the internet browser because he cannot view this message on his screen simultaneously in his messaging system and the transaction web page, he must switch from one application to another. The user must therefore memorize the authentication code, which constitutes a source of an input error which can cause the user to abandon the transaction. To avoid a memorization error, the user can copy the character string corresponding to the authentication code from the short message and then copy it again (or "paste") into the browser. However, the use of "copy and paste" functions on a smartphone is not mastered by all users and can sometimes be confusing. The use of an e-mail has the same drawbacks when the terminal is a telephone or a tablet which does not make it possible to simultaneously view the messaging application and Internet browsing. In addition, a personal computer user who is not familiar with computer applications may also find it difficult to copy the code from his e-mail to an Internet browser.

The present invention aims to remedy the inconveniences mentioned above when using an authentication code in a procedure with two security factors when the transaction is carried out on the terminal which receives the message containing the authentication code. To this end, the subject of the invention is a method for the two-factor authentication of a banking transaction, in which, a terminal of a user being connected to at least one banking transaction server via first and second communication, the second channel being a mobile telephony short message service, the two channels being logically distinct from each other, the terminal comprising within it a mobile application, the following steps are implemented: beforehand:

- the mobile application asks the operating system of the terminal to be alerted in the event of a message received by the short message service,

- the mobile application asks the operating system of the terminal for the possibility of reading the messages received by the short message service, then:

- the server determines a transaction verification code,

- the server sends, to the mobile application and via the second channel, a message containing the verification code, - the server sends, to the terminal and via the first channel, a request asking the terminal to resend the verification code via the first channel,

- the terminal receives the request on the first channel,

- the mobile application automatically detects the receipt of the message on the second channel, - the mobile application automatically identifies the transaction verification code in the message, and to automatically identify the verification code in the message, the mobile application first automatically identifies in the message a predetermined character string, distinct from the verification code, certifying that the message includes a verification code, - the terminal sends back, to the server and via the first channel, a response to the request comprising the identified code. Thus, by automatically detecting the verification code on the second channel and sending it back via the first channel, the terminal avoids the user having to switch from the first channel to the second, for example from his web browser to his messaging service, and having to memorize or manually copy and paste the code from his second channel to the first. The two-factor authentication is therefore carried out as securely as in the state of the art, via the two channels, but without requiring any restrictive manipulation on the part of the user. The risk of error and the probability of abandonment of the transaction are therefore reduced.

In addition, the message includes a "flag", i.e. a string of characters indicating that the message includes a verification code. This flag can be specific to a particular transaction protocol (for example “3D Secure”). Its predetermined knowledge can also make it possible to know the format of the code to be identified and its position in the message.

In addition, in particular during the installation of the mobile application, it requests the accesses necessary for its operation to the operating system of the terminal. These accesses can be accepted automatically or upon simple validation by the user.

Moreover, compared to state-of-the-art solutions, the only change concerns the steps followed by the terminal. In particular, it is not necessary to modify the programming or the components of the banking server. It is also not necessary to modify the hardware components of the terminal, any mobile terminal of the smartphone or ordiphone type, having two logically distinct communication channels, can implement this process. A personal computer comprising two logically distinct communication channels, for example the presence of an Internet browser on one side and an e-mail system on the other, is also a terminal capable of executing the method without it being necessary to modify it. The invention is therefore easily implemented within an existing architecture.

Advantageously, the first channel is an Internet browser, and the second channel is a mobile telephone short message service or email messaging. Thus, while the request requesting the code is provided on a web page, for example in a field intended to receive the code, the verification code is provided by sms or by e-mail. Its identification and automatic copy saves the user from having to switch from his Internet browser to his mobile phone or e-mail messaging service and remember the code sent there to copy it into the browser. Preferably, after automatically identifying the verification code in the message and before sending the response back to the server, the terminal automatically copies the code, from the message received on the first channel, to the response to the request on the second channel.

Thus, it is the terminal which, without user intervention, reproduces the code in the response to be sent to the server, for example in a field provided for this purpose in the web page of the request.

Alternatively, after identifying the verification code in the message and before sending the response back to the server:

- the terminal automatically copies the code, from the message received on the first channel, to a buffer memory, - the user copies the code, from the buffer memory, to the response to the request on the second channel.

Thus, in this case, the terminal automatically copies the code to the memory, but it is the user who performs the "paste" operation, i.e. the manipulation consisting in copying from the buffer the code to the query response. Preferably, the request comprising a field to be filled in with the verification code, the response to the request comprises the request with the field filled in.

Thus, the request appears for example on a web page following the transaction request. Once the field has been filled in with the code and this response has been validated, the banking server receives the code provided in the field, via the first channel which is an Internet browser in this example, and compares it with the code sent via the second channel.

Provision is also made according to the invention for a two-factor authentication method for a banking transaction by a mobile terminal, in which the terminal comprises within a mobile application implementing the following steps: beforehand: - the mobile application asks the operating system of the terminal to be alerted in the event of a message received by the short message service,

- the mobile application asks the operating system of the terminal for the possibility of reading the messages received by the short message service, then: - reception of a request, on a first communication channel of the terminal, requesting the return of a transaction verification code,

- automatic detection of the reception of a message, on a second communication channel of the terminal logically distinct from the first, the second channel being a mobile telephone short message service, - automatic identification of a transaction verification code in the message, wherein to automatically identify the verification code in the message, the mobile application first automatically identifies in the message a string of predetermined character, distinct from the verification code, certifying that the message includes a verification code,

- sending, via the second channel, a response to the request including the identified code.

Thus, it is the mobile application installed on the terminal that implements the steps of the invention. It is therefore not necessary to modify the operating system of the terminal or other elements, it is enough to install and activate the application, which can be implemented with any type of terminal as long as it has the ability to communicate on two logically separate communication channels.

Advantageously: - the application also asks the operating system of the terminal beforehand for the possibility of deleting the messages received by the short message service,

- if a user of the terminal invalidates the transaction via the first channel, the application deletes the message, received by the short message service, including the transaction verification code. Thus, if the user cancels the transaction, then the application automatically deletes the text message containing the verification code, which is therefore removed from the memory of the terminal, this code having become useless.

There is also provided according to the invention a computer program for a mobile terminal comprising instructions which, when the program is executed by a mobile terminal, lead it to implement the steps of the method as described above. This program corresponds in particular to the mobile application itself.

Brief description of figures

The invention will be better understood and other characteristics and advantages thereof will appear on reading the following description of particular embodiments of the invention, given by way of illustrative and non-limiting examples, and referring to the attached drawings, including:

[Fig. 1] shows a prior art two-factor authentication business transaction system, [Fig. 2] shows a commercial transaction system with two authentication factors according to the invention,

[Fig. 3] illustrates a mobile phone implementing the invention,

[Fig. 4] shows an operating flowchart of the method of the invention.

Detailed Description Figures 1 and 2 show two transaction systems carried out through an open network, such as for example the Internet, using two-factor authentication. In these two figures, the same references correspond to the same or similar items. These two figures correspond to transaction schemes with two security factors as used in the state of the art and according to the invention.

By "open network", it is necessary to understand a communication network allowing interconnections between one or more computer machines accessible to anyone 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 facilitating the connection of people, thus increasing the possibilities of commercial transactions between people connected to said network. A disadvantage of open networks is the risk of interacting with machines belonging to 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 carry out a bank transfer or to carry out a purchase of securities online or any other type of operation for which the user makes a money transfer from his bank account. In this figure 1, 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 i.e. a transfer of money from a bank account.

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 allowing it to connect to the open network 3, a man-machine interface for viewing and entering information, such as for example a display screen, a touch screen, a keyboard, a mouse or other. Among the programs stored in its memory, the first terminal has a navigation program on the open network 3, allowing it to connect to and interact with web sites, in particular to consult web pages or to fill in and send forms corresponding to transaction requests. Alternatively, the first terminal 2 may have a specific program enabling it to connect through the open network 3 to the banking services server 4.

The banking services server 4, which will also be called in the following without distinction “banking server” or “banking transaction server”, is for example a computer having one or more processing units, at least one volatile memory and mass, and at least one communication interface allowing it to connect to the open network 3. The mass memory stores between others 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 includes programs stored in memory allowing it to make available to connected terminals, through the open network 3, searchable web pages which allow interaction 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.

When a transaction is desired by a user 1, the latter 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 may include information to be displayed on the first terminal 2, as well as commands to be executed according to choices made by the user via the man-machine interface. Among the choices offered to user 1, a transaction, for example a bank transfer, can be carried out. By choosing to make a transfer, a transaction form is presented to the user 1, the form can be included in the web page or transmitted by the banking services server 4 after reception 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. Many other pieces of information may also be required, such as redundant identifiers of the user and/or the bank account or 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. Once the form is completed, the 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 terminal 2.

Having received the completed transaction form, 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 interrogates 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 enable the transaction to be authorized. Optionally, the server can verify the correctness of redundant identifiers or information on the holder of the bank account. This first verification corresponds to a first safety factor. However, the transaction was transmitted by the open network 3 and, despite this first verification, it is possible that this transaction comes from misappropriation of the form and/or information relating to the bank account by a malicious third party.

Indeed, the communications on the open network 3 can be intercepted and possibly replayed in a modified manner. In order to guarantee a minimum of security, it is known to encrypt sensitive messages between two machines, such as for example the terminal 2 and the banking services server 4, using session keys or specific keys. However, any encrypted message can be decrypted after a certain time, which makes it possible to recover an exchanged form and reuse the information it contains. In addition, the fact that the network is open allows malicious people to spread viruses on the machines which are 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 to another machine also rendering the confidentiality of encrypted messages inoperative.

In order to add a level of security, a second security factor can be added by using a second communication channel to send a one-time code. For this purpose, 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 mobile telephone network provided 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 to send the transaction form.

After performing the first verification, the banking services server 4 recovers, in its database, the identifier of the second terminal 5 to send it a single-use 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 (Short Message Service). The message may also indicate the amount of the transaction and/or the beneficiary of the transaction, so that the account holder can verify that the transaction in progress conforms to a desired transaction. It should be noted that the short messaging service (SMS messaging) is managed by the operating system of the smartphone 5.

In parallel, the banking services server 4 sends the first terminal 2 a confirmation request requesting the single-use code. User 1, if corresponds to the holder of the bank account, 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 banking services server 4.

Upon receipt of the response form, the banking services server 4 compares the code present in the form with the single-use 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 services server 4 can reiterate sending a new single-use verification code to the second terminal 5 and a request to the first terminal 2. This two-factor authentication, the second factor of which is the code provided to the user by a second channel and having to be sent back to the server by the first, makes it possible to improve the security of the transactions. The disadvantage is that the user must have both his terminal 2 and his smartphone 5 to validate the transaction. He must copy, via the interface of terminal 2, a code read on smartphone 5, which can be a source of error. These constraints can cause the user to abandon the transaction.

Figure 2 illustrates elements of a transaction according to the invention that are similar. Instead of using terminal 2 and a smartphone 5 in FIG. 1, the user performs the entire transaction on one and the same smartphone 8, which combines the steps carried out on terminals 2 and 5 of the figure 1.

The terminal 8, a smartphone, has classic components of any smartphone, as illustrated in FIG. 3. Thus, it has a microprocessor 81 controlling a central bus 87 to exchange data with a memory 84, of the EEPROM type (of the English “Electrically-Erasable Programmable Read-Only Memory”) flash, or else of the ROM type (from the English “Read-Only Memory”) as well as with a volatile memory 83 of the RAM type (from the English “Random Access Memory») It also communicates with the user interface 82 of the terminal 8, comprising in particular a touch screen, and possibly one or more buttons, or even a keyboard. The terminal also includes a SIM card 86 and a radio antenna 85 to communicate without contact with the outside, in particular by Internet, by e-mail or by sms. An operating system, that is to say a computer program, is implemented by the microprocessor 81 to manage all the components of the terminal 8. In particular, this operating system can authorize the read or write access to certain areas of the memory to commands from mobile applications installed on the smartphone 8. Of course, many architectural variants of smartphone are known and those skilled in the art can at their leisure use a different or similar architecture from that described in FIG. 3. Nevertheless, those skilled in the art will take care to use only architectures comprising the possibility of communicating by least two logically distinct communication channels. Thus, this smartphone 8 is connected by two logically distinct communication channels to the banking services server 4. The first channel is the Internet browser, which allows the user of the smartphone 8 to request and then validate the transaction in the same way than on terminal 2 in figure 1. In other words, where user 1 in figure 1 performed the transaction on a computer 2, user 1 in figure 2 performs it on his ordiphone 8, but always online. The second channel is, as for the smartphone 5 in FIG. 1, the short message service of the SMS type managed by the operating system of this smartphone 8. It could alternatively be an e-mail system. The banking services server 4 always performs the same operations for it: when the user orders a transaction and after verification of a first authentication factor, the server 4 sends to the terminal 8 and via the first channel, i.e. ie here by Internet, a request asking to return a verification code. This involves displaying on the screen, via the web browser of the smartphone 8, the request with a field to be filled in intended for this code. At the same time, the server 4 produces a single-use verification code which it sends to the smartphone 8 via the second channel, that is to say here by SMS. The user 1 is therefore presented on the smartphone 8, on the one hand with a web page where he is asked to provide a verification code to validate the transaction he has initiated, and on the other hand, an sms on his SMS messaging including the code.

At this stage, in a transaction according to the state of the art, the user, manipulating the ordiphone 8, would then have to leave his internet browser to open his messaging application, to read the verification code of the SMS received and to return to the browser to fill, from memory, the field intended for the verification code in the web page where the corresponding request appears. Alternatively, he could attempt to use the smartphone's copy/paste function for this purpose. In both cases, the process is cumbersome, error-prone and can lead the user to abandon the transaction.

This is why, unlike the ordiphone 5 of FIG. 1, the ordiphone 8 includes within it a specific mobile application 6, illustrated schematically in FIG. 2, recorded in the memory 83 of the terminal and installed via the operating system of the terminal 8. Once activated, and requested to authenticate a transaction, this mobile application 6 leads the terminal 8 to implement the steps of the flowchart of FIG. 4. This mobile application 6 is in the form of a a computer program provided specifically for a mobile terminal. It can be downloaded and installed on any mobile device such as a smartphone or smart phone. In the following, we will describe, by means of figure 4, the steps implemented by the terminal 8 thanks to this application 6.

Recall that the context is as follows: user 1 orders a transaction on the Internet via his terminal 8. The first authentication factor is verified. The second is the production, by the banking services server 4, of the verification code, sent by SMS to the terminal 8. It is considered that the application 6 is activated. Then, in a first step 101, the application 6 listens to the messaging service managed by the operating system of the terminal 8. If and when an SMS is received on the messaging service, an alert is issued at step 102 (an “INTERRU PT” type signal) so as to allow the application 6 to read the received sms, at step 103. At this step, it is determined whether the sms includes a string of predetermined character attesting that the sms relates to a banking transaction. If this is not the case, nothing is done and the method returns to step 101, waiting for the next sms. The character string, called "Flag", can for example refer to the banking service associated with the transaction, or to a predetermined authentication protocol, for example with the string "3D Secure" which corresponds to the protocol of the same name described in 2017 (“3DSecure2.0 Specification by EMVCo”). Any type of flag can be recognized by the mobile application, from the moment its identification has been provided for in the mobile application, before its installation or during an update. If this string is identified, the mobile application 6 identifies the verification code automatically in step 104. In particular, the format of this type of sms being known, it is easy to identify a code for example by calculating the position of its first character with respect to the Flag, position which can always be the same. This code is then "copied", in step 105, into a buffer memory, for example the RAM memory 83 of the terminal 8. The mobile application 6 then provides in step 106 to "paste" the code, that is that is to say, to reproduce this code from the buffer, to automatically place it in the field of the request on the web browser, thus performing a copy-paste operation. In summary, these steps 101 to 106 lead to the automatic production of the response to the request from the banking service by automatically detecting, identifying and reproducing the code provided by sms in the web page of the transaction and particularly in the corresponding field. At step 107, the user is asked to validate the provision of the code. All he has to do is press the button corresponding to the validation. Conversely, he can also cancel the transaction. In the event of validation and in a conventional manner, not specific to the invention, the banking services server 4 will check in step 108 the conformity of the code received with the code provided, to validate or not the transaction. It should be noted that during all the steps 101 to 106, the user did not have to manipulate the ordiphone 8. Thus, the monitoring of the sms, the identification of a relevant sms, the identification of the code of verification in the text message, and its copy in the field of the web page, were carried out automatically by the mobile application 6, the user having only to validate the provision of this code. Conversely, as we said, he can also cancel it at step 107. In this case, at step 109, or even if the user cancels the transaction earlier but after having received the SMS verification code, the mobile application 6 automatically deletes from the messaging system of the terminal 8 the SMS containing the code. Thus, the code is no longer stored in the memory of the terminal. Alternatively, it is entirely possible to send the code back without even asking the user for validation. In this case, the user no longer performs any action from the moment he has ordered the transaction before step 101, the entire process corresponding to the second factor being performed automatically without intervention on his part. Alternatively, the code can be copied not directly into the field of the web request, but into a separate field, for example within a specific window appearing at the appropriate time (a "pop-up") . This “pop-up” displays to the user the code copied from the buffer memory (and therefore before that from the messaging system), and a button allowing the user to validate or not the sending of this code. If it validates, then the application 6 copies the code into the appropriate field of the request, and it adds to the code the characters '\rï, which is interpreted by the browser as the use of the "enter" key or validation. Thus, the user is not asked again to validate this code since he has already done so when it was displayed in the “pop-up”. Alternatively again, we can provide that the code is copied from the messaging service into the buffer memory, but instead of pasting it into the control of the web page or into a "pop-up" automatically, it is user to manually perform this "paste" function in the field of the web page.

For the mobile application 6 to be able to carry out the steps described above, it must have the appropriate accesses. This is why, in preliminary steps not illustrated, during the installation of the mobile application 6 on the terminal 8, the latter asks the operating system of the terminal 8 for access to reading the sms (access type "READ") of the messaging service. It also asks for the possibility of being alerted in the event of reception of an sms, and finally the possibility of deleting an sms. It is once these accesses have been accepted, by the user or automatically depending on how the terminal 8 is configured, that the activation can operate as described above. This invention therefore makes it possible to copy and paste the verification code received by a second channel, in this case by sms, in order to send it via a first channel, in this case by Internet, in response to a requester requesting this code to validate two-factor authentication. It allows this to be done automatically, avoiding the user having to switch from the browser to their messaging service and vice versa to memorize or manually copy and paste the code received by sms. It reduces the risk of the user abandoning the transaction due to second factor authentication constraints. Another advantage is that it does not require changes to existing systems. Thus, the bank server remains identical. In addition, on the terminal side, the operating system remains identical, there is no need to adapt or update it. The only modified element is the presence of the mobile application installed on the terminal. In addition, this mobile application can be compatible with any operating system and any bank server, as well as with any payment protocol using two-factor authentication. The invention is not limited to the embodiments shown and other embodiments will be apparent to those skilled in the art. In particular, the two-factor authentication method can be carried out within the framework of the “3D Secure” payment protocol but is not limited to such a type of protocol. Similarly, the communication channels may be different from those mentioned, the invention being applicable to any type of channel accessible by a mobile application, if necessary after requesting access to the operating system.

Claims

[Claim 1] Method (100) of two-factor authentication of a banking transaction, in which, a terminal (8) of a user being linked to at least one banking transaction server (4) via first and second communication channels, the second channel being a mobile telephony short message service, the two channels being logically distinct from each other, the terminal comprising within it a mobile application, the following steps are implemented: beforehand :

- the mobile application (6) asks the operating system of the terminal (8) to be alerted in the event of a message received by the short message service,

- the mobile application (6) asks the operating system of the terminal (8) to read the messages received by the short message service, then:

- the server (4) determines a transaction verification code,

- the server (4) sends, to the mobile application and via the second channel, a message containing the verification code,

- the server (4) sends, to the terminal (8) and via the first channel, a request asking the terminal (8) to send back the verification code via the first channel,

- the terminal receives the request on the first channel,

- the mobile application (6) automatically detects (102) the reception of the message on the second channel,

- the mobile application (6) automatically identifies (104) the transaction verification code in the message, and to automatically identify (104) the verification code in the message, the mobile application (6) first identifies (103) automatically in the message a predetermined character string, distinct from the verification code, certifying that the message includes a verification code, - the terminal returns (108), to the server and via the first channel, a response to the request comprising the identified code.

[Claim 2] A method (100) according to the preceding claim, wherein the first channel is an internet browser, and the second channel is a mobile telephone short message service or e-mail messaging.

[Claim 3] A method (100) according to any preceding claim, wherein, after automatically identifying (104) the verification code in the message and before returning (108) the response to the server, the terminal (8 ) automatically copies (105) the code, from the message received on the first channel, to (106) the response to the request on the second channel.

[Claim 4] A method (100) according to any of claims 1 to 2, wherein, after identifying (104) the verification code in the message and before returning (108) the response to the server:

- the terminal (8) automatically copies (105) the code, from the message received on the first channel, to a buffer memory,

- the user copies the code, from the buffer, to the response to the request on the second channel.

[Claim 5] Method (100) according to one of the preceding claims, in which, the request comprising a field to be filled in with the verification code, the response to the request comprises the request with the field filled in.

[Claim 6] Method (100) for two-factor authentication of a banking transaction by a mobile terminal (8), in which the terminal (8) comprises within a mobile application (6) implementing the following steps: beforehand:

- the mobile application (6) asks the operating system of the terminal (8) for the possibility of reading the messages received by the short message service, then: - receipt of a request, on a first communication channel of the terminal (8), requesting the return of a transaction verification code,

- automatic detection (102) of the reception of a message, on a second communication channel of the terminal (8) logically distinct from the first, the second channel being a short message service for mobile telephony,

- automatic identification (104) of a transaction verification code in the message, in which, to automatically identify (104) the verification code in the message, the mobile application (6) first identifies (103) automatically in the message a predetermined character string, distinct from the verification code, certifying that the message includes a verification code,

- sending (108), via the second channel, a response to the request including the identified code.

[Claim 7] A method (100) according to the preceding claim, wherein:

- the application (6) also asks the operating system of the terminal (8) beforehand for the possibility of deleting the messages received by the short message service,

- if a user of the terminal (8) invalidates the transaction via the first channel, the application (6) deletes (109) the message, received by the short message service, comprising the transaction verification code.

[Claim 8] Computer program (6) for a mobile terminal comprising instructions which, when the program is executed by a mobile terminal (8), cause the latter to implement the steps of claims 6 to 7.