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.
The MtGox breach inspired me to switch to LastPass. I used to do what you did, and MtGox was part of my "medium security" tier.
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.
My reason for not using LastPass is because it is proprietary. In fact, there has been an XSS attack on them in the past which was somewhat successful. I use KeePassX because it allows me to avoid laying trust on any proprietary entity. At present if LastPass were to have another security flaw (and hey, security flaws on web-facing servers are all too common) you'd be out of luck. With KeePassX security is local. The worst case for me is someone stealing my database and trying to bruteforce the password (hah, like that'll happen). This requires them to have physical access to my computer. Anyone can take a guess at your password because it's a web based service.
KeePassX is still vulnerable to a keylogger on your local machine.
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.
All my services have gotten 50 char (nice entropy) random passwords, and for ease of use I store them in the browser with an equally difficult master password.
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.
Funny enough, the SpiderOak distribution password is saved in the KeePass db, giving me a sort of chicken-or-egg problem when setting up, I'm toying with the idea of distributing the database publicly, which should be secure enough.
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.
I haven't heard of SpiderOak before, but from their site, it sounds like you create the equivalent of a private key on each device you use, so that your data is encrypted on the machine itself and never visible/readable by the SpiderOak servers (roughly). Is this correct?
I gave SpiderOak a shot but had to give up quickly because their OSX client was an unmitigated disaster.
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...
http://www.spideroak.com is nice but unfortunately they started to implement some file sharing features so they stopped offering true client-side encryption as well. At least they are way more secure than DropBox. Another one: https://secure.cloudsafe.com/
> I like the idea of password managers, but in practice they were too much hassle for me.
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
I developed my own password manager. It is browser based javascript and html with Amazon S3 for storage. I embed it in my home page, so for every device/computer I have it is accessable. If I don't like something I can tweak the code:
Both LastPass and 1Password failed to save some generated passwords for me, causing too many trips to forgot password.
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.
Do you store your 1Password keychain in Dropbox? If so, check out the html file they put there. It's 1PasswordAnywhere, which is basically a web interface to 1Password. You would still need to remember your Dropbox login, and of course your master password that encrypts all the 1Password data.
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.
The problem with that is once someone DOES get your 1Password database, they can crack it at their leisure. Now sure the encryption is strong, and sure it will take a long, long time, but once the attacker has your 1Password database they only have to keylog your master password once and you're SOL. If you keylog my LastPass account you still need my grid (soon to be SMS 2 factor auth when LastPass implements it).
Yes, 1Password is especially bad at not saving generated passwords to the specific account you are trying to update. However, by changing your settings, you can get a history of all generated passwords, sorted by website. It's a pain, but you can grab that password from the history, and update the login record for the website in question.
Curious why you think LastPass is too hard for the average user. It integrates with the browser and autofills stuff. Where is the point of difficulty and how can it get easier than that?
1Password has saved me so much time. It has a nice search feature that allows you to just start typing the domain (or name) of the password you saved and then click it, and it will auto-fill and login.
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.
Don't all browsers have password managers built in? I've been using Firefox's and it seems to work pretty well. As far as I can tell it's stored encrypted on the disk (and my sync server) so I'm not sure why a external password manager is better... I'm happy to be enlightened.
Just for example: Let's say I want to log into google's jabber service with a non-web client (pidgin or something). If I used firefox's built in password storage I could not easily log in. This applies to passwords that are not web based. In addition, firefox's security is not very strong. By default they are stored unencrypyed (Security -> Saved Passwords -> Show passwords ... That button wouldn't be there if they weren't unencrypted).
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.
> By default they are stored unencrypyed (Security -> Saved Passwords -> Show passwords ... That button wouldn't be there if they weren't unencrypted).
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.
The problem with your solution is that when you need to change all your password in 6 months, it's kind of a pain in the ass. A password manager with very strong passwords for everything is the way to go.
I've been using Password Safe for quite some time, it is fairly minimalist, very easy to use.
I love 1Password, but really wish they supported syncing over iDisk (apple) or ideally over a user-specified WebDAV directory. I use dropbox for sharing public files only; my password db, even with a strong passphrase, is one of the things I least want to share.
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.
I use 1Password on Dropbox, but is there any particular reason you can't use it with iDisk? 1Password's db "file" is really a directory and is designed to use a ton of small files for easy file-level syncing, and it notices any externally-motivated changes to the files or directory and reads the changes live. Seems like this should work just as well with iDisk as it does with Dropbox.
Mobile client (on IOS, Android). It's trivial to do this on real computers with OS access, but for me, there is a LOT of value to using 1Pass on my phone too.
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).
Jasber - I'm doing pretty much everything you describe (random base password plus "salt" algorithmically derived from the URL, resulting in unique password per site, plus extra salt for email and banking, paypal etc.
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.
The problem with tiered passwords is that if someone leaks a tier one password they get your tier one. It doesn't matter how important it is to you, if they mess up and lead your information its out there, nothing you can do about it.
This thread just encouraged me to enable 2 factor auth everywhere I could (aws, google, google apps, openid) etc.
It's 2011. Why are people still surprised when some blatant hole is found in a site? Does everyone just delude themselves into thinking "oh, they HAVE to be secure"? That old cliche 'nothing is totally secure' is almost right: the reality is, everything is mostly-not secure.
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.
> That old cliche 'nothing is totally secure' is almost right: the reality is, everything is mostly-not secure.
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.
If you're relying on a cloud-hosted startup to secure gold or the president, you're doing it very, very, very wrong.
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.
_Because I pay for a secure service_. Sure, I'm not stupid and I realize that it conceivably could be hacked, but I expect the company to respond appropriately and deal with security proactively. I ask this of all aspects of my computer (including PGP, etc.)
Yes, I agree. But until I don't hear a confirmation from Dropbox I am going and assume that all this never really happened and it's just a prank. It seems too big and too weird to be true. edit: This is the guy who reported the "glitch" https://twitter.com/#!/csoghoian seems legit. I am shocked.
"But until I don't hear a confirmation from Dropbox I am going and assume that all this never really happened and it's just a prank."
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.
People have been slamming Dropbox quite a bit, and it's not all entirely unwarranted.
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.
Well, this definitely cinches it. I had stuck with Dropbox thru the whole "your files aren't THAT encrypted" debacle because I have nothing worth hiding. But, this complete incompetence has convinced me that it isn't worth the risk!
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.
"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 suspect what that comment means is that Dropbox have traded security for ease of use at a fundamental level - compared to something like tarsnap (which is dedicated to doing backups in a very secure way) Dropbox does look a lot less secure but it is also a lot easier to use and supports a much wider ranges of uses.
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.
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).
Neither de-duplication nor web access require server-side encryption/decryption. Here's how you do a Dropbox-like service with all encryption handled by the clients, but that allows de-duplication and web access. Let's call the service DBL (for Dropbox-like).
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).
What makes you think 'capacity' has anything to do with it? I'm sure those smart people you think work there could get security right, but that doesn't mean management has budgeted the resources for it.
Have you looked at JungleDisk? I have never used Dropbox, but from what I can tell they are similar. JungleDisk works with S3 or RackSpace Cloud storage. You can store files encrypted or unencrypted. Everything is transmitted over SSL. My data can only be accessed with my S3 access keys. It can mount/map a drive, do automatic backups or keep directories in sync across multiple computers.
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.
Interesting. Do you know of any alternatives? One of the things I really like about JungleDisk is it uses _my_ S3 bucket. I have apps that use the data in my S3 bucket and it is also nice to be able to access it using JungleDisk.
Not an exact clone, but have you tried Wuala? There are using client-side encryption - so even if they wanted to they cannot read the content of your files.
OSX. Specifically Snow Leopard on a Macbook. I tried it a month or two ago.
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.
For the record, Arash isn't some random support guy, he's the CTO.
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.
They say that less than 1% of all of their users logged in during the vulnerable time frame. I suspect those are weasel words to downgrade the apparent severity of the problem. A more useful metric would be # user logins during vulnerable timeframe / # user logins per day.
The fact that this could happen is a fairly significant indictment of their technical capabilities and the amount of trust they deserve when it comes to safe-guarding your data.
If there's anyway in your code that deserves unit and integration tests, it's your authentication system.
This is the sort of thing where the submitter (at pastebin in this case) should be absolutly sure that the bug is fixed from Dropbox' side before telling the hole world about it.
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 did contact Dropbox and was told, essentially, "it's a glitch, don't worry about it."
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.
Dropbox very temporarily failed open (i.e. let people in without actually verifying their password).
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?
Last time the Dropbox security thing was in the news, regardless of your personal preference on what encryption keys dropbox should have been using, the issue and more importantly the way they handled it made me question their abilities. Then they sent a DMCA takedown notification notification to someone they were just trying to censor, and now they temporarily set their auth method to "allow any password".
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.
> I've moved to rsync.net. Its uglier, but at least they know what the fuck they're doing.
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.
> Then they sent a DMCA takedown notification notification to someone they were just trying to censor...
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.
Honestly the whole DMCA explanation from the executive team sounded like finding an explanation that fits. I hate that people read a comment like that then turn around and claim it to be the truth as you are doing.
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.
I must remind you that DMCA email did contain name of the company who sent it (and it was "Dropbox", if I remember it correctly). I guess, Dropbox administrator had to type it by hand (I doubt they frequently send DMCAs from "Dropbox") - and it is hard to imagine that UI was unclean on purporse of that field.
This is completely unfair to Drew and also out of line.
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.
What is "out of line" is attacking me for operating on a default-untrusted policy instead of a default-trusted policy. We all don't share your happy Drew Houston story do we?
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.
I can relate with "I tried believing in the best in people. It stopped working." I've had some nasty experiences as well. I've been burnt, badly, a lot. By both family and friends.
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.
I think there's a difference between deciding that you're skeptical, so that you're not going to act in a way that risks too much; versus publicly implying that it's actually a lie.
I know. I didn't bring that up to accuse them of malice as far the DMCA part, I brought that up as an example that dropbox employees don't understand what their own internal tools do.
I don't think that is as damning as you seem to. Once a company reaches more than a handful of people, knowing all the tools inside and out (especially in the divide between development and support, which this particular case highlighted) becomes impossible.
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.
I'd suspect that rsync's security advantage is more related to their obscurity than their superiority. My personal site has not been compromised by LulzSec or Anonymous, for instance, but that's simply because I haven't attracted the attention. I'm sure my Wordpress, FTP or hosting passwords could be discovered by some attack.
If it's online, it's not safe, period. Not combination of encryption, or BSD*, or any operating system will make it safe. Why? Human error.
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.
What's your standing -- how were you harmed? What are the damages?
You can't sue someone just because you don't like their behavior. You need to actually suffer a loss as a result of their behavior, before you've got any standing in court.
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.