4 ms·
Setting aside the data integrity issues: I think the author's point about privacy is valid, and a little silly. If I understand correctly (the article is very
by sunchild 15y ago
Setting aside the data integrity issues:
I think the author's point about privacy is valid, and a little silly. If I understand correctly (the article is very confusingly worded in some places), he is saying that weak passwords are weak. Anyone who cares about privacy should already be choosing long, complex, strong passwords for this kind of application.
Also, I'm confused about one feature of JD. When I signed up years ago, they allowed me to hold my key privately and it never left the client. I had the option to upload that key to the server, if I wanted to, or not. I understand from the article that the client might misbehave and, for example, share my key in ways I don't want it to. Am I getting this right?
When I looked into secure cloud-based storage two years ago, I found that JD was the best mix of privacy and convenience, if for no other reason than it could be deployed on a mix of Windows, Mac and Linux boxes. It was clear even then that data integrity was the weak link/trade off.
I'm interested in hearing about the latest, best solutions for easy, cross-platform, secure backups to cloud services that offer better data integrity.
- tptacek 15y agoThis article points out two flaws. Neither of them are silly. First, there's no integrity protection on data stored on Jungledisk. Jungledisk can own up your machine. That's not a good property for a secure backup system to have. Second, the key derivation scheme it uses makes every passphrase, no matter how carefully chosen, drastically weaker. I'm glad you like Jungledisk and I don't think you need to read stories like this as an indictment of your choice or a demand to change services. But it doesn't help to downplay them.
- Locke1689 15y agoSecond, the key derivation scheme it uses makes every passphrase, no matter how carefully chosen, drastically weaker. I'd just like to repeat this point because it's so important. The password verification method in JungleDisk is fundamentally broken and needs to be rearchitected immediately. For non-cryptography people, this is similar to the vulnerability that allowed passwords to be retrieved from the Gawker database hack a couple months ago (just not quite as vulnerable).
- sunchild 15y agoOK, I freely admit that I'm not an expert in this area, so I'll rescind my "silly" comment. But, "drastically weaker" than what? If the password is strong, JD doesn't make it weak. JD just doesn't make it as strong as it should/could? Is this correct?
- cperciva 15y agoBut, "drastically weaker" than what? If the password is strong, JD doesn't make it weak. JD just doesn't make it as strong as it should/could? Is this correct? Correct. The vast majority of people can't remember strong passwords, so it's necessary to "strengthen" them using a good key derivation function. Jungle Disk doesn't do this.
- sunchild 15y agoOK, well, I guess I don't see how that's fairly described as a "flaw" in JungleDisk. I can understand why a responsible developer should assume their users are simple-minded, mouth-breathers who can't be trusted to choose a proper password (and I'm sure there's plenty of evidence to support that assumption), but it just isn't right to characterize JungleDisk as compromised from a security perspective because it relies on the user to choose a strong password.
- cperciva 15y agoSaying that Jungle Disk is secure as long as users pick strong passwords is like saying that the Ford Pinto is safe as long as drivers don't get into rear-end collisions. In both cases you're asking for behaviour which we know perfectly well that users don't exhibit; and in both cases there is a simple fix for the problem. The Ford Pinto is an unsafe car, and Jungle Disk is an insecure backup service.
- sunchild 15y agoI'm trying to understand this. Again, I'm no expert. I can see why the data integrity issues may allow external factors to compromise the security of my buckets and/or local device. That's me in a Pinto, at the mercy of the bad driver behind me. I don't see how password strength is open to any external factor; it would seem to be purely a matter of user error. That part doesn't seem to fit the Pinto analogy. That's where I'm struggling to follow your article.