Directory Server Multifactor Authentication for Online Fraud Prevention

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current online transaction security methods are vulnerable to fraud, particularly through phishing, as they rely on additional verification steps that can be compromised when multiple third parties are involved in the communication process.

Innovation Solution

A multi-factor authentication method that involves obtaining a first identifier and cryptogram from a portable consumer device, forwarding them to a directory server for validation, and receiving a second identifier associated with the validated form, which is then used to complete the transaction securely, utilizing a merchant plug-in and access device to ensure authentication across the issuer, acquirer, and payment processing network.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If additional verification steps are implemented during online transactions, then transaction security is improved, but the complexity of the authentication process increases

Engineering Contradiction:
Improvetransaction securityVSAvoidauthentication process complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The authentication process is segmented into distinct phases: (1) obtaining the first identifier and cryptogram from the portable consumer device, (2) validating them through the directory server, and (3) receiving the second identifier. This segmentation allows each phase to be handled by appropriate system components, improving security while managing complexity through modular processing.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The directory server acts as an intermediary between the access device and the issuer. It receives the first identifier and cryptogram, performs validation, and issues the second identifier. This intermediary approach centralizes the complex validation logic in a dedicated server, simplifying the overall system architecture while maintaining high security standards.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If multiple third parties are involved in the communication process for verification, then authentication reliability is improved, but vulnerability to phishing attacks increases

Engineering Contradiction:
Improveauthentication reliabilityVSAvoidphishing vulnerability
Core Design Contradiction:
ReliabilityVSObject-affected harmful factors

Solution Approach 1:

The patent extracts the critical validation function from the complex multi-party communication process and places it in the directory server. By isolating the validation logic in this dedicated server, the system reduces the attack surface for phishing while maintaining the benefits of multi-party authentication through proper separation of concerns.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The system performs preliminary validation of the first identifier and cryptogram before completing the transaction. This preliminary action in the directory server ensures that authentication credentials are verified before being used in the actual transaction, preventing phishing attacks that occur during the verification process.

Inventive Principle:
Principle #10Preliminary action

3Measurement precision

If the full primary account number must be remembered by users, then authentication accuracy is improved, but user convenience deteriorates

Engineering Contradiction:
Improveauthentication accuracyVSAvoiduser convenience
Core Design Contradiction:
Measurement precisionVSEase of operation

Solution Approach 1:

The system uses a copy of the account identifier (the first identifier such as email or phone number) instead of requiring the full primary account number. This copy is sufficient for authentication purposes and is easier for users to remember, while the system maintains the security requirements through the cryptogram validation process.

Inventive Principle:
Principle #26Copying

Solution Approach 2:

The system changes the parameter used for authentication from the full primary account number to alternative identifiers (email, phone number) that are easier for users to remember. The validation process adapts to these parameter changes by validating the cryptogram against the provided identifier, maintaining security while improving user convenience.

Inventive Principle:
Principle #35Parameter changes

4Reliability

If additional authentication factors are required, then protection against card fraud is improved, but transaction processing time increases

Engineering Contradiction:
Improvefraud protectionVSAvoidtransaction processing time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The authentication process maintains continuous useful action by performing validation in the background through the directory server. The cryptogram validation occurs continuously as part of the transaction flow rather than as separate discrete steps, reducing overall processing time while maintaining comprehensive fraud protection through multiple authentication factors.

Inventive Principle:
Principle #20Continuity of useful action

Data Source

PatentUS11410169B2Multifactor authentication using a directory server
Publication Date: 2022.08.09 VISA INTERNATIONAL SERVICE ASSOCIATION
  • US11410169B2 patent drawing
  • US11410169B2 patent drawing
  • US11410169B2 patent drawing

AI summary

A method and a server computer are provided for authenticating a cardholder account. The server computer implements the method, which includes obtaining a first identifier and a cryptogram from a first entity, identifying an issuer associated with the cardholder account, forwarding the first account identifier and the cryptogram to a second entity for validation, receiving a second identifier from the second entity, and sending the second identifier to the first entity. The first identifier can be associated with the cardholder account. The second identifier can be generated by the second entity and associated with a validated form of the first identifier.