Can protonmail access my passwords and hence my secrets?

Question

protonmail provides encrypted "zero-access" encryption mailboxes. The way they explain "zero-access" is, at least for me, similar to zero-knowledge encryption. However protonmail has in its servers my private keys. They say that the keys are encrypted as well, but they also have in their servers my password for that encryption. Therefore, it seems to me that protonmail could at any time access my private keys and my mailbox.

Is this correct, or am I missing something? Is this the reason why they do not call it zero-knowledge encryption?

Answer 1

Xavier59's answer is correct, in that protonmail uses SRP. Therefore (under normal circumstances) your password is never sent to protonmail's server.

However, the SRP is implemented in javascript, which is served by protonmail's server. If protonmail were to be compromised, or if protonmail were to 'go rogue', they could easily serve javascript that captures your password after you enter it, and sends the password back to their servers. Then, they would have everything necessary to decrypt your private key, and then decrypt your messages.

This is why javascript cryptography is a 'chicken-and-egg' problem. If you can't trust the server with your secrets, then how can you trust the server to deliver secure code? See https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/ for some good reading on this subject.

---

Edit 9/24/2020

I sent the following email to security@protonmail.com on 9/21/2020, inviting Protonmail to weigh-in on this subject. I've not received a response from Protonmail as of yet, but if/when I do, I will update here.

Hello ProtonMail Team,

First off, I’d like to thank you for building ProtonMail. You’ve managed to make end-to-end encrypted email as simple to use as webmail, which is truly groundbreaking.

I am a moderator at security.stackexchange.com, and several questions have come up recently about ProtonMail (and other services that rely on in-browser crypto to implement ‘zero-access’ systems), in the context of the ‘Browser Crypto Chicken-and-Egg Problem’ .

On your page at https://protonmail.com/security-details, it reads, ‘your data is encrypted in a way that makes it inaccessible to us’, and ‘data is encrypted on the client side using an encryption key that we do not have access to’. However, it would seem that if ProtonMail were to ‘go rogue’ (or if ProtonMail were to be coerced, or if an attacker were to gain access to ProtonMail’s servers, etc.), it would be possible for ProtonMail to modify the client-side code served by Protonmail’s servers, such that the code captures the user’s private keys or plaintext information, and sends these secrets back to the server (or somewhere else). As you may know, this problem was coined ‘The Browser Crypto Chicken-and-Egg Problem’ by security researcher Thomas Ptecek in 2011. In other words, if users can’t trust the server with your secrets, than how can users trust the server to serve secure crypto code?

Copied below are links to a few questions on security.stackexchange.com where this subject has come up recently. Some of these questions (and their ensuing responses) also contain some interesting ideas around solutions to this problem:

Can protonmail access my passwords and hence my secrets?

Solution to the ‘Browser Crypto Chicken-and-Egg Problem’?

What’s wrong with in-browser cryptography in 2017?

Problems with in Browser Crypto

I’m curious if ProtonMail has any comment on this subject. Specifically, if ProtonMail were to go rogue, would it be possible for ProtonMail to access users’ secrets by modifying the client-side code that you serve? If so, has ProtonMail considered any solutions to this problem? I’d be interested in reading any comments that you have on this subject – either in a response from you to this email; or better yet, in a response from you to one of the questions above on security.stackexchange.com.

---

Edit 10/20/2020

I received the following reply from the security team at ProtonMail. For anyone interested in this subject, I recommend watching the video referenced in the reply.

The robustness of ProtonMail’s cryptographic architecture, and whether or not users can trust it, is something that comes up from time to time.The discussion around whether or not ProtonMail could access users’ secrets by modifying the client-side code boils down to two more fundamental questions:

1. Are browsers suitable for cryptography?
2. Can you trust the source of the software you use?

With regards to the first question, browsers have evolved a lot since security researcher Thomas Ptecek published his report in 2011. Currently, browsers expose not only a the systems built-in random number generator, but the entire Web Crypto API, which means that cryptography can be done natively, instead of implemented via JavaScript. ProtonMail does indeed leverage the Web Crypto API instead of doing cryptography in JavaScript. The second question is more difficult to answer. It’s a question that is not specific to ProtonMail, but applies to all software in existence today (including software which is not downloaded from web browsers). While open-source code helps provide transparency, testing and verifying whether or not software has been compromised is not feasible for the average user. Some people view web browsers to be more susceptible to this problem (we don’t entirely agree because users don’t really verify the code of the software they download from e.g. Google Play either), and if that is the case, one mitigation ProtonMail provides is by offering open source native applications on all platforms, so you can use the service without using a web browser if you wish. Long story short, in today’s software delivery model, be this through the web browser or via another channel, users need to trust the source and hope that someone with the necessary skills notices and flags the tampering. We recognize that this is an issue (not unique to ProtonMail), and are working on a solution, called Source Code Transparency. The idea is to publish a hash of the source code which everyone verifies to ensure that they’re all running the same source code. An independent third party would then evaluate and assert the integrity of the delivered software. This process would not only increase everybody’s trust in the source code, but would also make it much more difficult for us to attack any specific user (as running an attack would mean all our users, who run the same source code, would be impacted, and so the risk of detection is higher). You can find more details at a talk we gave at FOSDEM (Free and Open source Software Developers’ European Meeting) earlier this year: https://archive.fosdem.org/2020/schedule/event/dip_securing_protonmail/ We hope this helps clarify a bit our thoughts on the topic. Thank you again for reaching out to us.

Answer 2

You are wrong in your assumption that protonmail stores the password used for the encryption of your private key.

Protonmail uses the Secure Remote Password Protocol (SRP on wikipedia - Protonmail blog post about SRP) and so they only store a verifier that is irreversibility related to your password.
When entering your password on the login form of protonmail, some javascript is executed client side and generates this verifier that it sends to protonmail.
Upon verification, protonmail returns the encrypted version of your private key which then gets decrypted client side using your password. This private key is then used to decrypt your emails.