New security issue at Dropbox
pastebin.com
pastebin.com
I recently looked into password managers myself after the MtGox leak. I tried 1Password and LastPass. While both do what they say--I found them cumbersome to use.
I settled on a scheme like this:
E-mail: Very strong, completely unique. 2-factor auth. If you have my e-mail, it's game over.
Bank: Very strong, completely unique.
The rest of the passwords I've broken down into tiers. I've memorized a password for each tier combined with a hashing algorithm stored in my head.
The theory here being if an entire tier gets compromised (someone figures out my hashing scheme), at the very worst I lose the entire tier.
This does keep me safe from automated attacks, but not if someone singled me out individually. Which in that case, I've got other problems.
This isn't perfect, but it gives me a couple of things I really value:
- Keep all passwords in my head
- Unique passwords on each site
- Tiered passwords so if someone figures out my hashing scheme, they only get that tier
I like the idea of password managers, but in practice they were too much hassle for me.
I use one, but I feel like I'm more willing to use something cumbersome. But I think that most ppl feel the same way you do.
It seems like a huge startup opportunity to do what DropBox did, and make PW managers easy for average Joe. I think most people recognize the need.
LastPass would sometimes post to the wrong login form.
1Password got confused a couple of times between 'Logins' and 'Accounts'.
With 1Password, when I'm away from my computer, I have to use my phone to read my passwords. If my phone dies (fairly common) I have to install the password manager (not always possible).
With LastPass I can access their web interface--but experienced too many of the issues above. Plus I am a little nervous about a 3rd party having that much power.
I'm sure all of this was my fault, but the end result was I discovered many hidden costs and it felt like I was fighting against them.
I guess you could put it in the Dropbox Public folder. I wouldn't be totally comfortable doing this, but all the 1Password data is encrypted so it should be safe.
I've been using Password Safe for quite some time, it is fairly minimalist, very easy to use.
I am a freelancer and I maintain about 50+ sites (most of those are cpanel logins). I don't know what I would do without a password manager.
I used keepass for awhile too, but it's too buggy and just doesn't work as well.
[0] http://www.keepassx.org/
[1] https://spideroak.com/
My Fx settings involve flushing all cache and sessions on closing.
Apparently when setting the Fx master password, the local database appears to be using 3DES encryption in CBC mode[0] (nice and slow) which is insanely secure with long and keys. The only password I have to remember is the KeePass database, which in turn is as complicated as I can remember. The when booting up firefox, just paste the master password.
[0] http://luxsci.com/blog/master-password-encryption-in-firefox-and-thunderbird.html
This means that the only password that is stored in my head is for the KeePass db, but I'm planning on replacing it with a key file (perhaps on USB), once I've figured out a usable scheme for it.
I'm just dying for the day when web services can be integrated into a proper keychain, that would spell an end to this bull.
How easy do you find SpiderOak to use otherwise?
It may be possible to ignore the horrible UI once it's set up, but I couldn't ignore that it randomly decided to stop syncing individual files or entire folders.
On the second day I even set it up from scratch again, as I figured I might have done something wrong the first time. But on day 3 my laptop and desktop were desynced again, so I went back to unison...
Now, I've decided that there is no real effective solution other than randomly generated passwords unique to each site.
I also turned on 2-factor auth for Gmail a couple months ago - their SMS system is really effective.
I do have to credit Google for being extremely awesome when it comes to security... They noticed a few "your password has been changed" emails incoming to my inbox yesterday and immediately put a security flag on my account, requiring me to re-auth with 2-factor and change my password. Google is really proactive when it comes to security. The fact that they can recognize a high number of password change emails arriving as an indicator of possibly account hijacking is just amazing.
I think LastPass is probably as good of a solution as any. They only store your encrypted password database in the cloud. With a strong enough master password and optional 2-factor authentication with Yubikey, it seems quite secure.
LastPass with 2-factor auth should be more secure than KeePassX, however, your point about it being proprietary is well taken.
I also think LastPass has a very good reputation for full disclosure - when the salted hashes of master passwords were compromised in 2010 it was very refreshing to see the CEO come forward and give immediate full disclosure to the public about the implications, and why you should change your master password.
I also find it refreshing that if you have a strong master password, even someone compromising their entire database should not give you reason to worry - it would be similar to someone getting a copy of your KeePassX database - it's still encrypted with high-grade encryption.
They do not. Mt. Gox contacted google and gave them all the gmail accounts that were leaked.
However, where we differ is I then have those stored in LastPass, so I have log-in convenience, plus the ability to log in even without the password manager.
Too much hassle in putting data in, getting it out, or both?
I used to feel that way, but I just ended up getting lazy too often and repeating passwords, so I started seriously using a simple one on iOS (that I helped make, so I had some encouragement). I never use autofill (it annoys the ever long crap out of me) and browser integration features and don't really want to, as I don't mind having to sign in occasionally (I prefer it).
I force myself to take the time to turn it on and create a new entry when i am creating a new web login (e.g. online bill pay for some utility) and I'm tempted to use a throw-away password. Or, when i realize i've got a throw-away password i've been using on multiple sites and it's time to set a new one. This makes data entry easy, it's kind of like lazy loading IRL ;-) People make a big fuss about having lots of add-on features for such apps, but in the end I think all one really needs is a good habit and a strong data store.
Our app uses an open source encryption engine we developed called SQLCipher, it's page-level encryption for SQLite plus some key hardening and hmac protection on the pages. You can check it out here (and maybe use it to build your own?) http://sqlcipher.net
The reason I don't use LastPass is because it is proprietary. I use KeePassX over firefox because it has better security, can store associated details (Comments field which I can put, for example, what my secret was (I randomly generate those too) and so on), and can easily be used for passwords that are not for only web based stuff.
The most important detail would be the fact that passwords saved in browsers are only useful in the browser, not for apps etc.
As another random example, firefox couldn't save, say, the passwords of sites I ssh into or the irc keys I need to authenticate myself on various irc servers.
Once you set up a master password then firefox encrypts them in the password database. That button is still there, but using it requires the master password before actually it shows you the stored encrypted password.
1Password has abstracted the browser away from me, so I can use Chrome, FF, or Safari with ease on Win or Mac.
Dropbox integration seemed nice, but I'm now strongly considering moving my keychain to a different service.
The wifi sync thing works ok, though.
It would almost be worth writing a utility to manage 1Password syncing external from 1Password.
The real solution to all of this is some kind of active agent running on each frontend which can make zero-knowledge proofs to third parties about credentials, vs. passwords, but I don't have a lot of faith the web will move to a sane authentication infrastructure anytime soon.
What would utterly fucking rock is NFC/RFID credentials managed through 1Password too; with a dongle on my desktop, and maybe in my phone, or even a dedicated hw device.
Maybe also manage smartcard/crypto credentials (processed in HW, but this could be the admin UI to shuffle them around).
The other wishlist I have is Linux support (I'm a Linux desktop dev/sysadmin workstation holdout, with macs for mobile and office automation).
This thread just encouraged me to enable 2 factor auth everywhere I could (aws, google, google apps, openid) etc.
Tips on never getting caught with your pants down by a 3rd party service:
1. Never ever rely on a service maintained by a 3rd party to remain secure. Just assume they will be compromised in the near future (including your password).
2. Make your password strong but don't reuse it; save it in your browser password cache or keyring. Use a memorized really-freaking-difficult master password for the browser cache/keyring.
3. Use NoScript and updated browsers to help prevent XSS and other simple attacks from compromising your cached cookies.
4. Encrypt all sensitive stored information yourself using a well-vetted tool such as gpg, openssl, etc and store the encrypted files on the 3rd party service.
5. Keep hard copies of your secure files, keys, etc in a secure location. 'The Cloud' is not a backup, it's a trap.
A security hole is one thing, but something like being able to log into anyone's account with whatever you'd like as the password? Or changing a digit in a URL and accessing someone else's account? Come on, that's like the guards at Fort Knox leaving all of the doors open directly to the gold, or the Secret Service collectively going out for a smoke break during a presidential parade.
The level of complexity of an attack and the ridiculousness of a hole are almost completely arbitrary in terms of compromising the security of a service. The biggest attacks of the past 6 months were performed either using social engineered credentials or extremely common web application vulnerabilities (so common that probably every hole used is on OWASP's Top 10 security holes).
The only reason Fort Knox or the Secret Service works is because it relies on humans spending 100% of their time actively focusing on security, 24 hours a day, every day. No web service I have ever heard of has that level of security.
As far as this particular hole: it's probably a bug somebody left in some code by accident and nobody foresaw the consequences. There are bugs like this in every system. The only reason you don't see more of these holes is because either nobody's looking for them or somebody found it and is keeping it very secret.
Yikes
Various big-name dropbox people are likely aware of this thread now based on their quick responses to previous threads here at HN. The fact that they've said nothing here is virtually an admission that there was a problem. It only takes a few seconds to bang out a 'this claim has no merit' post if it indeed does have no merit.
The question is, are they working on some sort of official statement to make (which would have to be exactly worded and thus I can understand the lag time) or are they ducking down and hoping this will just blow over?
IMO they absolutely need to address this very soon, and not just as a one line email that promises it'll never happen again.
I think that part of this is how Dropbox is handling things, and the fact they appear to be growing faster than they can code.
I'd love to see them offer something like a free lifetime 50GB account for anyone the submits a high security reproducible bug like this. Sure, they may end up giving out a couple of terabytes of free space, but the intense QA they would get for free would likely be worthwhile.
I'm not as highly paid as the Dropbox guys are, I'm sure, but even I know to test authentication with automated tests. Oh, and not to let things that fail tests through to production!
What if I had archived my bank records there and someone go ahold of them? Thankfully I'm still just a little too paranoid for that.
I'm moving to Wuala or rsync.net; before I try the latter I want to test Wuala.
Mind putting up a mirror of your Dropbox folder?
As I said, it wasn't worth worrying about.
"Your files are backed-up, stored securely, and password-protected."
Except, apparently, you don't even need to know the password to get access to the unencrypted files.
I wish somebody would clone exactly what Dropbox does, but get the encryption/security right so that it is impossible for anyone other than the account owner to access their files. Dropbox will never get security right.
I fail to see how you conclude that. Yes, they did have several glitches in the past, and no, they did not always respond as they should have.
But there are some pretty smart people working at Dropbox. What makes you think they do not have the capacity to solve security issues?
1.) De-duplication
2.) Web access to the files.
Those are the main reasons I have come to this conclusion.
Here is a forum post where they admit that mobile SSL was impossible.
It feels a bit awkward to even refer to file-level hashing and lookup as de-duplication as it's more commonly known in block-level de-dupe.
Regardless, on documents it's probably safe to assume they get close to 2:1 compression ratio. I'd assume that the de-dupe of large binaries is a huge part of what makes running such a business on very expensive cloud-storage systems financially viable.
Would Dropbox work financially without it?
They could offer a non-de-duped version at much higher cost for the security minded, but then they've implied that the basic version is fundamentally flawed.
Just an interesting technical barriers to think about (IMO).
1. Each user has a public/private key pair. This is generated client side, deterministically from the user name and password. The public key is stored on the DBL server.
2. To store a file on the DBL server, the client encrypts the file with, say, AES256, before sending the data to the server. The key is deterministically derived from the file contents, say by SHA256.
3. The client keeps a file that contains a mapping from files to their encryption keys. This file is encrypted using a public key system, with the public key being the user's public key. It is stored on the DBL server (and no doubt cached locally on the client).
The above is sufficient for non-shared files. When you wish to retrieve a file from a client other than the one it came from, the retrieval client can grab the file/key mapping file, decrypt it using your private key, and then lookup the decryption key for the file.
For files that are to be shared with specific people, the client maintains a file for each person you share with. In this file it stores the mappings of files to encryption keys for the files you are sharing with that person. This file is stored on the DBL server, encrypted with the public key of the person you are sharing with.
De-duplication is possible in this system because when two people store identical files, they pick the same encryption key, and so the end result is the same encrypted data.
Web access is possible, as long as Javascript is allowed on the client, by implementing the key retrieval and the AES decryption in Javascript.
Note that DBL never sees the unencrypted data, and they never see the encryption key for a file in plaintext--they only see it when it is encrypted via your public key (or the public key of someone you are sharing the file with). Even if they are breached, the crackers cannot get your data. Same goes for if they are subpoenaed--they can't give up your plaintext because they don't have access.
Note also that DBL doesn't actually need your user name. All they need is your public key (at least as far as operation of the file storage/retrieval/sharing system goes--they need more for billing if you are using paid services, of course).
How would you display that data as a file or save it locally?
I guess you could do it in Flash/Java using something like Downloadify
Edit: I am a pretty happy DropBox user, but I only store files there that I wouldn't really care too much if they were made public. DropBox to me is about convenience, not about security.
Edit2: I was a pretty happy DropBox user, now that I think about what having a system that is prone to "failing open" means I'm seriously thinking about closing my account. However, I'll wait and see what the "official" explanation is first.
I also tried it a couple of years back under Linux and had stability problems when copying lots of small files into it automatically. The mount would just break.
It does not look as easy as Dropbox (because there is a distinction between the JungleDisk software and the underlying storage), but it is not difficult either. I have been using it a little while and like it so far.
There is also no iPhone or Android app, but there is a pretty decent web interface.
Not the case any longer, iPhone app is available (I haven't used it yet): https://www.jungledisk.com/iphone_app_backup_share_files_man...
I'm sure an Android version is in the works.
That means the support team properly escalated this way up the food chain very quickly, and I'd be extremely surprised if we didn't see a response from Dropbox later today.
http://blog.dropbox.com/?p=821
It is very light on details of how exactly the problem occured other than saying it was due to a bug in a code update.
If there's anyway in your code that deserves unit and integration tests, it's your authentication system.
This way everyone is happy, and not to mention safe.
I'm so tired of seeing all these username/password leaks lately. It is not doing anyone anything good, except from teenagers and thieves which thinks it is funny to empty Amazon accounts or upload nude pictures on Facebook (etc. etc.)
So, in all fairness, the submitter did actually contact Dropbox first (which is great), but please wait until they definitely have fixed before telling the world about it. Or at least, that is my humble opinion.
The poster was not told any details about "the glitch" -- we don't know if it was a one-time issue, or if it represents a deeper architectural issue. In this case, full disclosure is absolutely warranted.
Applying the most optimistic reading, Dropbox fixed the problem, so disclosure is fine. The most pessimistic would say that the problem still exists, and that disclosure will cause exposure, but will also prompt further scrutiny to the issue.
Unclear if the pun was intended or not, but amusing either way...
So, at the moment, there's nothing to see here.
hi XXX, there was a very brief glitch and this should never happen/be possible again. thanks for the email.
-arash
The question is, do they fail open under a DoS attack on the machines handling authentication? Do they fail open if you just run enough login attempts?
They are showing us that they are technologically incompetent at managing their own systems. I don't know why anyone continues to do buisness with them for files they want any sort of privacy over.
I've moved to rsync.net. Its uglier, but at least they know what the fuck they're doing.
That's not true. They used an admin control to disable public sharing of a file in DropBox; this procedure apparently is typically used when DropBox receives a DMCA request and it had a side-effect of (mistakenly) notifying the file's owner that DropBox received a DMCA notification. See http://news.ycombinator.com/item?id=2483053. DropBox didn't send a DMCA takedown request to any service provider hosting the file.
You do not know what happened any more than the OP does so your usage of the word 'true' is weak at best. I'd be more okay with your comment if you had written "Drew explained" instead of "That's not true" as if you speak authoritatively.
We do know what happened, because Drew told us what happened.
Years ago, when my wife thought her MacBook was stolen, I emailed Drew and asked if he would notify us if it connected to Dropbox, and he was happy to help. This was back when Dropbox was small. (My account is number 315, for example.)
Drew is a good person, and unless you have some basis for calling him a liar, don't.
That is great that Drew helped you when the company was small. Facts are easy to distort when your company's reputation is getting flushed down the toilet and it is not a reflection upon Drew personally that I do not automatically trust him.
I tried believing in the best in people. It stopped working. Until shown otherwise I question every input and you would be stupid to do otherwise.
You're right. I was probably just clinging to the fantasy that YCombinator is the one pure group of people in a world of backstabbers. But I guess Airbnb already disproved that.
I don't distort facts. Neither did Feynman. Drew is an MIT alum, so I was assuming/hoping YCombinator consisted mostly of people with that type of scientific integrity.
It came out in the aftermath that the takedown notice was the result of an automated process that was accidentally triggered.
However, regardless of whether I feel like the previous event said anything about DropBox's development capabilities, I do feel like this event does.
I'm responsible for the authentication code for my company. I can't imagine having a default "YES" in any circumstance, and that DropBox did shakes my faith in them and their ability to protect my information significantly.
How do you know? Could it just be that the only reason Dropbox has publicized exploits and rsync.net doesn't is because Dropbox has many, many more users? And thus more people trying to exploit it and more publicity when an exploit is found?
Pubkey auth connecting to openssh on freebsd to hippa- pci- sox- and sas 70- compliant storage with a warrant canary and you can give them a call to talk to the engineers (I have). Looking back dropbox feels like a fly by night in comparison.
Just like rsync.net but infinitely cheaper and based on ZFS. With a web interface [and ZFS snapshots]
Brain surgeons makes mistakes, people die. Pilots makes mistakes, people die. _Everyone_ makes mistakes. There is not one single person on this planet who is perfect, human error, this includes the employees of rsync.net, or any other company for that matter.
Today it happened to dropbox, tomorrow it happends to Visa, Bank of america, Amazon, rsync.net, <insert X company here>
Its just life, learn to deal with it. If you seriously have seriously confidential stuff, you're probably intelligent enough not to "upload" it anywhere, much less some file service with millions of users.
The more users the more exposed it is, human error. No encryption or system will ever protect against it, at least until we have true AI, and yes you also make mistakes, now matter how stupidly simple or complicated they are, nevertheless you do.
And dropbox, don't get a sad face because of this, just look at Sony or whatever, then smile.