Xavier59's answer is correct, in that protonmail uses SRP. Therefore (under normal circumstances) your password is never sent to protonmail's server.
I sent the following email to [email protected] 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
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:
- Are browsers suitable for cryptography?
- 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
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:
We hope this helps clarify a bit our thoughts on the topic. Thank you
again for reaching out to us.