Dropbox employee’s password reuse led to theft of 60M+ user credentials
techcrunch.com
techcrunch.com
Truly essential service and I'd be happy to pay more. Even with good password discipline it's useful knowledge on your exposure.
Edit: I misread the article. It says the leaked hashes were salted, but the leak didn't include the salts.
I think he's saying that the leak didn't include the salts.
Very true. It is a constant battle between debuggability and not leaking credentials.
In Erlang for example, when processes crash they dump their state, their neighbours, links to other processes, and other such useful stuff. That's very helpful, however it means it could dump credentials as well.
Luckily there a custom function to format the state of a process http://erlang.org/doc/man/gen_server.html#Module:format_stat... which helps with that. But have to implement that each process which holds credentials.
Also some of those log ingesting services provide a pre-indexer credentials filtering. I know Splunk has it:
http://docs.splunk.com/Documentation/Splunk/6.4.3/Data/Anony...
Of course it is better if it is filtered out before that. But it could be a safety net perhaps.
And there are so many ways of getting bitten.
Another anecdote for you:
I recently found out that an API wasn't logging errors anywhere.
Easy enough to fix, plug in a library and bam, everything is nicely logged to the database.
Including the HTTP headers.
Headers that include API auth tokens.
Ouch.
Is there any way you can take the opposite approach and whitelist stuff to include?
That way you don't have to worry about stuff sneaking in in the future.
(not that blacklisting has ever bitten me in the behind before, no siree...)
What to do when the company is ignorant and continues to use something as stupid as that?
> [...] batch of encrypted passwords [...]
> [...] from using the encryption algorithm SHA-1
> Some of the stolen passwords were encrypted with SHA-1, while 32 million were encrypted with bcrypt
> The passwords were also secured with a salt, a random data string added to strengthen the encryption.
> it does not appear that the encryption protecting them has been cracked.
I know it's completely tangential and I'm just nitpicking but damn that does bother me more than it should.
You WOULD have an e-mail account without knowing how password hashing works. You WOULD buy a car without knowing how airbag works.
If you think you know everything about every aspect of everything you interact with, you're so clueless you don't even realise.
Of course, any site can claim to have hashing but not actually do it or implement it terribly. The same is true for airbags, but for that we have regulations....
Yes, yes it matters. Correctness matters. Falsehood is wrong.
Please Techcrunch, you are making it sound like you are talking about actual encryption while you are really talking about hashing. From that sentence people would believe that it takes a single "crack" to get them all.
The magic of bcrypt (and hashing in general) is that probably some low-hanging fruits have been picked already while any non-trivial password remains secure.
Hopefully all these clouds will pass over and we can get back to personal computing.
I have an encrypted file with website|username|password on my laptop to allow for unique passwords across sites. But it's a pain, and definitely not something everyone will do.
In practice, it would mean replacing most of the world's user-facing computer infrastructure.
The card reader doesn't have to be any more tamper-resistant than the rest of the computer. On a public terminal, it should probably be built like an ATM's card slot (and the rest of the machine should be similarly armored), but on a personal computer it doesn't need to be any more robust than the keyboard a user would otherwise type passwords in with. The card-computer communication is all encrypted anyway, so even if it's built like any old USB peripheral it's still better than typing into a keyboard.
If you have deals with many strangers do you not expect to get your hands dirty in some way?
This was something I changed when I realized that a tax related government agency's machine I was using about 10 years ago man in the middled SSL connections to my online banking. Who knows what was logged and what the retention on that was? I don't have time or the inclination to ensure every relative's / customer's devices are secure, so I use my own or go without.
The first makes your public key useless for security. The second locks you out of everything.
So you've still got to have patterns-of-fraudulent-use detection, and some sort of token-reset mechanism.
Persistent data encryption is another option, but that compounds the key-loss problem in that you cannot access earlier data.
It's shameful that it's so much easier to find tutorials on how to store passwords "securely" (including several tutorials that tell you crazy insecure things, like storing with unsalted commodity hashes) than it is to find tutorials on how to integrate your brand new battling-fairies website game with OAuth for authentication.
I think it's going to have to be legislated:
1. Mandate that all publicly disclosed passwords are collected in a compiled set.
2. Require that any Internet service vendor check against this set on password change revisions, and against different portions of the file, as maintainable, on each authentication.
Known passwords are rejected when set, and mandate changes when detected on login.
Asking a 76 year old mostly-computer-illiterate pereson to come up with a never-been-used-before password simply doesn't work.
This also means mandating password safes on all consumer-grade OSes. Apple already does, Microsoft and Android. For Linux, you might be semi- on your own, though most distros offer several options.
I'd also like to see 2FA via a keyfob generator rather than contact token (e.g., phone, email).
For sites where I don't really care about security (present company included :), I use a passphrase, usually in the form of a mnemonic. As an example, the password I may choose for this site would be "Hack_G1bson_RedPill_KungFooey" Much easier to remember and it only makes sense to me. Also, for apps like Dropbox, you better be using multi-factor authentication.
I can't do this for every site because of their tyrannical password requirements. I wish they used overall password complexity as an entropy threshold instead of 1 lower, 1 upper, etc.
If Im feeling "community minded" that day, I might email their contact address and tell them why I didn't complete the signup process - if I'm in a stabby mood I'll more likely just lampoon them as morons on Twitter. doubt either action on my part makes any difference.
You could argue that if someone doesn't care for their digital security that's their problem, but we live in a time when one single careless employee can screw over 60 million people, as it was the case with Dropbox.
However, I think being able to use the same stupid password on all sites I do not care about is a feature rather than a bug.
Thinking about it, my account was added by a company using Azure, perhaps they are able to set the password restrictions for their sub-accounts...
I had a "stupid" multiply re-used password exposed in a breach of PerlMonks (which I didn't really care about in 2007 or so) which I also used when signing up to check out yet another new social media site in 2008. A couple of years later my Twitter account was sending Acai berry spam to my friends...
(And even if new-site-de-jour doesn't turn out to be something you stick with, it's now got your name (or regular handle) with the risk of damaging your reputation when it gets exploited without you even knowing...)
Yeah, I mean, my friends talked me into signing up for some stupid site back in 2005, "Face"-something? Seemed pretty trivial to me.
(IIRC in all seriousness Facebook's password requirements were hilariously trivial back when they first started.)
None that will not dissuade potential paying customers, though.
At scale, there's no way you'll get everyone to use good passwords. Random generation is a bad idea, users just write them down if you do that.
Then, you reinforce that by using some sort of SSO setup/service (you can outsource this to someone like okta.com if necessary), so that all internal systems never have a place to set a password. (e.g., don't make people set up separate accounts with passwords on the corporate jira or bitbucket server)
Basically, not training people to reuse passwords internally can help them to not reuse their one internal password externally.
Another possibility is to simply buy a password manager subscription for every employee and have it as a perk. That's a per-employee overhead of $20-30/year.
Do all login through OAuth or the related proprietary "login with" mechanisms Facebook and Twitter have. Offer your users a choice of mechanism, in the signup flow, and don't require that they first set up a password that they then replace with login-with-(whatever).
If you can't imagine what this looks like, open an incognito browser and go through the signup-for-an-account flow at stackoverflow.com. That should be what you're aiming for.
In the past this would have been considered as bad practise, since nobody can remember that kind of passwords but nowadays it is pretty clear that everybody (in IT) is either using some password manager or reusing their passwords between systems.
(And to clarify, I'm not talking about end users of service like Dropbox, but people who are working with security sensitive stuff on the backend)
I'll go check it for you.
You have no way to know the password you set on sites you signed up with, except from pastes of breaches?
I don't think that's a problem Troy needs to fix...
I think he's chosen very smartly to explicitly and publicly _not_ know anything about the passwords, and only store email addresses. If you think 60mil Dropbox passwords sounds like a spectacular fail, imagine the headlines if an attacker got into HIBP and exfiltrated 1.3_billion_ passwords (or password hashes)! It's be the first "Unicorn credential breach" ;-)
Unless HIBP is getting its dumps from nonpublic sources..?
So that's only useful where cleartexts are breached and there he'd then have the massive headache of securing that data.
The best approach if this is a concern for you would be for you to store a password history of ones that you have used and when you changed them.
Whenever I've seen passwords stored without a salt it's either because there is no salt or the salt is derived from the username. If it's the latter, it's only a matter of time till the specifics are figured out.
I'd be very surprised if there is a random salt for each of the SHA-1 passwords that's stored separately from the hashes themselves.
What is also not apparent is whether the stolen credentials were utilized to pull off data from the accounts? Users might have had sensitive documents stored!
At least their passwords were hashed!
what a nice way to say that they lied before and that they are now finally coming clean - three years too late.
From 2012 to 2016 -- it'd be four.
Incredibly poor response from Dropbox on this issue.
Exact phrasing from 2012 blog post:
>A stolen password was also used to access an employee Dropbox account containing a project document with user email addresses. We believe this improper access is what led to the spam. We’re sorry about this, and have put additional controls in place to help make sure it doesn’t happen again.
The fact that such a document can even exist is plenty of reason to worry about processes and access at dropbox.