Non-intrusive Web 3.0 accounts: A SecureMeeting Perspective
Build a brighter future for the Web
Because accounts do not have to be intrusive
Hardly a day goes by that a site does not require you to create an account. The travesty of the current Web is that account creation always always leads to tracking and snooping. Yet, accounts are necessary in making scalable backend services happen.
In this article, we offer a perspective of how SecureMeeting handles account creation without being intrusive. Our hope is that this article helps other developers who firmly believe in preserving user privacy by wanting to build scalable back-end services that do not require people to give up their data.
Current Web 2.0 Account
Centralized, intrusive, and ripe for abuse
Web 2.0 accounts typically involve a username and password to prove your ownership. This leads to several vulnerabilities in which an attacker can break into your account. A few of these vulnerabilities are leaked passwords, keyloggers, database breaches, phishing websites, and so many more (Read more about how accounts make your site less secure).
These flaws aside, many portals defer to a Google or Facebook login. This kills transparency. The whole Web 3.0 movement is to put an end to the online monopoly of these big corps. Our advice? Avoid them altogether.
Web 2.0 account vulnerabilities in general lead to billions of accounts being hacked every single year. Nobody wants hackers getting access to your accounts, but we also forget the websites we sign up on also have access to our accounts. Entire companies, such as Facebook, are built on the collection of this user data and profiting off of it by selling it. This means that even if we are the only ones with the username and password, the data we generate is not truly ours.
How to use Web 3.0 compliant accounts
Broadly speaking, a Web 3.0 compliant website relies on decentralized systems to solve account vulnerabilities. The gold standard is to create your own blockchain and accounts thereof. But if you are just starting out, this is obviously not worth your time since building a chain from scratch is not a trivial undertaking. An easier alternative then is to work off of an existing chain like Ethereum.
We will first introduce and explain the technologies we use to secure an account.
#1 Account Creation. The first aspect of an account is creating and gaining access to it. We use Ethereum wallets for this process. An Ethereum wallet is software or hardware that allows a user to interact with the Ethereum blockchain. Every wallet has an Ethereum address, also known as a public key, which is a public string of letters and numbers that start with “0x”. These wallets can be seen publicly on the Ethereum blockchain, but the ownership of each wallet is anonymous. Every Ethereum wallet also has a private key or a “password” that is specific to the wallet and is not publicly known. In SecureMeeting we currently support Metamask and Fortmatic as Ethereum wallet providers with plans to include other wallet providers in the future as well as hardware wallets.
#2 Data Storage & Retrieval. The second aspect of an account is how the data is stored to be retrieved on a successful login. We use IPFS, also known as InterPlanetary File System as our database for user data. IPFS is a protocol and peer-to-peer network for storing and sharing data in a distributed file system. When you add a file to IPFS, your file is split into smaller chunks, cryptographically hashed, and given a unique fingerprint called a content identifier (CID). This CID acts as a permanent record of your file as it exists at that point in time. It can be thought of as instructions for how to decrypt and reconstruct your file in IPFS.
How our Accounts work
Using the two technologies above, we have developed a decentralized process that makes the login not only easy but also extremely secure. The first part of the process starts with calling our authentication API with your public key. We save this in a record in MongoDB that contains your CID and public key. Our authentication API then returns your CID by finding the record that has your public key. Once we have your CID we pass this onto IPFS to get your account from IPFS.
When IPFS gets your CID it then goes to multiple clusters, grabs different parts of your account, decrypts them, and reconstructs your account, and returns to the user the account. This account that is returned from IPFS was encrypted before saving it so at this point your account is reconstructed, but still encrypted. Once the user finally gets this data back, the user is prompted with a signature request to use the private key of the wallet to decrypt the account. Once the user agrees and signs, their private key is used to decrypt the account and then the user finally has access to their data which can be used across SecureMeeting.
The signup process on SecureMeeting works very similarly to the login process. We first get the account data you provide upon signup and build an account. Once we build this account the wallet provider will prompt the user with a signature request to use the wallet’s private key. Once the user agrees and signs, we use their private key to encrypt the account. We then send this account to be saved in IPFS where they break up the account, encrypt the account again, and store it on multiple clusters, then return a CID. Since we need this CID to reconstruct the account, we then send both the CID and public key to our authentication microservice where we save this pair in MongoDb to be used in the future to log in.
Benefits
The benefits of this login process are that first, it’s passwordless. Having no passwords helps prevent your account from being hacked like on traditional websites. There is also no need for two-factor authentication, making it quicker for you to log in to your accounts. The other benefit is that by utilizing the Ethereum wallet’s private and public keys, it is much easier to encrypt and decrypt user data as we have the keys stored directly on your device. The login process also makes you the true owner of your data as it is impossible for us to see your account data. While we do have the CID to your account, we would still need your private key to decrypt the account once IPFS returns the account. We NEVER store your private key anywhere so you are the only owner of the private key — we just can’t do it.
Downsides
While the account creation and login system sounds awesome from the user’s perspective, it poses some challenges for the developers. The major challenge is that we can not access your account data. While this is the point of our system, it makes it difficult to do basic things like sending a friend request by email or name. Another problem is that we are used to having the same accounts across multiple devices and platforms. While this can still exist with some hardware wallets and some Ethereum wallet providers, providers such as Metamask are dependent on browser and device. This means that if you’re using Metamask you will not be able to log in to your account on multiple laptops.
SecureMeeting
SecureMeeting is on a mission is to advance human rights and freedom of speech. We do this by designing, developing and deploying planetary-scale, privacy-preserving communications architectures for all of mankind.
We are a US 501(c)(3) non-profit.
Send us a note, we’d love to hear from you: hello@securemeeting.org
