The Dropbox Security Team is responsible for securing over 500 petabytes of data belonging to over half a billion registered users across hundreds of thousands of businesses. Securing data at this scale requires a security team that is not only well-resourced, but also one that can keep ahead of the expansion of our platform. We focus on scaling our own leverage, so each new security person we add multiplies the impact of our team.
Over the course of this year—and beyond—we’ll go into more detail on how Dropbox approaches security and some of the projects we’ve tackled. Protecting Dropbox requires serious investments in security.
We first launched our bug bounty program in 2014, with initial bounties for critical bugs in the range of $5,000, ramping up to (currently) over $10,000 for critical bugs. Over the past three years, leading security researchers from around the world have participated in our programs with some amazing, often original research. Beyond just the individual bugs, we have learned many a lesson, uncovering unique, interesting threats, exploit vectors, and new research as well as rejigged our priorities based on the bug bounty reports. From Dropbox and all our users, a big THANK YOU to all the researchers that help secure Dropbox for our users!
Our comms team told us we need an image; our legal team told us it needed to be freely licensed. Credit: Carsten Schertzer (Creative Commons Attribution 2.0)
Dropbox employs traditional cross-site attack defenses, but we also employ same-site cookies as a defense in depth on newer browsers. In this post, we describe how we rolled out same-site cookie based defenses on Dropbox, and offer some guidelines on how you can do the same on your website.
Recently, the IETF released a new RFC introducing same-site cookies.
Security incidents happen. And when they do, they need to be dealt with—quickly. That’s where detection comes into play. The faster incidents are detected, the faster they can be handed off to the security team and resolved. To make detection as fast as possible, teams are usually aided by monitoring infrastructure that fires off an alert any time something even slightly questionable occurs. These alerts can lead to a deluge of information, making it difficult for engineers to sift through. Even worse, a large number of these alerts are false positives, caused by engineers arbitrarily running
It’s universally acknowledged that it’s a bad idea to store plain-text passwords. If a database containing plain-text passwords is compromised, user accounts are in immediate danger. For this reason, as early as 1976, the industry standardized on storing passwords using secure, one-way hashing mechanisms (starting with Unix Crypt). Unfortunately, while this prevents the direct reading of passwords in case of a compromise, all hashing mechanisms necessarily allow attackers to brute force the hash offline, by going through lists of possible passwords, hashing them, and comparing the result. In this context, secure hashing functions like SHA have a critical flaw for password hashing: they are designed to be fast.
This is the fourth of four posts on our experience deploying Content Security Policy at Dropbox. If this sort of work interests you, we are hiring! We will also be at AppSec USA this week. Come say hi!
In previous blog posts, we discussed our experience deploying CSP at Dropbox, with a particular focus on the script-src directive that allows us to control script sources. With a locked down script-src whitelist, a nonce source, and mitigations to unsafe-eval, our CSP policy provided strong mitigations against XSS via injection attacks in our web application.