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

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?
US Turning Up the Heat on North Korea's Cyber Threat Operations
Jai Vijayan, Contributing Writer,  9/16/2019
Preventing PTSD and Burnout for Cybersecurity Professionals
Craig Hinkley, CEO, WhiteHat Security,  9/16/2019
NetCAT Vulnerability Is Out of the Bag
Dark Reading Staff 9/12/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-16413
PUBLISHED: 2019-09-19
An issue was discovered in the Linux kernel before 5.0.4. The 9p filesystem did not protect i_size_write() properly, which causes an i_size_read() infinite loop and denial of service on SMP systems.
CVE-2019-3738
PUBLISHED: 2019-09-18
RSA BSAFE Crypto-J versions prior to 6.2.5 are vulnerable to an Improper Verification of Cryptographic Signature vulnerability. A malicious remote attacker could potentially exploit this vulnerability to coerce two parties into computing the same predictable shared key.
CVE-2019-3739
PUBLISHED: 2019-09-18
RSA BSAFE Crypto-J versions prior to 6.2.5 are vulnerable to Information Exposure Through Timing Discrepancy vulnerabilities during ECDSA key generation. A malicious remote attacker could potentially exploit those vulnerabilities to recover ECDSA keys.
CVE-2019-3740
PUBLISHED: 2019-09-18
RSA BSAFE Crypto-J versions prior to 6.2.5 are vulnerable to an Information Exposure Through Timing Discrepancy vulnerabilities during DSA key generation. A malicious remote attacker could potentially exploit those vulnerabilities to recover DSA keys.
CVE-2019-3756
PUBLISHED: 2019-09-18
RSA Archer, versions prior to 6.6 P3 (6.6.0.3), contain an information disclosure vulnerability. Information relating to the backend database gets disclosed to low-privileged RSA Archer users' UI under certain error conditions.