Authentication Server Cryptogram Validation for Secure Transactions

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current payment systems in multi-server environments, such as online marketplaces, are vulnerable to security risks like man-in-the-middle attacks and fraud due to the sharing of static payment tokens across multiple servers, which can lead to illegitimate transactions and loss of trust among issuers.

Innovation Solution

A computer-implemented method and system that generates a cryptogram at an authentication server, validated with a unique merchant identifier and secret, ensuring only authorized transactions are approved, thereby enhancing security by preventing unauthorized access and misuse of payment tokens.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If payment tokens are shared across multiple servers to enable transactions in multi-server environments, then transaction capability and versatility are improved, but security is worsened due to vulnerability to man-in-the-middle attacks and fraud

Engineering Contradiction:
Improvetransaction capabilityVSAvoidsecurity
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The patent segments the payment authentication process into distinct components: a requestor server that obtains cryptograms, a merchant server that validates them, and an authentication server that maintains secure merchant identifier and secret pairs. This segmentation ensures that no single server holds all authentication credentials, reducing the impact of any single point of failure or compromise.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The authentication server acts as an intermediary between requestor servers and merchant servers, validating cryptograms against stored merchant identifier-secret pairs. This intermediary role ensures that payment tokens are not directly shared between requestor and merchant servers, but rather validated through a secure authentication layer that prevents man-in-the-middle attacks.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If dynamic payment credentials are used to reduce fraud risk, then security is improved, but complexity of the authentication system is worsened due to multiple validation steps and secure communication requirements

Engineering Contradiction:
ImprovesecurityVSAvoidauthentication system complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system performs preliminary actions by pre-storing unique merchant identifier-secret pairs in the authentication server's database before transactions occur. This allows the authentication server to quickly validate cryptograms against pre-established credentials without requiring complex real-time authentication protocols, reducing operational complexity while maintaining security.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent utilizes parameter changes by generating unique cryptograms for each transaction and validating them against changing merchant identifiers and secrets. This dynamic parameter validation ensures that even if communication channels are intercepted, the transaction cannot be replicated, reducing fraud risk while maintaining a relatively simple validation process.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS11734683B2Authentication for secure transactions in a multi-server environment
Publication Date: 2023.08.22 MASTERCARD INT INC
  • US11734683B2 patent drawing
  • US11734683B2 patent drawing
  • US11734683B2 patent drawing

AI summary

Disclosed herein is a computer implemented method for providing authentication for secure transactions in a multi-server system, the method comprising; receiving, at an authentication server from a requestor server, a request for a cryptogram, the request being associated with a transaction and including a requestor identifier; in response to receiving the request, generating a cryptogram; sending, from the authentication server, the cryptogram to the requestor server; receiving, at the authentication server from a merchant server, the cryptogram, a payment token, and a unique merchant identifier, and a merchant secret; validating, at the authentication server, the cryptogram; comparing, at the authentication server, the unique merchant identifier and the merchant secret with a unique merchant identifier and a merchant secret pair stored in a database; and authorizing, at the authentication server, the transaction when there is a match.