5 ms·

I'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 bucke

I'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.

cperciva 15y ago
If you're a good driver, you'll be paying attention to the traffic behind you and avoid being rear-ended. But ultimately what it comes down to is that if 99% of users make a particular error, it isn't useful to say "oh, that's user error".
- sunchild 15y ago
  OK. I think I understand now. I still don't think it's fair to call it defective design (and I'm not really certain that you ever did call JD's password privacy defective, BTW). More like a design that is unsafe in the hands of the typical driver, perhaps. Why do I care? I just want to understand the risks for someone like me, who has taken care to choose very strong passwords. My conclusions from all of this: (1) The data integrity issue is serious because it presents an opportunity for introduction of malicious code, creates a risk of data loss, and may lead to security breaches. (2) The local binary is opaque, and therefore presents a theoretical risk of compromising even the most "close to the vest" key management strategy. (3) The password protection issue is a serious shortcoming that can, and should, be mitigated by choosing strong passwords. Yes?!
  - cperciva 15y ago
    Yes, that sounds like an accurate summary.
    - sunchild 15y ago
      Cool, thanks for hanging in there with me. I found this very informative.
cipherpunk 15y ago
One way requires the user to have a drastically stronger password to be safe, and the other significantly strengthens passwords, protecting a subclass of users that will always exist (those that are unable to remember strong passwords or don't know enough about the dangers of password cracking to know how to effectively choose passwords). It is madness to defend the use of MD5 for password hashing these days. It is clearly not designed for that at all.
SoftwareMaven 15y ago
The issue is how fast the password can be broken. MD5 is a very fast hash, so even a relatively slow computer can do a lot of attempts very quickly. Bcrypt, on the other hand, can be tuned to go as slow as you want. You can force it to take 250 milliseconds, regardless of how good or bad the password is. And that is the fundamental flaw. Jungle Disk's key derivation makes it possible to crack your password in a reasonable time; bcrypt does not. Because of that decision, everybody's data is much less safe as a result (I'm referring to everybody's data in a statistical sense: the average password sucks and is easily broken in this scheme, so the average file is at risk). As a provider of security software (like my company is doing), Jungle Disk should be doing everything it can to help users keep their data secure. Jungle Disk isn't doing that.

cperciva 15y ago

If you're a good driver, you'll be paying attention to the traffic behind you and avoid being rear-ended. But ultimately what it comes down to is that if 99% of users make a particular error, it isn't useful to say "oh, that's user error".

sunchild 15y ago
OK. I think I understand now. I still don't think it's fair to call it defective design (and I'm not really certain that you ever did call JD's password privacy defective, BTW). More like a design that is unsafe in the hands of the typical driver, perhaps. Why do I care? I just want to understand the risks for someone like me, who has taken care to choose very strong passwords. My conclusions from all of this: (1) The data integrity issue is serious because it presents an opportunity for introduction of malicious code, creates a risk of data loss, and may lead to security breaches. (2) The local binary is opaque, and therefore presents a theoretical risk of compromising even the most "close to the vest" key management strategy. (3) The password protection issue is a serious shortcoming that can, and should, be mitigated by choosing strong passwords. Yes?!
- cperciva 15y ago
  Yes, that sounds like an accurate summary.
  - sunchild 15y ago
    Cool, thanks for hanging in there with me. I found this very informative.

cipherpunk 15y ago

One way requires the user to have a drastically stronger password to be safe, and the other significantly strengthens passwords, protecting a subclass of users that will always exist (those that are unable to remember strong passwords or don't know enough about the dangers of password cracking to know how to effectively choose passwords). It is madness to defend the use of MD5 for password hashing these days. It is clearly not designed for that at all.

SoftwareMaven 15y ago

The issue is how fast the password can be broken. MD5 is a very fast hash, so even a relatively slow computer can do a lot of attempts very quickly. Bcrypt, on the other hand, can be tuned to go as slow as you want. You can force it to take 250 milliseconds, regardless of how good or bad the password is. And that is the fundamental flaw. Jungle Disk's key derivation makes it possible to crack your password in a reasonable time; bcrypt does not. Because of that decision, everybody's data is much less safe as a result (I'm referring to everybody's data in a statistical sense: the average password sucks and is easily broken in this scheme, so the average file is at risk). As a provider of security software (like my company is doing), Jungle Disk should be doing everything it can to help users keep their data secure. Jungle Disk isn't doing that.