WO2015186195A1 - Système de transaction - Google Patents

Système de transaction Download PDF

Info

Publication number
WO2015186195A1
WO2015186195A1 PCT/JP2014/064757 JP2014064757W WO2015186195A1 WO 2015186195 A1 WO2015186195 A1 WO 2015186195A1 JP 2014064757 W JP2014064757 W JP 2014064757W WO 2015186195 A1 WO2015186195 A1 WO 2015186195A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
server
user
transaction
authentication
Prior art date
Application number
PCT/JP2014/064757
Other languages
English (en)
Japanese (ja)
Inventor
秀治 小川
Original Assignee
パスロジ株式会社
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 パスロジ株式会社 filed Critical パスロジ株式会社
Priority to JP2014547614A priority Critical patent/JP5670001B1/ja
Priority to PCT/JP2014/064757 priority patent/WO2015186195A1/fr
Priority to US15/316,043 priority patent/US11206266B2/en
Priority to JP2015512937A priority patent/JP5750560B1/ja
Priority to PCT/JP2015/051525 priority patent/WO2015186372A1/fr
Priority to JP2015100634A priority patent/JP6584824B2/ja
Publication of WO2015186195A1 publication Critical patent/WO2015186195A1/fr
Priority to US17/524,534 priority patent/US11902283B2/en
Priority to US18/438,173 priority patent/US20240187415A1/en

Links

Images

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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles
    • 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/31—User authentication
    • 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/31—User authentication
    • G06F21/42—User authentication using separate channels for security data
    • G06F21/43—User authentication using separate channels for security data wireless channels
    • 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
    • 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/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • 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

Definitions

  • the present invention relates to a transaction system suitable for enhancing safety in a transaction system that requires first authentication for login to a server and requires second authentication for execution of a transaction instructed after login.
  • the MITB attack can be achieved simply by rewriting the contents of the transaction exchanged between the server and the access terminal so that it cannot be seen by the user, so this can be prevented by simply combining the first authentication and the second authentication. It is difficult. Therefore, a technique for effectively preventing such an attack is required.
  • the present invention is to solve the above-described problems, and requires first authentication to log in to a server, and enhances safety in a transaction system that requires second authentication to execute a transaction instructed after login. It is an object of the present invention to provide a suitable transaction system.
  • the transaction system is: A transaction system comprising a server, a first terminal, and a second terminal,
  • the server When receiving a transaction instruction via the first terminal from a user who has logged in to the server due to the success of the first authentication via the first terminal, the server is notified that the server should transmit to the second terminal.
  • the second terminal attempts a second authentication of the user,
  • the second terminal presents the transaction details to the user,
  • the server is configured to execute the transaction when the transaction is confirmed by the user presented with the details of the transaction.
  • a transaction system suitable for enhancing safety in a transaction system that requires first authentication for login to a server and requires second authentication for execution of a transaction instructed after login. it can.
  • FIG. 6 is a display example of a login form displayed on the first terminal according to the embodiment of the present invention.
  • 7 is a display example of a transfer form displayed on the first terminal according to the embodiment of the present invention.
  • FIG. 6 is a display example of a standby form displayed on the first terminal according to the embodiment of the present invention.
  • FIG. 7 is a display example of a notification transmitted to a second terminal according to an embodiment of the present invention.
  • FIG. 10 is a display example of an authentication form of a dedicated application that is activated on the second terminal according to the embodiment of the present invention.
  • FIG. 10 is a display example of an authentication form for requesting a retry at the second terminal according to the embodiment of the present invention.
  • FIG. 10 is a display example of a standby form indicating that the transaction is canceled at the first terminal according to the embodiment of the present invention.
  • FIG. 10 is a display example of a cancellation form displayed on the second terminal according to the embodiment of the present invention.
  • FIG. FIG. 10 is a display example of a standby form indicating that the second authentication is successful at the first terminal according to the embodiment of the present invention.
  • FIG. FIG. 10 is a display example of an authentication form of a dedicated application that is activated on the second terminal according to the embodiment of the present invention.
  • FIG. 10 is a display example of an authentication form for requesting a retry at the second terminal according to the embodiment of the present invention.
  • FIG. 10 is
  • FIG. 10 is a display example of a confirmation form displayed on the second terminal according to the embodiment of the present invention.
  • FIG. FIG. 10 is a display example of a standby form indicating that the transaction is completed at the first terminal according to the embodiment of the present invention.
  • FIG. FIG. 10 is a display example of a completion form indicating that the transaction is completed at the second terminal according to the embodiment of the present invention.
  • FIG. FIG. 10 is a display example of a confirmation form displayed on the second terminal according to the embodiment of the present invention.
  • FIG. 1 is an explanatory diagram showing an outline of a transaction system according to an embodiment of the present invention.
  • FIG. 1 is an explanatory diagram showing an outline of a transaction system according to an embodiment of the present invention.
  • the transaction system 101 includes a server 121, a first terminal 141, and a second terminal 161.
  • Server 121 provides services such as Internet banking.
  • the first terminal 141 is communicatively connected to the server 121 via the computer communication network 181 and is used by the user to access the server 121.
  • the user logs in to the server 121 through the first terminal 141 by the first authentication.
  • a personal computer is employed as the first terminal 141, but a mobile terminal such as a smartphone may be used.
  • the first terminal 141 and the server 121 are connected via an Internet connection provider using an optical cable or the like.
  • the second terminal 161 is communicably connected to the server 121 via the computer communication network 181, and the user who has logged in to the server 121 indicates the contents of the transaction instructed to the server 121 via the first terminal 141 by the user. Used to confirm.
  • a mobile terminal such as a smartphone is adopted as the second terminal 161, but a personal computer or the like may be used.
  • the second terminal 161 and the server 121 are connected via a mobile phone communication network using wireless or the like.
  • the first terminal 141 and the second terminal 161 need not be able to communicate with each other. That is, the communication network related to communication between the first terminal 141 and the server 121 and the communication network related to communication between the second terminal 161 and the server 121 pass through different communication paths as described above. It is typical. However, since the first terminal 141 and the second terminal 161 are assumed to be used by the user at the same time, they may be able to communicate with each other via wireless LAN or Bluetooth (registered trademark). In addition, the server 121 may communicate with the server 121 via a common gateway.
  • first terminal 141 and the second terminal 161 are typically different terminals, but the same terminal may be used depending on the application.
  • FIG. 2 is an explanatory diagram showing how information is exchanged in the transaction system according to the embodiment of the present invention.
  • a description will be given with reference to FIG. In this description, it is assumed that the user name and the first password are used for the first authentication, and the second password is used for the second authentication. Other aspects will be described later.
  • the first terminal 141 sends the user name and the first password to the server 121 (202).
  • the first authentication for the user name and the first password is successful at the server 121 (203)
  • the result is sent from the server 121 to the first terminal 141 (204).
  • the server 121 executes the low-risk procedure.
  • the result is sent from the server 121 to the first terminal 141 (207).
  • the server 121 displays the content of the notification on the screen of the first terminal 141 by encoding a code such as an encrypted character string, a one-dimensional code, or a two-dimensional code.
  • a code such as an encrypted character string, a one-dimensional code, or a two-dimensional code.
  • the code displayed on the screen may be photographed using a camera or the like included in the device, and the second terminal 161 may obtain a notification from the photographed code.
  • the second terminal 161 When the notification is transmitted from the server 121, the second terminal 161 requests the user to input the second password (210). If the second terminal 161 and the server collaborate and the second authentication for the second password succeeds (211), the second terminal 161 displays the contents of the transaction specified in the notification on the screen of the second terminal 161. (212) to inform the user.
  • the result is also sent to the second terminal 161 (217), and the notice of the details of the transaction is deleted from the user and the result of the executed transaction is displayed.
  • the second password entered by the user to the second terminal 161 is sent to the server 121, and the server 121 performs second authentication.
  • conventional Internet banking it was customary to enter the first password and the second password from one access terminal. In this mode, the first password and the second password are entered from different terminals. Therefore, even if one terminal is attacked by a computer virus, it is possible to prevent damage caused by the MITB attack as much as possible.
  • a character string or symbol string determined in advance between the user and the server 121 may be employed, or a one-time password may be employed.
  • One-time password modes are as follows: (1) First of all, a random number table distributed to the user from the operator of the server 121 (each cell is filled with codes such as numbers, letters, figures, etc.) Is extracted from the first terminal 141 or the second terminal 161, and the second terminal 161 inputs a character string in which the codes in the extracted random number table are arranged. Conceivable. (2) In addition, the server 121 may display the one-time password on the screen of the first terminal 141, and the user may input the displayed one-time password from the second terminal 161.
  • the server 121 displays a random number table on the screen of the first terminal 141, and the user extracts a code from the grid based on the extraction rule assigned to the user, and the code in the extracted random number table is displayed.
  • a method of inputting the arranged character strings at the second terminal 161 can also be adopted.
  • the contents of the transaction are not displayed on the screen of the second terminal 161 until the second authentication is successful. Therefore, there is an advantage that when the second terminal 161 is lost or stolen, even if a high-risk procedure is started without noticing it, the contents of the transaction do not leak.
  • the user who sees the content of the transaction to be performed displayed on the screen of the second terminal 161 gives a confirmation instruction if it can be executed.
  • the simplest confirmation method is to tap or click an object (a button or a link displayed on the screen) for executing a transaction, or to press a return key.
  • the user inputs the second password at the time of the second authentication, but the second authentication may have various modifications.
  • the user confirms the execution of the transaction by tapping or clicking a button or a link displayed on the screen together with the transaction content, but the confirmation may have various modifications. . These modifications will be described later.
  • the server 121 functions as a web server, and the first terminal 141 operates a browser program for accessing the server 121.
  • the first terminal 141 can use a conventional browser as it is. Therefore, hereinafter, a flow of processing in which the server 121 cooperates with the first terminal 141 and the second terminal 161 will be described.
  • FIG. 3 is a flowchart showing the flow of processing in the server according to the embodiment of the present invention.
  • the server processing shown in this figure is executed by the server 121 executing a server program.
  • the first terminal 141 executes a browser program
  • the second terminal 161 executes a dedicated application program.
  • each program is read by a computer such as a compact disk, flexible disk, hard disk, magneto-optical disk, digital video disk, magnetic tape, ROM (Read Only Memory), EEPROM (Electrically Erasable Programmable ROM), flash memory, semiconductor memory, etc. It can be recorded on possible non-transitory information recording media.
  • This information recording medium can be distributed and sold independently of the computers that constitute the server 121, the first terminal 141, and the second terminal 161.
  • a computer reads a program recorded on a non-transitory information recording medium into a RAM (Random Access Memory) which is a temporary storage device, and then a CPU (Central Processing Unit).
  • the processor executes a command included in the read program.
  • the CPU directly reads and executes instructions included in the program stored in ROM.
  • the above-described program is transmitted from the distribution device or the like via a transitory transmission medium such as a computer communication network, independently of the computer on which the program is executed, from the server 121, the first terminal 141, the second It can be distributed and sold to the terminal 161 or the like.
  • a transitory transmission medium such as a computer communication network
  • the CPU or the processor controls the NIC (Network Interface Card), the display, the microphone, the speaker, and the like in cooperation with the RAM and the like.
  • the server 121 performs various initializations (step S301), receives a packet sent via the computer communication network (step S302), and examines the contents (step S303).
  • Step S303 access request
  • a login form for entering a user name and password is transmitted to the first terminal 141.
  • the process returns to Step S302.
  • the access request is transmitted from the first terminal 141 to the server 121 when the user designates the URL (Universal Resource Locator) of the server 121 in the browser operating on the first terminal 141.
  • URL Universal Resource Locator
  • FIG. 4 is a display example of a login form displayed on the first terminal according to the embodiment of the present invention. Hereinafter, a description will be given with reference to FIG.
  • the login form 401 is provided with a user name field 402, a password field 403, and a login button 404.
  • a user name field 402 When the user inputs the user name assigned to his / her account in the user name field 402, inputs the password field 403 as the login password, and clicks the login button 404, the first terminal 141 logs in to the server 121. A request is sent.
  • step S303 If the packet received by the server 121 is a login request transmitted from the first terminal 141 (step S303; login request), the first authentication is attempted using the user name and password specified in the login request. (Step S305). If the first authentication fails (step S305; failure), the server 121 transmits an error response indicating that the login has failed to the first terminal 141 (step S306), and returns to step S302.
  • step S305 if the first authentication is successful (step S305; success), the server 121 performs low-risk procedures such as balance inquiry and transaction history inquiry, transfer, transfer, application for time deposit, application for financial products, password change.
  • a start form in which a link to a high-risk procedure or the like is arranged is transmitted to the first terminal 141 (step S307), and the process returns to step S302.
  • the first terminal 141 that has received the starting form displays it on the browser screen and allows the user to select a desired procedure. Then, a request corresponding to the selected procedure is transmitted from the first terminal 141 to the server 121.
  • a transfer form is generated and transmitted to the first terminal 141.
  • the generation and transmission of the bank transfer form corresponds to a mere page transition that does not involve execution of the transaction itself, and can be considered as a low-risk procedure.
  • step S303 low-risk procedure request
  • step S308 the server 121 performs a low-risk procedure corresponding to the request. This is executed (step S308), and the result form is transmitted to the first terminal 141 (step S309), and the process returns to step S302.
  • links for executing various processes are arranged thereafter.
  • FIG. 5 is a display example of a transfer form displayed on the first terminal according to the embodiment of the present invention.
  • the transfer form 411 includes a bank name column 412, a branch name column 413, an account type column 414, an account number column 415, an account holder name column 416, a transfer amount column 417, and an execution button 418 for specifying a transfer destination. Has been placed. When the user clicks the execute button 418 after inputting the transfer destination information in each field 412-417, a transfer request is transmitted from the first terminal 141 to the server 121. This transfer request is a high risk transaction.
  • the transfer destination information is input in one form. However, the transfer destination information may be sequentially input by a plurality of ordered page transitions.
  • the server 121 obtains the name of the account holder from the database and complements the account holder name column 416. By doing so, the user's direct input may be omitted. In addition, it is possible to assist the user's input by preparing a list box for easily selecting a transfer destination registered in advance.
  • the server 121 performs the procedure specified in the high-risk procedure request.
  • a transaction ID is assigned to (transaction), and a notification indicating the transaction ID and the content of the transaction is generated (step S310).
  • the transaction ID is linked to the high-risk procedure specified by the user, and the server 121 is used to request the high-risk procedure for who the user specified the high-risk procedure by the transaction ID.
  • Information such as which terminal is the first terminal 141 and which stage the progress status of the high-risk procedure is in is managed.
  • the server 121 transmits, to the first terminal 141, a standby form indicating the contents of the procedure (transaction) specified in the high-risk procedure request and the transaction ID to the first terminal 141 (step S311).
  • FIG. 6 is a display example of a standby form displayed on the first terminal according to the embodiment of the present invention.
  • the contents of the high-risk procedure accepted by the server 121 are displayed in the transaction content column 422. Further, the progress status column 423 displays that the second authentication is waiting.
  • the trap server 121 transmits a message to that effect to the first terminal 141.
  • the script specified in the standby form 421 is waiting for a progress report to be transmitted from the server 121.
  • a new situation is displayed in the progress column 423. To do.
  • the transaction ID is also specified in the script.
  • the standby form 421 is provided with a cancel button 424.
  • a cancel button 424 When the user operates the cancel button 424 before the second authentication and confirmation through the second terminal 161, a request to that effect is transmitted from the first terminal 141 to the server 121, and the server 121 receives the transaction ID.
  • the suspension of transactions related to is executed as a low-risk procedure. Specifically, the fact that the transaction with the transaction ID is canceled is recorded in a database or the like in association with the transaction ID.
  • a result form indicating the result is sent from the server 121 to the first terminal 141, and the browser of the first terminal 141 displays the result form on the screen.
  • the contents of the transaction content field 422 displayed on the standby form 421 may be displayed after being changed to the attacker's account, etc., or modified to the original bank information. In some cases.
  • the contents of the transaction instructed from the first terminal 141 to the server 121 are transmitted to the second terminal 161 as they are.
  • the server 121 obtains the destination information of the second terminal 161 registered in advance for the user who has logged in from the first terminal 141 from the database (step S312), and generates the second terminal 161.
  • the notified notification is transmitted (step S313), and the process returns to step S302.
  • a push notification for a dedicated application operating on the second terminal 161 can be employed.
  • a notification area prepared by the operating system of the second terminal 161 is automatically popped up and displayed.
  • FIG. 7 is a display example of a notification transmitted to the second terminal according to the embodiment of the present invention.
  • a notification 432 indicating that a notification regarding the high-risk procedure has arrived is displayed in the home screen 431 of the second terminal 161.
  • the user taps or clicks the notification 432 displayed on the home screen 431 of the second terminal 161, displays a list of notifications at the notification center, taps or clicks the notification 432,
  • the dedicated application is activated. Further, depending on the specifications of the second terminal 161, it may be set so that the dedicated application is automatically activated when a notification arrives.
  • a URL to a web application that performs the same function as the dedicated application may be transmitted to an SMS, an email address, or the like assigned to the second terminal 161.
  • the browser of the second terminal 161 is activated and the web application is executed.
  • the server 121 encodes the content of the notification, such as an encrypted character string, a one-dimensional code, and a two-dimensional code, on the standby form 421 of the first terminal 141, and the user selects a dedicated application.
  • the second terminal 161 may obtain a notification from the photographed code by starting and photographing the code displayed on the standby form 421 using a camera or the like provided in the second terminal 161.
  • FIG. 8 is a display example of an authentication form for a dedicated application activated on the second terminal according to the embodiment of the present invention.
  • the authentication form 441 includes a password field 442 and an authentication button 443, and a message field 444 displays an instruction to input a password for the second authentication. ing.
  • a transaction password in the password field 442 and taps or clicks the authentication button 443, an authentication request specifying the transaction ID and the transaction password is transmitted from the second terminal 161 to the server 121.
  • step S314 If the packet received by the server 121 is an authentication request transmitted from the second terminal 161 (step S303; authentication request), the server 121 tries the second authentication (step S314).
  • the following information is scrutinized: (1) Whether the high-risk procedure for the transaction ID specified in the authentication request is ongoing (has not been canceled). (2) Whether a notification is transmitted to the second terminal 161 of the transmission source related to the transaction ID. (3) Whether the transaction password specified in the authentication request is valid as the password of the user who specified the high-risk procedure for the transaction ID.
  • step S314 threshold number failure
  • the server 121 prompts the user to re-enter the transaction password for the second terminal 161. (Step S315), and the process returns to step S302.
  • FIG. 9 is a display example of an authentication form for requesting a retry at the second terminal according to the embodiment of the present invention.
  • the fact that the server 121 has requested re-input is displayed in the message field 444, and the user can input the transaction password again.
  • step S314 failure for the threshold number of times or more
  • the server 121 cancels the transaction for the first terminal 141 and the second terminal 161. (Step S316), and the process returns to step S302.
  • FIG. 10 is a display example of a standby form indicating that the transaction is canceled at the first terminal according to the embodiment of the present invention.
  • the progress status column 423 of the standby form 421 displays that the transaction has been canceled
  • the cancel button 424 is hidden
  • an OK button 425 is displayed instead.
  • the browser transitions to a start form or the like.
  • FIG. 11 is a display example of a cancellation form displayed on the second terminal according to the embodiment of the present invention.
  • the message column 452 of the cancellation form 451 displays that the transaction has been canceled.
  • the OK button 453 is tapped, the contents of the message field 452 are deleted, and a management form for the dedicated application is displayed.
  • step S314 when the second authentication is successful (step S314; success), the server 121 reports the success of authentication to the first terminal 141 and the second terminal 161 (step S317), and returns to step S302.
  • FIG. 12 is a display example of a standby form indicating that the second authentication is successful at the first terminal according to the embodiment of the present invention. As shown in this figure, the progress status column 423 of the standby form 421 displays that the second authentication has been successful and is waiting for user confirmation at the second terminal 161.
  • FIG. 13 is a display example of a confirmation form displayed on the second terminal according to the embodiment of the present invention.
  • the confirmation form 461 details of the contents of the current transaction are displayed in the message field 462.
  • the details of the contents of the transaction have already been acquired in the second terminal 161 by the previously received notification. Therefore, the content of the high-risk procedure can be displayed in the message field 462 by collating the transaction ID specified in the authentication success report with the content of the received notification.
  • the content of the high-risk procedure is not specified in the notification itself, but the content of the high-risk procedure is specified in the success report transmitted from the server 121 to the second terminal 161 after the second authentication is successful. It's also good.
  • a confirmation button 463 is prepared on the confirmation form 461.
  • a confirmation request for specifying a transaction ID is transmitted from second terminal 161 to server 121.
  • the stop button 424 may be operated on the standby form 421 displayed on the browser of the first terminal 141.
  • a separate cancel button may be provided on the confirmation form 461, and the transaction may be canceled when the user taps the confirmation button.
  • the server 121 checks the consistency of the confirmation request (step S318). . Specifically, the following items are inspected. (1) Whether the high-risk procedure for the transaction ID specified in the confirmation request is ongoing (has not been canceled). (2) Whether the terminal that sent the confirmation request is the second terminal 161 that has succeeded in the second authentication for the transaction ID.
  • step S318 If the check request does not pass this check (step S318; failure), the transaction cannot be continued, and control proceeds to step S316, where the transaction is stopped.
  • step S318 if the confirmation request passes this inspection (step S318; success), the server 121 executes a high-risk procedure (step S319). That is, in this embodiment, transfer remittance associated with the transaction ID is performed. Further, the progress status of the transaction linked to the transaction ID is updated to “completed”.
  • the server 121 reports the completion of the transaction to the first terminal 141 and the second terminal 161 (step S320), and returns to step S302.
  • FIG. 14 is a display example of a standby form indicating that the transaction is completed at the first terminal according to the embodiment of the present invention. As shown in the figure, the progress status field 423 and the transaction content field 422 of the standby form 421 indicate that the transaction has been completed. Further, since the transaction is completed, the cancel button 424 is hidden and an OK button 425 is displayed instead. When the user operates the OK button 425, the browser transitions to a start form or the like.
  • FIG. 15 is a display example of a completion form indicating that the transaction is completed at the second terminal according to the embodiment of the present invention.
  • the completion form 471 the history of transactions completed so far is displayed in the history column 472 in a scrollable manner.
  • the OK button 473 is tapped, a management form for the dedicated application is displayed.
  • the dedicated application operating on the second terminal 161 automatically switches the form displayed on the screen to the authentication form 441 when a notification is transmitted from the server 121.
  • a tab may be prepared for each server 121 so that processing based on a series of forms can be switched for each server 121.
  • step S303 If the packet received by the server 121 is another type of packet (step S303; other), the server 121 executes a corresponding process (step S321) and returns to step S302.
  • the first authentication related to login is performed from the first terminal 141 for the user to access the server 121
  • the second authentication related to the high-risk procedure (transaction) is performed from the server 121. This is performed from the second terminal 161 to which the notification is transmitted. Then, after the second authentication is successful, the content of the transaction is presented to the user on the second terminal 161, and after confirming the content on the second terminal 161, the transaction is executed.
  • the transaction confirmation does not necessarily have to be performed from the second terminal 161, and may be performed at the first terminal 141. Good. In this case, as will be described later, it is preferable to combine with a technique that prompts the user to examine the contents of the transaction displayed on the second terminal 161.
  • the content of the high-risk procedure is not displayed on the screen of the second terminal 161 until the user inputs the second password at the second terminal 161 and the second authentication is successful.
  • the second authentication is automated.
  • the server 121 when the server 121 encrypts the content of the notification and the second terminal 161 attempts to decrypt the encrypted notification and succeeds, the second authentication is considered successful.
  • the second terminal 161 functions as an authentication token.
  • a mode in which the server 121 and the second terminal 161 each generate a common key for time synchronization can be adopted as the encryption system. That is, the server 121 encrypts the notification using the common key generated by the server 121. When the encrypted notification is transmitted to the second terminal 161 from the encryption to the expiration of the common key, the second terminal 161 is encrypted with the common key generated by the second terminal 161. Decrypt notifications.
  • public key cryptography can also be adopted for this embodiment. That is, the user generates a public key / private key pair by using the second terminal 161 as a notification destination.
  • the public key is transmitted to the server 121.
  • the server 121 encrypts the notification with the public key when sending the notification, and the second terminal 161 decrypts the encrypted notification with the secret key.
  • time synchronization cipher requires sharing the seed between the server 121 and the second terminal 161, but when transmitting the seed from one to the other, the use of public key cryptography further improves security. Can be made.
  • the second authentication is automatically executed and the second password is not necessarily required.
  • the second password may be used in order to sufficiently perform the authentication by the user.
  • the second terminal 161 requests the user to input a transaction password.
  • the second terminal 161 and the server 121 cooperate to perform authentication (third authentication) using the input transaction password. If the third authentication is successful, it is considered that the transaction has been confirmed by the user, and the server 121 executes the transaction.
  • This aspect is similar in appearance to the Internet banking aspect that is widely used at present, but in this aspect, the contents of the transaction are encrypted in the server 121 and decrypted in the second terminal 161.
  • the MITB attack on one terminal 141 can be invalidated. That is, the user must match the information such as the transfer destination and transfer amount entered by the first terminal 141 with the information such as the transfer destination and transfer amount displayed on the second terminal 161. For example, it can be determined that an attack has occurred.
  • the user needs to confirm whether the content of the high-risk procedure input at the first terminal 141 matches the content of the high-risk procedure displayed at the second terminal 161. . Therefore, it is desirable to promote a comparison between the two in order to reduce the damage caused by MITB and other attacks.
  • the user is encouraged to sufficiently confirm the contents of the transaction displayed on the second terminal 161.
  • This embodiment can also be used in place of confirmation with a transaction password in a mode in which the second authentication is automatically performed.
  • FIG. 16 is a display example of a confirmation form displayed on the second terminal according to the embodiment of the present invention.
  • a description will be given with reference to FIG.
  • the details of the contents of the current transaction are displayed in the message field 462, but a part of the details is in a hidden form.
  • the part to be turned upside down may be any part of letters and numbers such as the name of the account holder of the transfer destination, the bank name, the branch name, and the account number.
  • the second terminal 161 randomly determines the place to be turned over.
  • buttons 464 are prepared.
  • one letter of the name of the account holder of the transfer destination is a hidden character (represented by “*” in this figure), and the answer to the hidden character is listed in the choice button 464.
  • the choice button 464 presented here includes one correct answer and a plurality of incorrect answers.
  • the second terminal 161 When the user selects the correct answer from the plurality of option buttons 464, the second terminal 161 considers that the user has confirmed and transmits a confirmation request to the server 121. If the answer is incorrect, a warning is displayed to review the contents of the transaction again, and the same confirmation form 461 is requested again.
  • a text field or a list box for the user to input the part that is turned upside down may be prepared, and a confirmation button 463 may be provided.
  • the confirmation button 463 is operated after the user selects the correct answer, a confirmation request is transmitted to the server 121.
  • the confirmation input is performed by the second terminal 161, but may be performed by the first terminal 141. This is because, in the present embodiment, it is guaranteed that the user has examined the contents of the transaction displayed on the second terminal 161 by causing the user to supplement the portion that has been turned over.
  • the second terminal 161 randomly determines the place of the hidden character, the correct answer is transmitted from the second terminal 161 to the server 121, or the answer input by the first terminal 141 is sent to the server 121. It is possible to adopt a technique such as transmitting to the second terminal 161 via the terminal and causing the second terminal 161 to make a determination.
  • the user logs in to the server 121 via the first terminal 141, and when the server 121 receives a transaction instruction from the user via the first terminal 141, the server notifies the second terminal of the notification to be transmitted. Is generated.
  • This notification specifies the details of the transaction (for example, the name of the transfer recipient, bank name, branch name, account type name, account number, and transfer amount). . For example, if you try to make a transaction with the bank name “ABC bank”, branch name “DEF store”, account type “GHI account”, account number “JKL”, holder “MNOP QRS” and transfer amount “TUVWXYZ Yen” The location (denoted by “*” below) is randomly determined and the following transaction content is generated.
  • a predetermined part for example, the last four digits of the account number
  • the server 121 transmits, to the second terminal 161 assigned to the user, a notification designating the content of the transaction partially hidden by the hidden character by e-mail or SMS.
  • the user who sees the contents of the transaction displayed on the second terminal 161 that has received the trap notification arranges the letters, numbers, and symbols that should be filled in the place of the hidden characters in order from the top, and uses this as the confirmation code.
  • the confirmation code is “BDJNSW”.
  • the user inputs a confirmation code into the first terminal 141. If the confirmation code input from the first terminal 141 matches the column in which the letters and numbers of the parts that were turned upside down when the notification was generated, the server 121 executes the transaction. It is assumed that there was confirmation to approve. In the simplest case, if there is a confirmation, the transaction may be executed by itself. That is, the second authentication using the transaction password can be omitted. This is because a part of the notification is hidden, so that, for example, if the location to be hidden is always selected from the account number, leakage of information called the account number can be prevented.
  • the confirmation code obtained from the hidden character is used, and the transaction is executed after further authentication by allowing the user to input the transaction password via the first terminal 141 or the second terminal 161. It's also good.
  • the transfer is canceled by operating the cancel button 424 from the first terminal 141, etc. be able to. If the transaction is unrecognized, the user name or password for login may be leaked, and the administrator of the server 121 is contacted.
  • the user registers his / her contact telephone number at the time of account contract. Then, the dedicated application is operated on the new second terminal 161 that is desired to be linked to its own account, and the user name and the login password are input.
  • the server 121 places a call to the contact telephone number of the user and transmits the registration authentication code by voice.
  • the server 121 When the user inputs an authentication code from a new dedicated application of the second terminal 161, the server 121 performs verification, and if this matches, the new second terminal 161 serves as the notification destination and the user's account. It is tied to.
  • the dedicated application in the second terminal 161 accesses the server 121 at the time of activation and notifies the server 121 that it is operating.
  • the server 121 receives a login request from the first terminal 141
  • the dedicated application is running on the second terminal 161 associated with the specified user name, and the password specified in the login request is valid.
  • the first authentication is successful and the user is allowed to log in.
  • a fixed login password can be adopted, and when the dedicated application of the second terminal 161 accesses the server 121, the random number table is acquired from the server 121, and the user can select from the random number table. It is also possible to obtain a one-time password obtained by extracting the contents of the cells based on the extraction rule assigned to the user, and use this as the login password.
  • the dedicated application when the user tries to execute the transaction, the dedicated application has already been operated on the second terminal 161, so that the server 121 also sends the notification as in the above embodiment. It can be transmitted to a dedicated application that has already been operated by the two terminals 161.
  • the transaction password and the input for confirming the transaction may be performed from the second terminal 161 or the first terminal 141 as described above.
  • a plurality of notification terminals can be assigned to a user.
  • a dedicated application is operated on the terminal, the server 121 is accessed, and then login is started via the first terminal 141. .
  • a certain notification terminal for example, a mobile phone that can be connected to a mobile phone communication network that is frequently used
  • another notification terminal for example, a tablet that can only be connected to Wifi
  • the confirmation code is 123456.
  • the part to be turned over is a bank name, branch name, name of a holder, etc.
  • the letters to be turned over may be relatively difficult to input, such as English letters, kana, or kanji.
  • the confirmation code since the confirmation code is generated by the server 121, the confirmation code can be configured to be of a character type that can be easily input at the first terminal 141 or the second terminal 161 (for example, only numbers as described above). , User convenience can be achieved.
  • the server 121 In the case where a notification is sent to the second terminal 161 composed of a mobile phone by e-mail and a confirmation code is input to the first terminal 141, the server 121 simply sends one confirmation code. It is difficult to prevent, and even if you send the contents of the transaction together, the MITB attack may succeed if the user does not scrutinize the contents. However, for the main unit, the content of the transaction will be scrutinized by the user, so that the MITB attack can be effectively prevented regardless of whether the input destination of the confirmation code is the first terminal 141 or the second terminal 161. Is possible.
  • a transaction system suitable for enhancing safety in a transaction system that requires first authentication for login to a server and requires second authentication for execution of a transaction instructed after login. it can.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un système de transaction (101) comprenant un serveur (121), un premier terminal (141) et un second terminal (161). Un utilisateur se connecte au serveur (121) par l'intermédiaire du premier terminal (141) par une première authentification réussie. Lors de la réception d'une instruction de transaction par l'utilisateur par l'intermédiaire du premier terminal (141), le serveur (121) génère une notification à transmettre au second terminal (161). Lorsque la notification est transmise par le serveur (121), le second terminal (161) tente une seconde authentification de l'utilisateur. Si la seconde authentification est réussie, le second terminal (161) présente des détails de transaction à l'utilisateur. Si la transaction est confirmée par l'utilisateur à qui il a été présenté les détails de la transaction, le serveur (121) exécute la transaction.
PCT/JP2014/064757 2014-06-03 2014-06-03 Système de transaction WO2015186195A1 (fr)

Priority Applications (8)

Application Number Priority Date Filing Date Title
JP2014547614A JP5670001B1 (ja) 2014-06-03 2014-06-03 取引システム、取引方法、ならびに、情報記録媒体
PCT/JP2014/064757 WO2015186195A1 (fr) 2014-06-03 2014-06-03 Système de transaction
US15/316,043 US11206266B2 (en) 2014-06-03 2015-01-21 Transaction system, transaction method, and information recording medium
JP2015512937A JP5750560B1 (ja) 2014-06-03 2015-01-21 取引システム、取引方法、ならびに、情報記録媒体
PCT/JP2015/051525 WO2015186372A1 (fr) 2014-06-03 2015-01-21 Système de transaction, procédé de transaction et support d'enregistrement d'informations
JP2015100634A JP6584824B2 (ja) 2014-06-03 2015-05-18 取引システム、取引方法、ならびに、情報記録媒体
US17/524,534 US11902283B2 (en) 2014-06-03 2021-11-11 Transaction system, transaction method, and information recording medium
US18/438,173 US20240187415A1 (en) 2014-06-03 2024-02-09 Transaction system, transaction method, and information recording medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2014/064757 WO2015186195A1 (fr) 2014-06-03 2014-06-03 Système de transaction

Publications (1)

Publication Number Publication Date
WO2015186195A1 true WO2015186195A1 (fr) 2015-12-10

Family

ID=52573833

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/JP2014/064757 WO2015186195A1 (fr) 2014-06-03 2014-06-03 Système de transaction
PCT/JP2015/051525 WO2015186372A1 (fr) 2014-06-03 2015-01-21 Système de transaction, procédé de transaction et support d'enregistrement d'informations

Family Applications After (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/051525 WO2015186372A1 (fr) 2014-06-03 2015-01-21 Système de transaction, procédé de transaction et support d'enregistrement d'informations

Country Status (2)

Country Link
JP (1) JP5670001B1 (fr)
WO (2) WO2015186195A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104821934B (zh) * 2015-03-20 2018-11-20 百度在线网络技术（北京）有限公司 基于人工智能的声纹登录方法和装置
JP2016206718A (ja) * 2015-04-15 2016-12-08 株式会社大和証券グループ本社 オンラインバンキングシステム、情報処理装置、ワンタイムパスワードの通知方法、及び、ワンタイムパスワードの通知プログラム
US20180211021A1 (en) * 2015-08-06 2018-07-26 Mitsubishi Electric Corporation Authentication device, authentication system, and authentication method

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007249726A (ja) * 2006-03-17 2007-09-27 Hitachi Software Eng Co Ltd 認証システム
JP2008197710A (ja) * 2007-02-08 2008-08-28 Nec Corp 認証方法およびシステム、携帯機器、認証サーバ、認証要求端末

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7021534B1 (en) * 2004-11-08 2006-04-04 Han Kiliccote Method and apparatus for providing secure document distribution
JP2007026039A (ja) * 2005-07-15 2007-02-01 Hitachi Information Technology Co Ltd 認証システム、認証方法、及び、認証プログラム
JP4700431B2 (ja) * 2005-07-27 2011-06-15 株式会社野村総合研究所 ユーザ認証装置及び方法
WO2010066304A1 (fr) * 2008-12-12 2010-06-17 Nec Europe Ltd. Dispositif de vérification mobile universelle
JP2011204169A (ja) * 2010-03-26 2011-10-13 Nomura Research Institute Ltd 認証システム、認証装置、認証方法および認証プログラム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007249726A (ja) * 2006-03-17 2007-09-27 Hitachi Software Eng Co Ltd 認証システム
JP2008197710A (ja) * 2007-02-08 2008-08-28 Nec Corp 認証方法およびシステム、携帯機器、認証サーバ、認証要求端末

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
NATSUKI ISHIDA: "Transaction-Synchronized One-Time Password Token Using Cellular Phone", FIT2007 DAI 6 KAI FORUM ON INFORMATION TECHNOLOGY IPPAN KOEN RONBUNSHU, SEPARATE VOL. 4 , NETWORK SECURITY UBIQUITOUS MOBILE COMPUTING KYOIKU JINBUNKAGAKU JOHO SYSTEM, FORUM ON INFORMATION TECHNOLOGY 2007, vol. 4, 22 August 2007 (2007-08-22), pages 125 - 126 *

Also Published As

Publication number Publication date
WO2015186372A1 (fr) 2015-12-10
JPWO2015186195A1 (ja) 2017-04-20
JP5670001B1 (ja) 2015-02-18

Similar Documents

Publication Publication Date Title
US10489789B1 (en) Systems and methods for providing notifications to devices
EP3230917B1 (fr) Système et procédé pour permettre une authentification sécurisée
US11902283B2 (en) Transaction system, transaction method, and information recording medium
JP5066827B2 (ja) 移動装置を用いる認証サービスのための方法及び装置
CN108229956A (zh) 网银交易方法、装置、系统以及移动终端
JP2014529964A (ja) モバイル機器経由の安全なトランザクション処理のシステムおよび方法
US20180130056A1 (en) Method and system for transaction security
CN110719252B (zh) 用于通过通信信道授权交易的方法、系统和介质
JP6584824B2 (ja) 取引システム、取引方法、ならびに、情報記録媒体
JP5670001B1 (ja) 取引システム、取引方法、ならびに、情報記録媒体
JP6325654B2 (ja) ネットワークサービス提供装置、ネットワークサービス提供方法、及びプログラム
JP6336383B2 (ja) 取引システム
EP3058526A1 (fr) Interface utilisateur sécurisée et écran tactile
JP5750560B1 (ja) 取引システム、取引方法、ならびに、情報記録媒体
JP2007065789A (ja) 認証システム及び方法
TW201516902A (zh) 交易確認方法與系統
WO2011060738A1 (fr) Procédé de confirmation de données dans une carte cpu
TWM575158U (zh) Financial system
JP2017219918A (ja) サービス提供システム、サービス提供方法、および、プログラム
KR20150065556A (ko) 다중 경로를 이용한 피싱 방지 방법 및 장치

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2014547614

Country of ref document: JP

Kind code of ref document: A

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14893942

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14893942

Country of ref document: EP

Kind code of ref document: A1