dCommunity EZ Authentication
Wallet - Authentication
dCommunity's goal is to meet companies wherever they are on the path to Web3 adoption—from exploring authentication options to fully integrating with a blockchain, dCommunity provides solutions that developers and enterprises alike can trust. The mission to onboard the next billion users to Web3 is real and will occur where Main Street meets Metaverse. We provide a foundation that streamlines how we address security at every aspect of the user journey.
Password leaks are prevalent.
Companies that have a database with passwords are a high-value target for hackers, who have successfully breached companies of all sizes.
Passwords are NOT the only way.
Passwords are only one (obsolete) way to handle authentication. dCommunity utilizes Magic one-time passcodes to grant access. Delivered through email, these passcodes are time-bound tokens that enable authentication without having to store and maintain passwords. The dCommunity partnership with Magic allows us to leverage cross-platform authentication for our products.
What about Phishing
Phishing is an ever-present threat on the internet.
Since the creation of the internet, hackers have leveraged phishing to direct victims to authentic-looking pages to attack them or steal their credentials. Hackers can craft incredibly realistic pages, utilize social engineering to entice victims to connect, and capture credentials for later use in direct attacks or credential-stuffing attacks elsewhere on the internet.
dCommunity's approach to phishing makes it more difficult.
The dCommunity approach to authentication makes phishing much more difficult. By using Magic's time-bound tokens, any credentials captured from successful phishing attacks have the same limited shelf life. Magic’s innovative approach to device registration for authentication, for customers who wish to take advantage of it, dramatically increases the difficulty of phishing attempts.
With no passwords, how do we determine identity?
The 'Magic' of public-private key pairs.
Once an end-user uses their time-bound token to establish a session with Magic, Magic generates a key pair based on the Ethereum blockchain. The public key acts as an identifier for the user. Leveraging elliptic curve cryptography, the private key is used to generate a verifiable proof of identification and authorization from a claim. The proof is then sent to the developer application servers where data in the claim can be recovered, and the authenticity of the request can be ensured.
Authentication and authorization are achieved without requiring user passwords. The claim format is an adaptation of the W3C Decentralized Identifiers (DID) protocol. Learn more about DiDs here.
Private keys can be lost or stolen. How do you protect my private key?
Patented key management.
With this public-private key-pair approach, it is critical to ensure that users' private keys are properly secured. This is what the patented (Patent US-11546321-B2) Delegated Key Management System (DKMS) was designed for. The DKMS dCommunity provides has secured millions of private keys for thousands of companies for years. By leveraging this DKMS, our secure private key management is backed by best-in-class cryptography standards.
How does DKMS work?
dCommunity provides infrastructure that manages the encrypted private keys. This encrypted key is shared with the user upon successful authentication. The user is then able to decrypt their encrypted private key with a user master key. Our Delegated Key Management architecture delegates critical encryption and decryption operations to trusted AWS Key Management Service (KMS) and AWS Cognito.
Wait, another encryption key. Can't that one get stolen?
Hardware Security Modules (HSMs)
Using Hardware Security Modules (HSMs) provided by AWS KMS. User master keys are stored on the HSMs, which are generated using AES-256 with 384 bits of entropy. The master keys never leave the hardware as they are meant to be locked inside and unable to be exported. Thus, all encryption and decryption operations happen inside the hardware itself. HSMs are similar to popular FIDO devices like YubiKeys or hardware-based crypto wallets such as Trezor or Ledger, except they are stored in the cloud, heavily secured by AWS’s data centers.
Users' private keys are encrypted by these hardware-based user master keys, which means that attackers need to gain access to this AWS-secured hardware to retrieve the keys and are forced to stay within the infrastructure - which enables detecting, impeding and monitoring an attacker's progress.
Not my key, Not my crypto
Client to AWS Data Flow
Users need to authenticate using the auth relayer to access their HSMs. Upon successful authentication, users receive a time-bound access token which is traded for scoped credentials that interact with AWS directly. The scoped credentials exclusively enable users to call AWS to access their master keys stored on the HSM for encryption and decryption. This mechanism, by design, bypasses the Magic backend entirely, and Magic cannot intercept the scoped credentials. Both access tokens and scoped credentials are created dynamically by AWS with audit logs and with TTLs enabled.
When a user signs up, a public-and-private key-pair is generated on the client-side for the user inside an iframe inaccessible by the integrated app. Keys are generated with cryptographically secure pseudo-random 256-bits of entropy. Once generated, the key is then encrypted by DKMS, where Magic never sees the raw private keys. After encryption of the keys with the HSM, the encrypted key is then uploaded to the Magic back end to be retrieved, decrypted, and used on the client side in future wallet operations.
When users authenticate again, the encrypted private key is downloaded to the client. Users can then decrypt the encrypted private key directly with AWS KMS via Cognito.
Last updated
