System and method for secure transaction process via mobile device

• US 10,108,963 B2
• Filed: 10/10/2014
• Issued: 10/23/2018
• Est. Priority Date: 04/10/2012
• Status: Active Grant

• Current Assignee: Ping Identity Corporation
• Original Assignee: Ping Identity Corporation
• Inventors: Weiner, Avish Jacob, Ne'man, Ran
• Primary Examiner(s): Obeid, Mamon
• Application Number:
  US14/511,751
• Publication Number:
  US 20150073992A1
• Time in Patent Office: 1,474 Days
• Field of Search: 705 64
• CPC Class Codes: G06Q 20/3223 Realising banking transactions through M-devices
• CPC Class Codes: G06Q 20/3278 RFID or NFC payments by means of M-devices
• CPC Class Codes: G06Q 20/40 Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
• CPC Class Codes: G06Q 20/425 using two different networks, one for transaction and one for security confirmation
• CPC Class Codes: H04L 63/083 using passwords cryptographic mechanisms or cryptographic arrangements for entity authentication using a predetermined code H04L9/3226
• CPC Class Codes: H04W 12/068 using credential vaults, e.g. password manager applications or one time password [OTP] applications

Abstract

A system providing enhanced security for device based transactions, constituted of:

• • a server associated with a network address; a first device associated with a user, the first device in communication with the server over a first communication channel responsive to an obtained server network address; a second device associated with the user arranged to obtain the server network address from the first device; and a mobile device server in communication with the second device over a second communication channel, the mobile device server in communication with the server via a third communication channel, the mobile device server arranged to: obtain the server network address from the second device over the second communication channel; obtain the server network address from a trusted source; and authorize to the server over third communication channel a transaction only in the event that the server network addresses are consonant.

Claims

1. An apparatus, comprising:

a mobile device server (MDS) including a processor and associated with a memory, the MDS configured to;

be operably coupled to a provider server that communicates with a registered user device (RUD) on a first band during a time period, the RUD being registered with the MDS prior to the time period;

receive, from the provider server, a transaction authorization request including user identification and to authorize a user access from the RUD to a resource associated with the provider server;

based on the user identification, retrieve, from the memory, a registered user device identifier associated with the user identification and identifying the RUD;

generate a notification for the RUD including (1) a generated session identifier (SID) and (2) a prompt to connect to the MDS via a second band;

send, via a notification server, the notification to the RUD such that the RUD, in response to receiving the notification, sends to the MDS a response;

receive, from the RUD, the response including a received SID;

complete an out of band (OOB) supervision approval and authenticate the RUD by determining that the received SID matches the generated SID;

send, to the RUD and via the second band, an information query;

receive, in response to the information query and via the second band, information generated by the RUD;

complete the transaction authorization request based on (1) the completing the OOB supervision approval and the authenticating the RUD, and (2) verifying at least one factor based on the information generated by the RUD and predefined stored information; and

based on the completing the transaction authorization request, send, to the provider server, a signal representing an approval of the transaction authorization request to authorize access to the resource from the RUD.

2. The apparatus of claim 1, wherein the MDS is further configured to receive, in response to the information query, a user-provided input received at the RUD,

the MDS configured to complete the transaction authorization request based at least in part on the user-provided input received at the RUD.

3. The apparatus of claim 1, wherein the RUD is a user mobile device.

4. The apparatus of claim 1, wherein the RUD is one of a laptop user device, a tablet user device, a personal digital assistant (PDA) user device, or a desktop user device.

5. The apparatus of claim 1, wherein the prompt causes the RUD to automatically connect with the MDS via the second band and without an intervention of the user.

6. The apparatus of claim 1, wherein the MDS authenticates the RUD via a registered application that is executable on the RUD.

7. The apparatus of claim 1, wherein the information query includes a cryptographic mutual authentication between the RUD and the MDS.

8. The apparatus of claim 1, wherein the information generated by the RUD includes at least one of an internet protocol (IP) network address of the provider server, a hardware fingerprint associated with the RUD, a software fingerprint associated with the RUD, a digital fingerprint, a digital signature, server dynamic fingerprint information, or location information.

9. The apparatus of claim 1, wherein the prompt causes an application executable on the RUD and associated with the MDS to become active.

10. The apparatus of claim 1, wherein the information query includes information associated with the user identification to authenticate the user.

11. The apparatus of claim 1, wherein the MDS is configured to communicate with the notification server via a communication that is secured by a certificate, and the notification server is configured to communicate with the RUD via a communication that is secured by a token.

12. The apparatus of claim 1, wherein the information generated by the RUD includes at least one active network Internet Protocol (IP) address, the predefined stored information includes a network IP address of the provider server, and the MDS is further configured to (1) detect that the provider server is communicating with the RUD and (2) detect that there is no man-in-the-middle (MITM) attack associated with the transaction authorization request, when the at least one active network IP address matches the network IP address of the provider server.

13. The apparatus of claim 1, wherein the transaction authorization request is a first transaction authorization request, the information generated by the RUD includes at least one active network Internet Protocol (IP) address, the predefined stored information includes a network IP address of the provider server, and the MDS is further configured to:

receive, from the provider server communicating with a user device different from the RUD, a second transaction authorization request to authorize the user access from the user device to the resource associated with the provider server;

detect that the user device is one of an unregistered user device (UUD) or a fraudster device when the at least one active network IP address received from the RUD does not match the network IP address of the provider server based on the predefined stored information;

in response to the detecting that the user device is one of a UUD or a fraudster device, send an additional information query to the RUD that requests the user to approve or deny the transaction authorization request;

when an approval is received from the user, detect that the user device is a UUD and send to the provider server a signal representing an approval of the second transaction authorization request to authorize access to the resource from the UUD; and

when a denial is received from the user, detect that the user device is a fraudster device and send to the provider server a signal representing a denial of the second transaction authorization request.

14. The apparatus of claim 1, wherein the MDS is configured to receive the transaction authorization request based on the provider server sending the transaction authorization request in response to a login request from the RUD.

15. A method, comprising:

receiving, from a provider server and at a mobile device server (MDS) operatively coupled to the provider server that communicates with a registered user device (RUD) on a first band during a time period, a transaction authorization request (1) including user identification and (2) to authorize a user access from the RUD to a resource associated with the provider server, the RUD being registered with the MDS prior to the time period;

based on the user identification, retrieving, at the MDS and from a memory associated with the MDS, a registered user device identifier associated with the user identification and identifying the RUD;

generating, at the MDS, a notification for the RUD including (1) a generated session identifier (SID) and (2) a prompt to connect to the MDS via a second band;

sending, from the MDS via a notification server, the notification to the RUD such that the RUD, in response to receiving the notification, sends to the MDS a response;

receiving, at the MDS and from the RUD, the response including a received SID;

completing, at the MDS, an out of band (OOB) supervision approval and authenticating the RUD by determining that the received SID matches the generated SID;

sending, to the RUD and via the second band, an information query;

receiving, in response to the information query and at the MDS via the second band, information generated by the RUD;

completing, at the MDS, the transaction authorization request based on (1) the completing the OOB supervision approval and the authenticating the RUD, and (2) verifying at least one factor based on the information generated by the RUD and predefined stored information; and

based on the completing the transaction authorization request, sending, from the MDS to the provider server, a signal representing an approval of the transaction authorization request to authorize access to the resource from the RUD.

16. The method of claim 15, further comprising:

receiving, at the MDS, and in response to the information query, a user-provided input received at the RUD,

the completing the transaction authorization request based at least in part on the user-provided input received at the RUD.

17. The method of claim 15, wherein the RUD is a user mobile device.

18. The method of claim 15, wherein the RUD is one of a laptop user device, a tablet user device, a personal digital assistant (PDA) user device, or a desktop user device.

19. The method of claim 15, wherein the prompt causes the RUD to automatically connect with the MDS via the second band and without an intervention of the user.

20. The method of claim 15, further comprising registering, prior to the time period, the RUD via a registered application that is executable on the RUD.

21. The method of claim 15, wherein the information query includes a cryptographic mutual authentication between the RUD and the MDS.

22. The method of claim 15, wherein the information generated by the RUD includes at least one of an internet protocol (IP) network address of the provider server, a hardware fingerprint associated with the RUD, a software fingerprint associated with the RUD, a digital fingerprint, a digital signature, server dynamic fingerprint information, or location information.

23. The method of claim 15, wherein the prompt causes an application executable on the RUD and associated with the MDS to become active.

24. The method of claim 15, wherein the information query includes information associated with the user identification to authenticate the user.

25. The method of claim 15, wherein the MDS is configured to communicate with the notification server via a communication that is secured by a certificate, and the notification server is configured to communicate with the RUD via a communication that is secured by a token.

26. The method of claim 15, wherein the information generated by the RUD includes at least one active network Internet Protocol (IP) address, the predefined stored information includes a network IP address of the provider server, the method further comprising:

detecting that (1) the provider server is communicating with the RUD and (2) there is no man-in-the-middle (MITM) attack associated with the transaction authorization request, when the at least one active network IP address matches the network IP address of the provider server.

27. The method of claim 15, wherein the transaction authorization request is a first transaction authorization request, the information generated by the RUD includes at least one active network Internet Protocol (IP) address, and the predefined stored information includes a network IP address of the provider server, the method further comprising:

receiving, from the provider server communicating with a user device different from the RUD, a second transaction authorization request to authorize the user access from the user device to the resource associated with the provider server;

detecting that the user device is one of an unregistered user device (UUD) or a fraudster device when the at least one active network IP address received from the RUD does not match the network IP address of the provider server based on the predefined stored information;

in response to the detecting that the user device is one of a UUD or a fraudster device, sending an additional information query to the RUD that requests the user to approve or deny the transaction authorization request;

when an approval is received from the user, detecting that the user device is a UUD and sending to the provider server a signal representing an approval of the second transaction authorization request to authorize access to the resource from the UUD; and

when a denial is received from the user, detecting that the user device is a fraudster device and sending to the provider server a signal representing a denial of the second transaction authorization request.

28. The method of claim 15, wherein the receiving the transaction authorization request is based on the provider server sending the transaction authorization request in response to a login request from the RUD.