5 ms·

>>There is no way to ever prove or disprove whether any encryption was ever happening at all, and whether it was or not makes little difference. I get that Lav

by jere 13y ago

>>There is no way to ever prove or disprove whether any encryption was ever happening at all, and whether it was or not makes little difference. I get that Lavabit was fundamentally flawed, but I don't know about this part. Lavabit saying they can't read your email seems analogous to any website that requires a password saying they can't read your password, because it is hashed. That's an important and reasonable claim, right? It means at the very least all the passwords/emails can't be download in bulk and read immediately. You don't know for sure what hashing methods are being used on any given site, but to say it doesn't matter at all.... is kind of like saying the operators should just leave all of your passwords in plaintext in the database because they could intercept them at log in anyway.

hyperpape 13y ago
I think the point is that while it does matter in some ways, it doesn't matter for security issues Lavabit claimed it addressed. Think of a site that says your password is secure. When you call them on it, they say "well, we do store your passwords in plaintext, but we use SSL to transfer them."
- Dylan16807 13y ago
  I don't understand your analogy. 100%* of sites with passwords use the same method, transmitting the plain text to the server where it is hashed and discarded. Do you want 0%* of sites to claim that passwords are secure, even if they use a well-configured bcrypt and follow best practices? *rounded to the nearest percent
  - hyperpape 13y ago
    I meant SSL. Edited for clarity.
  - gknoy 13y ago
    It's a difference in who you care about it being secure from, and what it is you're trying to protect. SSL is enough (I think?) to prevent a random attacker from snooping your traffic to get your _credentials_. However, now imagine a judge gives them a subpoena saying, "We need Dylan's password. You receive it in plaintext over a secure tunnel, and you must give it to us." There's no wiggle room for that kind of request, and then a court-backed attacker would be able to do things like use your password as evidence, and probably even use it to try to gain access to other things of yours. A way to prevent a court-ordered harvesting of your credentials would be for the service to have your public key, and require you to cryptographically sign something as part of the login process: Your secret stays secret on your end. Back to what you are trying to protect. There are many things that can be secure, and from different types of attackers. We would ideally like to be able to keep our credentials (keys, passwords) secure from attackers both black-hat and police-hat, and we would like to also be able to keep the contents of our communications secret from those same entities. Most services safeguard your credentials against everyone except the court, and try to only protect your data similarly.
    - Dylan16807 13y ago
      Well I would deal with that problem in an entirely different way. Courts should not have the power to compel either party in a private communication to keep records of what was said/transmitted.
  - betterunix 13y ago
    "Do you want 0%* of sites to claim that passwords are secure, even if they use a well-configured bcrypt and follow best practices?" Yes, because passwords are insecure even if you follow "best practices." Here is a straightforward attack: http://www.businessinsider.com/how-mark-zuckerberg-hacked-into-the-harvard-crimson-2010-3 http://www.businessinsider.com/how-mark-zuckerberg-hacked-in...
    - Dylan16807 13y ago
      Uhh, I don't think best practices include logging the passwords people try to login with.
      - betterunix 13y ago
        You are missing the point. It makes no difference if your website is following best practices if your users enter their passwords on a website that fails to do so. Maybe your users are using the same passwords in many places. Maybe they accidentally entered the password for one website when trying to log in to another because their username is the same.
gknoy 13y ago
No. It matters because courts have ruled that your system cannot claim "averting its eyes" as a defense against providing intercepted data. Recent (in the past year) court rulings have decided that passwords in memory are accessible, even if your softwre normally throws them away -- so you could be legally compelled to implement interception of those. (IANAL, and this assumes that I understood the things others wrote about these...) Sure, it's likely only in some circuits, but I'd be surprised if other judges did not rule similarly. A safer system would be where YOU create your own key pair, and only send your public key to the secure mail provider. You know that your e-mail, your text, etc is never in cleartext on the remote system, which means that even if that system is completely compromised, all an attacker is getting is encrypted copies of your communications. (Well, and cleartext metadata, since you need that for sending mail.) In such a system, you know that encryption is happening, because you are doing it on your computer before sending bits to the server. (You'd also need a way to exchange keys in a way which doesn't require trusting the secure server not to be MITM-ing you.) Even that's likely not fully safe, but it's very different from having the server avert its eyes and pretend you never sent it plaintext keys/credentials.
- jedbrown 13y ago
  > you know that encryption is happening, because you are doing it on your computer before sending bits to the server If your server receives email for you over SMTP, you are trusting the server not to log a copy before encrypting, trusting that there is no intruder on the server, trusting that someone (like the NSA) is not logging traffic between servers, and trusting the sender's machines to the same. Similarly when you send email in a way that can be read by your recipient's provider. You have to encrypt for an individual, as with PGP, for there to be meaningful security, at which point your provider's "secure" practices are only covering a bit of metadata, some of which will be leaked when communicating the message. The problem with PGP is that it has a complicated trust model, poor client integration, and does not provide forward secrecy. The first two may be fixable via better user interfaces (which includes breaking from traditional webmail) but forward secrecy would need protocol support is in conflict with the asynchrony email currently enjoys.
betterunix 13y ago
"is kind of like saying the operators should just leave all of your passwords in plaintext in the database because they could intercept them at log in anyway." Actually, as with encrypted email, the cryptography research community already knows how to solve that problem: https://en.wikipedia.org/wiki/Zero-knowledge_password_proof https://en.wikipedia.org/wiki/Zero-knowledge_password_proof
basch 13y ago
What about something similar to dashlane. You type in your username, it downloads a payload, then you type in your password and it is decrypted locally. Your password never leaves your machine.

by jere 13y ago

hyperpape 13y ago

I think the point is that while it does matter in some ways, it doesn't matter for security issues Lavabit claimed it addressed. Think of a site that says your password is secure. When you call them on it, they say "well, we do store your passwords in plaintext, but we use SSL to transfer them."

Dylan16807 13y ago
I don't understand your analogy. 100%* of sites with passwords use the same method, transmitting the plain text to the server where it is hashed and discarded. Do you want 0%* of sites to claim that passwords are secure, even if they use a well-configured bcrypt and follow best practices? *rounded to the nearest percent
- hyperpape 13y ago
  I meant SSL. Edited for clarity.
- gknoy 13y ago
  It's a difference in who you care about it being secure from, and what it is you're trying to protect. SSL is enough (I think?) to prevent a random attacker from snooping your traffic to get your _credentials_. However, now imagine a judge gives them a subpoena saying, "We need Dylan's password. You receive it in plaintext over a secure tunnel, and you must give it to us." There's no wiggle room for that kind of request, and then a court-backed attacker would be able to do things like use your password as evidence, and probably even use it to try to gain access to other things of yours. A way to prevent a court-ordered harvesting of your credentials would be for the service to have your public key, and require you to cryptographically sign something as part of the login process: Your secret stays secret on your end. Back to what you are trying to protect. There are many things that can be secure, and from different types of attackers. We would ideally like to be able to keep our credentials (keys, passwords) secure from attackers both black-hat and police-hat, and we would like to also be able to keep the contents of our communications secret from those same entities. Most services safeguard your credentials against everyone except the court, and try to only protect your data similarly.
  - Dylan16807 13y ago
    Well I would deal with that problem in an entirely different way. Courts should not have the power to compel either party in a private communication to keep records of what was said/transmitted.
- betterunix 13y ago
  "Do you want 0%* of sites to claim that passwords are secure, even if they use a well-configured bcrypt and follow best practices?" Yes, because passwords are insecure even if you follow "best practices." Here is a straightforward attack: http://www.businessinsider.com/how-mark-zuckerberg-hacked-into-the-harvard-crimson-2010-3 http://www.businessinsider.com/how-mark-zuckerberg-hacked-in...
  - Dylan16807 13y ago
    Uhh, I don't think best practices include logging the passwords people try to login with.
    - betterunix 13y ago
      You are missing the point. It makes no difference if your website is following best practices if your users enter their passwords on a website that fails to do so. Maybe your users are using the same passwords in many places. Maybe they accidentally entered the password for one website when trying to log in to another because their username is the same.

gknoy 13y ago

No. It matters because courts have ruled that your system cannot claim "averting its eyes" as a defense against providing intercepted data. Recent (in the past year) court rulings have decided that passwords in memory are accessible, even if your softwre normally throws them away -- so you could be legally compelled to implement interception of those. (IANAL, and this assumes that I understood the things others wrote about these...) Sure, it's likely only in some circuits, but I'd be surprised if other judges did not rule similarly. A safer system would be where YOU create your own key pair, and only send your public key to the secure mail provider. You know that your e-mail, your text, etc is never in cleartext on the remote system, which means that even if that system is completely compromised, all an attacker is getting is encrypted copies of your communications. (Well, and cleartext metadata, since you need that for sending mail.) In such a system, you know that encryption is happening, because you are doing it on your computer before sending bits to the server. (You'd also need a way to exchange keys in a way which doesn't require trusting the secure server not to be MITM-ing you.) Even that's likely not fully safe, but it's very different from having the server avert its eyes and pretend you never sent it plaintext keys/credentials.

jedbrown 13y ago
> you know that encryption is happening, because you are doing it on your computer before sending bits to the server If your server receives email for you over SMTP, you are trusting the server not to log a copy before encrypting, trusting that there is no intruder on the server, trusting that someone (like the NSA) is not logging traffic between servers, and trusting the sender's machines to the same. Similarly when you send email in a way that can be read by your recipient's provider. You have to encrypt for an individual, as with PGP, for there to be meaningful security, at which point your provider's "secure" practices are only covering a bit of metadata, some of which will be leaked when communicating the message. The problem with PGP is that it has a complicated trust model, poor client integration, and does not provide forward secrecy. The first two may be fixable via better user interfaces (which includes breaking from traditional webmail) but forward secrecy would need protocol support is in conflict with the asynchrony email currently enjoys.

betterunix 13y ago

"is kind of like saying the operators should just leave all of your passwords in plaintext in the database because they could intercept them at log in anyway." Actually, as with encrypted email, the cryptography research community already knows how to solve that problem: https://en.wikipedia.org/wiki/Zero-knowledge_password_proof https://en.wikipedia.org/wiki/Zero-knowledge_password_proof

basch 13y ago

What about something similar to dashlane. You type in your username, it downloads a payload, then you type in your password and it is decrypted locally. Your password never leaves your machine.