Off-Chain Push-Mode Multi-Factor Authentication for Blockchain Services
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current 2FA mechanisms in Web3 cannot be adopted due to the need for secret information to be publicly accessible in the blockchain, and existing solutions like US11025431B2 lack security as they rely on a second wallet that can be compromised by hackers accessing the wallet management software.
Innovation Solution
A push-mode multi-factor authentication system that uses an off-chain approach, where the multi-factor authorization account ID is stored separately from the blockchain, allowing for secure multi-factor authorization without exposing user personal information, and integrates with existing push-mode multi-factor authorization providers.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If secret information is stored in the blockchain for 2FA, then the smart contract can verify authentication, but user privacy is compromised as all data becomes publicly accessible
Solution Approach 1:
The authentication system is segmented into on-chain components (smart contracts for verification logic) and off-chain components (secret information storage). The secret information is divided into multiple parts and stored in decentralized storage, while only verification hashes are stored on the blockchain. This segmentation allows verification without exposing sensitive data.
Solution Approach 2:
A decentralized storage network acts as an intermediary between the blockchain and the secret information. The smart contract interacts with this intermediary to verify authentication without directly accessing or storing secret information. The intermediary translates verification requests into secure operations while maintaining privacy.
2Reliability
If a second wallet is used for 2FA as in existing solutions, then multi-factor authentication is achieved, but security is reduced as hackers can access wallet management software to steal both wallets
Solution Approach 1:
The secret information for the second factor is extracted from the wallet ecosystem entirely. Instead of using a second wallet that could be compromised through software vulnerabilities, the system stores secret information in decentralized storage and uses cryptographic verification that does not require private keys. This extraction eliminates the attack vector of stealing wallet management software.
Solution Approach 2:
The system uses cryptographic copies (hashes and signatures) of the secret information rather than the actual secret itself. The smart contract verifies authentication by checking cryptographic proofs without ever handling or storing the actual secret information. This copying approach maintains security even when verification data is stored on-chain.
3Reliability
If pull-mode 2FA is used where users must actively provide authentication, then security is maintained, but user interaction complexity increases
Solution Approach 1:
The authentication system operates in push-mode where the user's authentication status is automatically verified by the smart contract without requiring active user participation. The system self-serve by continuously maintaining the authentication state and automatically verifying it during transactions. This reduces user interaction while maintaining security through the underlying cryptographic verification.
Data Source
Figure 1
Figure 2
AI summary
A method and a system for multi-factor authentication for blockchain services, the method comprising holding, by an authentication server, an account of an end-user identifiable via an accountlD; establishing, by the end-user, a multi-factor approval status in the server; and in response to an operation to be performed in a customer smart contract, the latter interacting with the server to confirm the established multi-factor approval status. The interacting step comprises checking whether a mapping between a public key and the accountID exists; calling a function in SDK and performing an in-chain call to a function OracleRequest; performing a gas payment and emitting an event with the accountID and an integer as parameter; executing a task identified by the integer, the task performing an API call to an oracle interaction backend that further calls a checkstatus API; performing a call to a function fullfillOracleRequest2, and further propagating the established multi-factor approval status to the customer smart contract.