> It turns out a Dropbox employee’s account was hacked, allowing access to user e-mail addresses.
This is misleading.
> Some Dropbox customer accounts were hacked too, but this was apparently an unrelated matter.
Unrelated how? What I read was: "Our investigation found that usernames and passwords recently stolen from other websites... A stolen password was also used to access an employee Dropbox account"
This article dangerously leaves the impression that an intrusion was made into Dropbox's system to access the employee's account, and possibly an admin interface. In reality Dropbox let a spammer with a valid email and password look at someone's files.
An employee account was compromised and privileged information (in this case user email addresses) was accessed. The attacker exploited a flaw in dropbox's password policy / authentication system to access the information. Dropbox is modifying their systems and policies to prevent this sort of attack in the future.
All that together certainly adds up to an intrusion and is well within the definition of a "hack".
Using a key to open a door that was designed to be opened with that key is not a flaw in the lock mechanism. The fact that the user set that key to also open something else is not the fault of the former lock.
This is not at all how security researchers think of it. Security vulnerabilities are very broad, they can be exploited through social engineering, through incompetent employees who do not have rigorous password standards, etc. If you narrow security vulnerabilities to coding mistakes, you're neglecting your customers.
No, a hack means that any malicious attacker (you, me, your mom, etc) could exploit ("hack") a flaw in their system security in order to gain access. This is not the case here.
I wish websites with user accounts would offer the option to "login via email" - as in you'd type in your username (or preferably your email) and maybe a captcha and then you'd login by clicking a link it sends via email afterwards. Ideally having a password associated with the account at all would be optional.
I have a Gmail tab opened just about 100% of the time I'm on the computer, so this would be very convenient for me as an alternative to having to remember passwords for sites that I visit once a month or less (and end up having to get a "password reset" link via email every time I log in anyway), and then I'd only have to keep my Gmail account secure (which I do via 2 factor).
To be honest I was mostly using the comments section for this link as a soapbox, I realize the idea isn't too relevant to this particular case with Dropbox, as no passwords are known to have been revealed. Sorry.
Though, I do think it would often mitigate the damage from this type of security breach that it seems like we've seen so much of from big name tech companies lately. I'd guess that a majority of accounts created on the internet are pretty unimportant to the account creator, and with how often passwords are reused indiscriminately, the worst effect of these password leaks is often not the unauthorized access to all those accounts on the hacked site but rather the usernames and passwords themselves - which are very often reused for bank, email, etc. accounts. With my proposal, anyone who opted not to have a password wouldn't be vulnerable to that.
The trouble with that solution is that email is not an instant protocol. It's usually instant, but SMTP RFCs give mail servers up to 72 hours to deliver before they must send back a delay notification.
We use Google Apps to host our email, and I've seen plenty of occasions where their systems don't deliver mail immediately. This "issue" used to generate a lot of calls when I was doing freelance consulting. "Bob sent me an email over 20 minutes ago and it's still not here." I'd get those calls all the time.
Imagine you're trying to get logged in somewhere and you have to wait an hour or two for an email to show up.
Having your webmail service also act as an OpenID provider would be much simpler. I often login with Gmail (or rather my Google account) on sites that support it.
Dropbox did not get hacked. One of their employees used the same password on multiple other sites, and one of those got hacked. This is awful journalism.
Security is fungible. You're applying some subjective standard that divides what constitutes a hack and what doesn't. If I had to guess, you wouldn't treat a buffer overflow where some code was executed the same way. This is arbitrary.
Considering a dropbox employee, corporate information, and internal security practices are on the line here: I think the author made the fair, ethical call.
I would think that if the attacker had access to a Dropbox employee's account, which in turn gave him/her access to user accounts, that would constitute a security breach.
That’s not really a response, is it? User account data could be accessed – because Dropbox was unable to protect your data. That’s not quite as awful a access to user account but it’s still awful.
Given that the RSA intrusion was known and the government didn't take steps to change passwords, sure. In this case, it's perfectly fair to say the Dropbox employee stupidly allowed their email to be hacked.
But making it sound as if Dropbox's security was compromised is misleading and inaccurate IMO.
If that weakest link happens to be an employee with a naive ideas about password security, it makes no difference.
This is the same silliness that makes people claim that social engineering isn't actually a security breach "oh they just phoned up the front desk and convinced them to be granted access, who would fall for that, that's not hacking!", yeah, no, someone just got 0wned.
The title of this submission matches the title of the article, matching recent HN policy. Users objecting to the phrasing may wish to flag the submission instead.
Yep, the guideline does say that. That is why I said recent policy. There have been several recent instances of submission title being edited to match the article linked, in some cases when that title was misleading or provided minimal context. Some examples here: http://news.ycombinator.com/item?id=4102013
Just to be clear one of those users was a Dropbox employee who had a document containing user details including but not limited to email addresses (some that had only been used for Dropbox). These details were then provided to spammers
There's no mention of how many users were in that document. I've had a Dropbox account for many years with a Dropbox specific email address and I did not receive spam, so it must not have been everyone.
That's not just GMail, that's all compliant email handlers; it's part of the RFC. Unfortunately, it's not guaranteed that the site you're signing up to can handle that address format - Facebook doesn't...
While the RFC mandates the ability to send and receive email from user+detail@example.org it doesn't require that it go to user@example.org. It's an extension to the email standard, and you could have labels in another form if you wanted to, e.g. inbox0-user@example.org (http://tools.ietf.org/html/rfc5233)
I really hope that Dropbox use Google Authenticator.
The last thing I want is double the number of apps on my phone as every single app has another 2-factor auth app to ship.
Just add yourself to Google Authenticator and be done with it. It doesn't require a Google account, you can use Google Authenticator as the generator of the 2-factor auth code and that's all.
LastPass uses Google Authenticator for 2-factor, and it works well.
One of the problems I've found with Dropbox is that I tend to use a shorter and easier to type password because I enter it on my phone in addition to my desktop.
Good passwords are great when you have a password manager, but in the app you're stuck with having to type it in. So my Dropbox password is weaker than I'd want just because apps mean I can't use a password manager. 2-factor can't come soon enough for me.
On a related note, 2-factor is one of the weaknesses I want addressed. The other one I'll bang on about is client-side encryption. If it's possible at all for someone to access their systems I still want to feel sure that someone can't access my files.
It's not that I limit my use of Dropbox, but I use it differently. That 1GB file in my account... that's a Truecrypt volume. The other files are just less sensitive.
How often do you have to log into your dropbox account? I hardly ever have to log into the website, and you don't have to log in every time on your phone.
I do client work and frequently find myself onsite where I can't connect my computer or phone to the network yet can use a computer on their network to access the web.
1) What about this issue would have been helped by client-side encryption? A valid username and password was used to access dropbox information, so it would have gone right through client-side encryption.
2) Do you not enjoy features like the web interface and public links? Those are one of my favorite parts of dropbox and they wouldn't work with client-side encryption.
> Do you not enjoy features like the web interface and public links? Those are one of my favorite parts of dropbox and they wouldn't work with client-side encryption.
You can have web interface with client-side encryption. Check aes.io (plug).
> What about this issue would have been helped by client-side encryption
I was assuming that an employee account can in a more or less direct way access user files. Either way, it's not the first time they've been compromised and last time[1] client-side encryption would have certainly helped.
> Do you not enjoy features like the web interface and public links?
The web interface could work with client side encryption.
I wouldn't mind having no encryption for publicly shared files.
You assumed wrongly. They accessed an employees account and took a file out, they didn't further compromise Dropbox's backend in any way. So in this particular instance, client side encryption wouldn't have helped at all.
Client side encryption would stop Dropbox from deduplicating the data. Very few people rip their own CDs. Instead they buy them from a digital store or pirate them. In either case the mp3 will not be unique. If you look in the average users home directory you'll find a few megabytes of word documents, a few hundred megabytes of family photos and maybe their music collection.
If we assume that the set of files users sync is similar to the set of files in their home directory then it is not a stretch to conclude that Dropbox deals with lots of music. Dropbox cannot do anything about the documents or family photos but they can save considerable bandwidth and disk space by deduplicating the music, or any other common media.
Since dropbox's biggest input cost is storage I could well see client side encryption having a consider effect on their profitability.
You could construct a de-duplicated system with client side encryption by building an index pre-encryption. There is some leakage of information about what files exist, but not the contents of those files, and IMO the "files which are shared widely among Dropbox accounts" are NOT the ones people care most about keeping encrypted...
There are several systems with client side encryption, some of which also have de-duplication, and at least one of which has interesting crypto (bitcasa).
This is all unrelated to the authentication problem with dropbox today, though.
Due to exaggerated copyright concerns, Dropbox no longer dedupes across customers, last I checked. People were using dedupe to "instantly send" files (a project called Dropship). Dropbox felt that made them too liable for copyright infringement and nixed the feature.
Is it just me or has there been a lot of security mishaps like this for various high-profile services? LinkedIn was a victim on a much larger extent not to long ago. This is becoming ridiculous.
This isn't on the same scale. Some user email addresses were in a spreadsheet, and the employee's password was compromised. I bet every single day someone's Gmail gets "hacked" if that's the standard for that.
The point is it shouldn't occur on any scale. Even small scale security exploits can turn into much bigger ones further down the track. For all we know, we've yet to see the full consequences of this attack it could be revealed that it's much more than an a spreadsheet of email addresses. The very fact Dropbox made everyone change their password is proof enough that even Dropbox aren't sure what hackers have taken or had access too..
The most annoying part is the disingenuous email we all received tonight.
Recently, passwords have been stolen from some internet services. We've reset your password.
I'd have been shocked, but ultimately more respectful of:
We've had a security violation. You can read about it here. Your account wasn't affected, but we're resetting everyone's password just in case. So sorry about this.
It disappoints me that a Dropbox employee might be using the same password for a work account and anything not work related. It's bad enough that they might re-use passwords internally, but I find that understandable.
However, using a work e-mail and the password you use at work on someone else's system was stupid. You can have faith in your own security measures, but not anyone else's. If you're going to re-use passwords, at least have a work one and an everything else one.
I believe your dropbox needs to be secure as your email account because it deals with storing your personal data.So offering 2 factor authentication is a step in the right direction, like what gmail has.
Other than that dropbox can't do much about people using the same passwords for different sites or social engineering attacks. You can educate and warn people about it, but it's ultimately up to the user to follow through.
This is misleading.
> Some Dropbox customer accounts were hacked too, but this was apparently an unrelated matter.
Unrelated how? What I read was: "Our investigation found that usernames and passwords recently stolen from other websites... A stolen password was also used to access an employee Dropbox account"
This article dangerously leaves the impression that an intrusion was made into Dropbox's system to access the employee's account, and possibly an admin interface. In reality Dropbox let a spammer with a valid email and password look at someone's files.