Magic is a passwordless authentication system. It starts with “magic links,” where you’re e-mailed a login link instead of providing the usual username and password. Magic makes it quick and easy for developers to implement this model in any application. But behind the scenes, you’ll find a robust security platform built on secure hardware and user-owned encryption that paves the way for broader adoption of Web 3.0 technologies.
Magic’s security overview does a great job of describing the security guarantees of the service, but here’s a quick summary. Normally, an application stores both your username and password and authenticates you internally. This is a huge security flaw because it means anybody who breaks into the application’s servers can potentially break into all accounts. And by storing both your username and password the service operator has effective control of all your data even if everything is encrypted internally. Magic also points out that “81% of all breaches are due to passwords, and 59% of people reuse their passwords everywhere”. So the failure of one service often cascades into other breaches.
An account in Magic is actually a unique cryptographic public/private key pair instead of the usual credentials. The public key is like a username (safe to share) and the private key is like a password (which must be kept safe). These come with two important features. First, the owner of a key pair can digitally sign any data in a way that others can verify its authenticity using the public key because only the holder of a private key can create a valid digital signature corresponding to that public key. Second, you can encrypt data such that only the owner of the private key can decrypt it.
Apps that use Magic authentication see your public key but never your private key. When you sign up, Magic generates a unique key pair on your device, specific to that application. When you log in, Magic has your device create a DID-compliant signature using the corresponding keys, and forwards it to the application. If the signature matches the public key, you’re in. No passwords.
Critically, Magic itself cannot see or access your private keys either. User keys are stored in dedicated hardware security modules (HSM) in specialized AWS centers. Each account has a dedicated HSM instance that only the user’s devices can access. Magic’s SDK manages the client-side flow of transactions between your devices, your HSM, and the application’s servers without exposing the private key. They do store encrypted copies of private keys for backup and recovery, but again only the user’s devices can decrypt them. It’s like having your own hardware wallet in the cloud.
Magic’s Delegated Key Management System
This setup is far more secure because there isn’t a single point of attack or control. The app has the user’s data, but not their keys. Magic has some contextual metadata about accounts and services, but not the user’s raw keys or data. AWS has the keys, but not the user’s data or the context of what the keys are for. To compromise an account, hacker would have to break into all of those at the same time.
Magic also generates unique key pairs for each account, so user identities across services are segregated. To steal information, even if an attacker managed to break into the app, Magic, and AWS, they could only try to brute force one account at a time, and they would have to remain online within all of those adversarial environments while they do it. So it’s hard enough to compromise a single account, let alone conduct a wholesale attack like it usually happens. This is a much higher standard of security, privacy, and trust than what you get with traditional authentication models without sacrificing user experience.
No developer should be surprised that key-based authentication beats passwords. These cryptographic standards have been around for a long time, and are frequently used behind the scenes in state-of-the-art setups. But the problem when it comes to consumer deployments has always been the user experience and the safekeeping of private keys. Cryptographic keys are computer-generated, long strings of text that can’t be changed, so they’re hard for users to work with. And it can be very difficult, often impossible, to recover from loss or theft of a private key.
Magic solves that problem. To start, it smoothes the experience by using email links. Email links are great for onboarding at the top of the funnel by piggybacking on the existing security of the user’s inbox, for which they are already responsible. The background is more sophisticated: when you click the link, Magic performs a variety of security checks (e.g. IP address, device profile, etc.) before triggering a signature. Over time, they’ll guide users to upgrade their setup with second factors like a security keys. In addition, developers will soon be able to complement or skip e-mail altogether using WebAuthn and even a mobile app to authenticate by simply plugging in a YubiKey or responding to a notification instead of clicking a link, adding several layers of security.
With Magic, neither users nor developers have to think or worry about managing keys. It’s also worth noting Magic builds on top of open standards to eliminate lock-in. Users can always export their private keys – and thus, their identity and control over their data. And developers can replace Magic’s SDK with another system that follows the same standard, and maintain the same functionality. In other words, it’s a portable identity model where users retain control over their data, and developers control over their applications.
Magic offers an authentication service that’s far more secure for users and much cheaper for developers and businesses. That’s a big win based on a clear economic value proposition. But more interesting is how key-based authentication can help us create a more private, decentralized web. Encryption enables data privacy, while signatures enable data verification. In an environment where every user account is represented by a key pair, these two features are enabled by default. Developers can use these features to create more private and trusted services.
Magic brings the principles of crypto service models to all online services by making it easier to create applications that don’t know anything about the user because their data is encrypted, and don’t have custody over the data because they don’t have the keys. Apps can encrypt your data with Magic such that only you can read it, or they can combine multiple keys so that only a specific group can use it. Besides creating more private and secure applications, there are major economic benefits for developers. These zero-knowledge, non-custodial services can save a lot of costs by eliminating the liability of holding user data, which can turn into real competitive advantages against web applications that have all of the knowledge, and all of the control.
Signatures are equally important because they allow the public to verify the authenticity of information. If you know my public key and I sign some data (like an e-mail or a file) with the matching private key, you can verify the legitimacy of that signature, and be sure the information came directly from me and hasn’t been tampered with. With Magic, developers can build services that leverage signatures to authenticate information. Every piece of content on the internet – articles, tweets, comments, photos, emails, PDFs, etc. – should come with a digital signature attached to verify its origin and authenticity. Even user interactions like upvotes and comments could be signed. So much damage comes from unauthenticated information; it should be obvious that digital signatures are a key part of the solution.
The encryption and signature features of key-based authentication address the two most critical, structural issues with today’s web: the insecurity of private data, and the fast spread of unverified information. Magic takes it further by adding a third primitive: transactions. Magic started out as Fortmatic, one of the most popular hosted Ethereum wallet providers. Today, it is used by hundreds of dapps to secure over 50,000 wallets. Magic includes that functionality by attaching an Ethereum wallet to the user’s keys, so each account can hold and transact in crypto as well as interact with smart contract systems. Magic will soon support other blockchains like Bitcoin, Tezos, and Flow.
Native compatibility with blockchain protocols opens a world of potential functionality for new kinds of applications. This allows developers to create applications that are natively integrated with the growing ecosystem of blockchain cryptocurrencies, smart contracts, finance protocols, and digital organizations –– all the way to virtual worlds and digital goods. The wallets Magic generates are not meant to be the user’s primary wallet, but a bridge that allows developers to get creative with the implementation.
For example, you could use the Gnosis multi-sig contracts to create a multi-factor identity scheme where a Magic account is one of the signatories or leverage Aragon DAO contracts to create apps that interact with digital organizations. You could integrate Erasure to build a data marketplace into your app, create custom Ethereum tokens for users like Reddit is doing with its Ethereum experiment. It’s a wide-open space for innovation.
We’re heading to a world where applications need to be more secure, users take back control of their data, and nobody is locked into predatory relationships with service providers. Magic enables that world by separating the keys from the application and helping developers leverage digital signatures, encryption, and blockchain transactions. But the real magic happens when creative companies combine all of this new functionality to create new business model opportunities. We can’t wait to see what developers build with these new tools, and are excited to be working with the Magic team on their mission to create a more authentic web.