6 ms·

> Just as important as what we do do is what we don’t. For example, we don’t do full message encryption (e.g. PGP) in the browser. In theory it means you “don’t

by gst 9y ago

> Just as important as what we do do is what we don’t. For example, we don’t do full message encryption (e.g. PGP) in the browser. In theory it means you “don’t have to trust us”. However in reality, every time you open your email you would be trusting the code delivered to your browser. If the server were compromised, it could easily be made to return code that intercepted and sent back your password next time you logged in; it could even just do this for specific users. It is very unlikely that a user would notice. I don't agree. I don't want full message encryption because I'm afraid that my email provider is reading my messages, but because I'm storing years worth of emails in my mailbox. With a provider such as ProtonMail that encrypts incoming messages with my personal key I know that if someone manages to get unauthorized access to my mailbox that person would only be able to read new emails, but none of my already archived mails. Of course it's possible that the intruder also manages to change the JS code returned to the client, but that's not the case for all of the possible scenarios where someone gets access to my mailbox. Full message encryption does not provide perfect security, but is able to significantly raise the provided level of security.

BCM43 9y ago
For most providers, like Protonmail, the decryption password is the same as your login password. I'm curious what scenario you see allowing someone other than the provider to get access to your mailbox but not also your decryption key.
- dboreham 9y ago
  That could happen via a breach of the provider's servers, or through dumpster diving for a discarded drive that the provider didn't properly wipe (in the case the data wasn't also encrypted at rest).
  - brongondwana 9y ago
    Email at FastMail is encrypted at rest in this sense (full drive encryption). It's not encrypted with a separate password per-user. We don't see any security benefits there, given that every user logs in almost every day, and if they have linked a device (many of our users use IMAP from mobile clients) they will connect and sync every time there's an update. Which changes the vector to "hack server, passively monitor for a couple of hours, gain access". The logical backflips and single-minded security outlook required to consider that significantly different from "hack server, gain access" are the kind of security theater we studiously avoid. Full disk encryption is a clear win with no significant downsides (slightly higher CPU consumption). Per-user encryption while still providing a full email service is not a clear win, and it has significantly higher downsides.
- whyagaindavid 9y ago
  For proton mail you could set different passwords for decryption and login
- gst 9y ago
  ProtonMail doesn't have access to the decryption password as it is not transferred to the server. Instead the client sends a password that's derived from it: https://protonmail.com/blog/encrypted_email_authentication/ https://protonmail.com/blog/encrypted_email_authentication/
  - carussell 9y ago
    The "client" is a webpage that exists as one of many assets delivered to your browser by the ProtonMail webmail server. The server has access to the password at any time if it wants it.
- arghwhat 9y ago
  The decryption password is not the same as the login password for ProtonMail. Logging in at minimum requires entering your username, your login password, and your mailbox password. The result is security at rest, which fastmail does not have. ProtonMail's web app is open-source, and can be deployed locally if you wish to remove the chance of an evil app deployment. If you use the official deployment, an evil update can obtain your mailbox password, in which case the the adversary (that is, the one capable of pushing the update) observe a security level equivalent to if security at rest was not implemented. However, even in this case, the data on the mail-servers is still protected from everyone else, so while a single adversary has observed a security level identical to that of fastmail (i.e. no security at rest), everyone else still observes a secured mailbox. Not having security at rest is, in my opinion, dangerous.
  - terraforming 9y ago
    That's wrong. You no longer need a third password in protonmail. All you need to have, in order to login, is the username and a password. If you've 2FA enabled, you need the 2FA code of-course.
    - arghwhat 9y ago
      I think you mean second password rather than third, but as a user of ProtonMail, I need one username, two passwords and one 2FA token to get in, with only login username/password being kept in a password manager (and all password managers get confused by multiple passwords, so I couldn't keep them all even if I changed my mind and wanted to). ProtonMail may have the option (I am not aware of this) to have login password and mailbox password set the same (and not prompt you twice if this is the case), but they are still separate passwords. You, as user, control whether you want them to be the same or not. If you chose this, the application then has an option for convenience to use the same input for both tasks. This is opposed to a service where they are always the same, so that the password send to the backend is the same used to decrypt your data.
- brightball 9y ago
  That's definitely not the default with Protonmail. They'll allow you to change it to that if you really want to though. On mine at least, proton prompts me for username and password, then 2 factor auth, then the decryption code.
  - arosier 9y ago
    One password is now the default for new ProtonMail accounts. For accounts that were created before this authentication was released, you will remain on 2 password until you update it in your settings.
danenania 9y ago
It would be fine if apps with in-browser crypto only made this sort of claim, but many/most of them are either stating or implying that users don't need to trust the service. This is a dangerous mismanagement of expectations, and it can be argued that the risk of creating a false sense of security far outweighs any of the benefits you mention.
arghwhat 9y ago
ProtonMail's web client is open source, and can be deployed locally if you wish to avoid scenarios where an evil application is deployed. Their native apps are unfortunately not open source, though.
- tptacek 9y ago
  Deploying a browser Javascript application locally does not automatically protect you from serverside malicious Javascript; you have to know a lot more about how the application is structured to know whether it's even helpful.
  - arghwhat 9y ago
    Deploying any application locally puts you entirely at mercy of whoever wrote it, and those that know how to abuse it. That holds true for any type of application. However, in this context, deploying this particular self-contained application locally protects against the hypothetical attack where a genuine application is later modified to turn malicious. It is relatively easy to look for and identify any execution of server-side content. To prove that an application is not intentionally malicious, you would have to inspect the source. To prove that an application cannot be malicious, directly or indirectly, intentionally a not, you will need full formal verification of the application. And that verification only holds if you have formal verification of what it runs on.
    - tptacek 9y ago
      No, it does not. You've missed my point. Deploying a browser JS application locally would help you if you could be sure that the application never loaded any additional Javascript from the server during execution. But browser JS applications can in fact do that, and so local deployment does not help as much as you think it does.
      - _Codemonkeyism 9y ago
        Yes you would probably need to play with headers.
bluGill 9y ago
You can use PGP then. However using PGP well turns out to be hard. You can to have the client local (and built by a trusted source), not a web client. You have to ensure you didn't forget your private key. You have to understand how it works and what the limits are to ensure that you don't accidentally break something. For what fastmail is doing providing PGP is the wrong answer: there is no way they can provide it safely. In particular a government can force them to replace their web PGP with a hacked version. (and some hacks can be very subtle such that you are unlikely to notice in a code review - remember we have a government's resources created it) That isn't to say PGP is bad. PGP is better than what they offer when you use it correctly. However there are many ways to use PGP wrong which make it seem like your messages are secure, but they are in fact not. This is probably worse than not using PGP at all, at least if you know your messages are not secure you won't do anything that requires security.
- mike-cardwell 9y ago
  All of my email is encrypted using PGP on the way in. I can read it on my laptop, desktop and phone because I use Evolution, Mutt and K-9 Mail, all three of which support PGP and all three of which I can use with my Yubikey. If you compromise my mailbox, you can't read any old or new email, and you can trigger as many password reset emails as you want, you wont be able to read them.

by gst 9y ago

BCM43 9y ago

For most providers, like Protonmail, the decryption password is the same as your login password. I'm curious what scenario you see allowing someone other than the provider to get access to your mailbox but not also your decryption key.

dboreham 9y ago
That could happen via a breach of the provider's servers, or through dumpster diving for a discarded drive that the provider didn't properly wipe (in the case the data wasn't also encrypted at rest).
- brongondwana 9y ago
  Email at FastMail is encrypted at rest in this sense (full drive encryption). It's not encrypted with a separate password per-user. We don't see any security benefits there, given that every user logs in almost every day, and if they have linked a device (many of our users use IMAP from mobile clients) they will connect and sync every time there's an update. Which changes the vector to "hack server, passively monitor for a couple of hours, gain access". The logical backflips and single-minded security outlook required to consider that significantly different from "hack server, gain access" are the kind of security theater we studiously avoid. Full disk encryption is a clear win with no significant downsides (slightly higher CPU consumption). Per-user encryption while still providing a full email service is not a clear win, and it has significantly higher downsides.
whyagaindavid 9y ago
For proton mail you could set different passwords for decryption and login
gst 9y ago
ProtonMail doesn't have access to the decryption password as it is not transferred to the server. Instead the client sends a password that's derived from it: https://protonmail.com/blog/encrypted_email_authentication/ https://protonmail.com/blog/encrypted_email_authentication/
- carussell 9y ago
  The "client" is a webpage that exists as one of many assets delivered to your browser by the ProtonMail webmail server. The server has access to the password at any time if it wants it.
arghwhat 9y ago
The decryption password is not the same as the login password for ProtonMail. Logging in at minimum requires entering your username, your login password, and your mailbox password. The result is security at rest, which fastmail does not have. ProtonMail's web app is open-source, and can be deployed locally if you wish to remove the chance of an evil app deployment. If you use the official deployment, an evil update can obtain your mailbox password, in which case the the adversary (that is, the one capable of pushing the update) observe a security level equivalent to if security at rest was not implemented. However, even in this case, the data on the mail-servers is still protected from everyone else, so while a single adversary has observed a security level identical to that of fastmail (i.e. no security at rest), everyone else still observes a secured mailbox. Not having security at rest is, in my opinion, dangerous.
- terraforming 9y ago
  That's wrong. You no longer need a third password in protonmail. All you need to have, in order to login, is the username and a password. If you've 2FA enabled, you need the 2FA code of-course.
  - arghwhat 9y ago
    I think you mean second password rather than third, but as a user of ProtonMail, I need one username, two passwords and one 2FA token to get in, with only login username/password being kept in a password manager (and all password managers get confused by multiple passwords, so I couldn't keep them all even if I changed my mind and wanted to). ProtonMail may have the option (I am not aware of this) to have login password and mailbox password set the same (and not prompt you twice if this is the case), but they are still separate passwords. You, as user, control whether you want them to be the same or not. If you chose this, the application then has an option for convenience to use the same input for both tasks. This is opposed to a service where they are always the same, so that the password send to the backend is the same used to decrypt your data.
brightball 9y ago
That's definitely not the default with Protonmail. They'll allow you to change it to that if you really want to though. On mine at least, proton prompts me for username and password, then 2 factor auth, then the decryption code.
- arosier 9y ago
  One password is now the default for new ProtonMail accounts. For accounts that were created before this authentication was released, you will remain on 2 password until you update it in your settings.

danenania 9y ago

It would be fine if apps with in-browser crypto only made this sort of claim, but many/most of them are either stating or implying that users don't need to trust the service. This is a dangerous mismanagement of expectations, and it can be argued that the risk of creating a false sense of security far outweighs any of the benefits you mention.

arghwhat 9y ago

ProtonMail's web client is open source, and can be deployed locally if you wish to avoid scenarios where an evil application is deployed. Their native apps are unfortunately not open source, though.

tptacek 9y ago
Deploying a browser Javascript application locally does not automatically protect you from serverside malicious Javascript; you have to know a lot more about how the application is structured to know whether it's even helpful.
- arghwhat 9y ago
  Deploying any application locally puts you entirely at mercy of whoever wrote it, and those that know how to abuse it. That holds true for any type of application. However, in this context, deploying this particular self-contained application locally protects against the hypothetical attack where a genuine application is later modified to turn malicious. It is relatively easy to look for and identify any execution of server-side content. To prove that an application is not intentionally malicious, you would have to inspect the source. To prove that an application cannot be malicious, directly or indirectly, intentionally a not, you will need full formal verification of the application. And that verification only holds if you have formal verification of what it runs on.
  - tptacek 9y ago
    No, it does not. You've missed my point. Deploying a browser JS application locally would help you if you could be sure that the application never loaded any additional Javascript from the server during execution. But browser JS applications can in fact do that, and so local deployment does not help as much as you think it does.
    - _Codemonkeyism 9y ago
      Yes you would probably need to play with headers.

bluGill 9y ago

You can use PGP then. However using PGP well turns out to be hard. You can to have the client local (and built by a trusted source), not a web client. You have to ensure you didn't forget your private key. You have to understand how it works and what the limits are to ensure that you don't accidentally break something. For what fastmail is doing providing PGP is the wrong answer: there is no way they can provide it safely. In particular a government can force them to replace their web PGP with a hacked version. (and some hacks can be very subtle such that you are unlikely to notice in a code review - remember we have a government's resources created it) That isn't to say PGP is bad. PGP is better than what they offer when you use it correctly. However there are many ways to use PGP wrong which make it seem like your messages are secure, but they are in fact not. This is probably worse than not using PGP at all, at least if you know your messages are not secure you won't do anything that requires security.

mike-cardwell 9y ago
All of my email is encrypted using PGP on the way in. I can read it on my laptop, desktop and phone because I use Evolution, Mutt and K-9 Mail, all three of which support PGP and all three of which I can use with my Yubikey. If you compromise my mailbox, you can't read any old or new email, and you can trigger as many password reset emails as you want, you wont be able to read them.