Security at Decentraland

Keeping our community safe

The cryptocurrency space has attracted a lot of attention from people using their technical skills to try to get their hands on some cryptocurrency. In this post, we share some of the measures we took to protect our users’ privacy, as well as the overall security of the operation, while planning and executing Decentraland’s MANA crowdsale.

The Checklist

A security roundup is a PITA for all persons involved in the project, but the alternatives are too risky. Complying with a thorough security checklist drastically lowers exposure to attack vectors and is a requirement for any project going through this process. Our goal was to protect from “groups” using social attacks, 0-day and N-day exploits that might launch their ammunition against us.

Our security checklist and operational policy included:

• Restrict access: Establish a need-to-have policy in place to grant access to any services. Pay special attention to the most important ones, like email lists, domain registrars, e-mail accounts and administration. These services should be using hardware 2FA, and in case that’s not an option, 2FA with a mobile phone using a brand new phone line that was acquired for this purpose alone.
• Password management: Do not repeat passwords for the most important services, and use a password manager for services that are not that important. Never reuse passwords. Personal accounts are as important as institutional accounts.
• Keep all software up to date: Android phones are usually more vulnerable than iPhones, so prevent moderators of group chats and team members with access to critical services from using old Androids.
• Don’t share needles: don’t plug in other people’s USB devices.
• Be cautious at hotels: When traveling, ask for hotel rooms with ethernet and connect behind a Raspberry Pi running https://github.com/pi-hole/pi-hole, equipped with a custom blacklist, a bridge to exit through a VPN service, and encrypted DNS resolution.
• Use only a Chromebook to connect when a safe access point is not available.
• Set up honeypot accounts in Slack (and make them look active) to guard against scam attacks sending Slackbot reminders or private messages.
• Wipe all disks (or buy new computers), install a clean and up to date OS, and have a zero-tolerance policy for running unknown or unsigned binaries.
• Call your mobile phone provider to set up a pin number to activate any kind of call or SMS forwarding. Even with this in place, remove your phone number as a recovery mechanism in personal and business email addresses.
• Enable 2FA in all services. Use the FIDO option for Google. Use a hardware-based 2FA whenever possible for the most exposed individuals. Did you know that OpenSSH can be configured to require a OpenPGP signature? A hardware device like the YubiKey can provide this signature.

The Whitelist

We created a secure whitelist of emails and Ethereum addresses that our engineering team is proud of. Our first attempt was using a Google form that allowed users to submit their emails and Ethereum addresses. The result sheet created by this form was only accessible by two users: Franco Zeoli, our friend and former marketing lead (a highly technical and security-oriented professional), and myself. Both Google accounts were highly secured, as described in the previous section.

But this was not enough: Google forms are banned in some countries, and there’s also the potential for this whitelist to be leaked in case one of our computers is compromised. Additionally, users wanted to check whether they were included in the list, and some asked to change the Ethereum address they signed up with. We also wanted to add more users to this list.

We decided against storing the email list in any kind of server. All systems have bugs, and we wanted to protect even against somebody getting access to our database. This is a pretty high level of security, and we are currently not aware of other projects doing something similar (if you are, please reach out! I would love to share notes).

We only stored in our database a simple mapping from a hash of the email (using scrypt) to an Ethereum address. Emails in clear text are only temporarily stored in the server’s RAM and within our email providers. For the three operations that we support, the output is always an email to the requester to avoid information leaks in the HTTP response. We are also not sending a non-confirmation email to avoid contacting people who may have never requested our emails. Whenever a confirmation email is needed, the email is included in clear text in the email’s body to avoid having to store it in the database (this way, all information is accessible when needed and it only lives in storage outside of our perimeter). Additionally, logs are kept on a third party service.

The Community contributions list

We have a Github community program where community members can propose ideas for the future of Decentraland. We have a list of how much to reward everyone, but we don’t want users to have their Ethereum address linked to their GitHub name. A version of this list, with all entries sorted alphabetically, was exposed to them so they can check how much will they receive.

Cryptocurrency Safety

We took all these measures because we care deeply for the safety of our users. Given the sheer number of scams that targeted our community and other crypto projects, we consider carefully and double check any communication that comes out of our public channels, and evaluate how a group impersonating us could use a similarly crafted message to try to run a scam.

If you have any comments on our setup, or need references to professionals that can help run your operation securely, please contact us at security@decentraland.org.