Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Attacks/Breaches

8/31/2016
05:40 PM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
50%
50%

Intruders Pilfered Over 68 Million Passwords In 2012 Dropbox Breach

But all passwords were hashed and salted and no evidence they have been misused, company says.

Reports this week that as many as 68 million email addresses and passwords were leaked online as the result of a 2012 breach of Dropbox has grabbed wide attention for its sheer scope. But the fact that all of the passwords were hashed and salted makes the incident less severe for users than it otherwise might have been.

In a seemingly routine email, Dropbox last week said that users who had signed up for the service prior to 2012 and had not changed their password since then would be prompted to reset it when they next attempted to sign in.

It also encouraged individuals who used their Dropbox password to log into other sites to change passwords to those sites as well, and recommended that they enable two-factor authentication as an additional security measure for protecting access to their accounts.

The company described the move to proactive reset user passwords as a purely preventive measure and not because there was any indication of accounts being breached. “Our security teams are always watching out for new threats to our users,” said Patrick Heim, head of trust and security at Dropbox in the email.

As part of these efforts, the company learned about a set of email addresses, together with hashed and salted passwords, that were illegally obtained in a 2012 security incident and subsequently leaked online.

“Based on our threat monitoring and the way we secure passwords, we don’t believe that any accounts have been improperly accessed,” Heim said. In comments to Motherboard, he said Dropbox initiated the reset to ensure that passwords from prior to 2012 cannot be used to access user accounts. Motherboard, which examined the leaked data, said about half of the passwords appear to have been hashed using the bcrypt hashing function, and the rest were protected via SHA-1.

Dropbox had originally described the 2012 security incident as one in which someone had used a stolen password to access an employee account that contained a document with user email addresses. At the time, Dropbox had said the incident only involved a small number of email addresses.

This week’s sudden broadening scope of the breach triggered many familiar recommendations from security experts on what users need to be doing to mitigate fallout from breaches like this.

“This has become a common enough occurrence that people should be taking all of the most common precautions with their user accounts and passwords when using online services,” said Nathan Wenzler, principal security architect at independent security consulting firm AsTech Consulting in a statement.

Breaches like this show why it is important for users never to reuse passwords across sites and to ensure passwords are long enough and complex enough to make them difficult to guess via brute force methods.

“There's a reason why companies have their employees change their passwords regularly. Employ the same practice for your personal accounts and credentials, too,” he said.

The breach is an important reminder why passwords alone are no longer sufficient as a form of user authentication said Ryan Disraeli, co-founder and vice president of mobile identity company TeleSign.  

“Dropbox appeared to practice good user data security protections, encrypting the passwords and updating the encryption standards.” But as the breach shows, even when good protections are used, passwords alone cannot provide enough protection, he said in a statement.

Meanwhile, DropBox’s failure so far to disclose why it took the company more than four years to discover the true scope of the breach drew criticism from some quarters.

The fact that user accounts taken in an incident in 2012 are only now coming to light is significant, said Chris Roberts, chief security architect at advanced threat detection vendor Acalvio.

It would interesting to know why Dropbox didn’t do more to determine the true scope of the 2012 intrusion until someone actually leaked the hacked accounts, he said in a statement. “It would be good to work out or understand why Dropbox didn't put its hand up and admit the issue back in 2012.”

Related Content:

 

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
lorraine89
50%
50%
lorraine89,
User Rank: Ninja
9/22/2016 | 10:15:16 AM
Dropbox hack
It's just baffling to me that how come companies of such stature and size can become the victim of hacks, what bugs me is that end user is at risk all the time. Risk of information leak lingers over our heads. I use encryption mehtods, file folders password locking method, deploying VPN method, purevpn is the server I use to secure my connection and especially while carrying out banking and other financial transactions to keep my passwords and account secure. 
RyanSepe
50%
50%
RyanSepe,
User Rank: Ninja
8/31/2016 | 7:58:46 PM
It would be good to work out or understand why Dropbox didn't put its hand up and admit the issue back in 2012.
Begs the question was dropbox aware of the security incident at the time or did they only start doing forensics work when the accounts were leaked?
When It Comes To Security Tools, More Isn't More
Lamont Orange, Chief Information Security Officer at Netskope,  1/11/2021
US Capitol Attack a Wake-up Call for the Integration of Physical & IT Security
Seth Rosenblatt, Contributing Writer,  1/11/2021
IoT Vendor Ubiquiti Suffers Data Breach
Dark Reading Staff 1/11/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2020: The Year in Security
Download this Tech Digest for a look at the biggest security stories that - so far - have shaped a very strange and stressful year.
Flash Poll
Assessing Cybersecurity Risk in Today's Enterprises
Assessing Cybersecurity Risk in Today's Enterprises
COVID-19 has created a new IT paradigm in the enterprise -- and a new level of cybersecurity risk. This report offers a look at how enterprises are assessing and managing cyber-risk under the new normal.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15864
PUBLISHED: 2021-01-17
An issue was discovered in Quali CloudShell 9.3. An XSS vulnerability in the login page allows an attacker to craft a URL, with a constructor.constructor substring in the username field, that executes a payload when the user visits the /Account/Login page.
CVE-2021-3113
PUBLISHED: 2021-01-17
Netsia SEBA+ through 0.16.1 build 70-e669dcd7 allows remote attackers to discover session cookies via a direct /session/list/allActiveSession request. For example, the attacker can discover the admin's cookie if the admin account happens to be logged in when the allActiveSession request occurs, and ...
CVE-2020-25533
PUBLISHED: 2021-01-15
An issue was discovered in Malwarebytes before 4.0 on macOS. A malicious application was able to perform a privileged action within the Malwarebytes launch daemon. The privileged service improperly validated XPC connections by relying on the PID instead of the audit token. An attacker can construct ...
CVE-2021-3162
PUBLISHED: 2021-01-15
Docker Desktop Community before 2.5.0.0 on macOS mishandles certificate checking, leading to local privilege escalation.
CVE-2021-21242
PUBLISHED: 2021-01-15
OneDev is an all-in-one devops platform. In OneDev before version 4.0.3, there is a critical vulnerability which can lead to pre-auth remote code execution. AttachmentUploadServlet deserializes untrusted data from the `Attachment-Support` header. This Servlet does not enforce any authentication or a...