Improved Authentication for Email Encryption and Security

encrypted email authentication

Today, we are happy to announce the launch of a brand new authentication system for ProtonMail’s secure email service using just a single password.

ProtonMail launched with a two-password system—one to authenticate the user to ProtonMail, and one to decrypt the mail. The security benefit provided by this separation is easy to understand, but it has multiple usability issues.

First, two passwords are more difficult to remember than one, and it contributes to users losing access to their accounts and mail. Second, it tends to confuse password managers, one of the best ways to organize and secure passwords. Third, it makes two-factor authentication (a best-practice method to securing online accounts) a very onerous process, as the user has to enter both passwords and a two-factor code to log in.

At ProtonMail, our mission to is make secure communication easy-to-use and secure. In pursuit of these goals, we are happy to introduce both one-password and two-factor authentication support with ProtonMail 3.6.0. While ProtonMail’s authentication system has been completely redesigned, these changes are transparent to end users, and we will continue to support the legacy two-password mode.

Design Philosophy

Our basic assumption is that all servers can be compromised, and that sooner or later, ProtonMail will also be compromised. Incidents like the Yahoo breach are not isolated, and will gradually become the norm over the next decade. This is the fundamental philosophy behind our Zero Knowledge Architecture. By utilizing client side end-to-end encryption, we ensure that we do not have the ability to decrypt your emails, and thus, your communications would also be inaccessible to any attacker who does manage to breach our systems. This same philosophy was also applied when we redesigned our authentication system.

How does One-Password Mode work?

In two-password mode, there is a login password and a mailbox password. The login password authenticates the user to ProtonMail and is not stored by the client. The server will occasionally ask the user for the login password to confirm sensitive settings changes, such as password changes. The mailbox password, however is cached on the client, as it is only used to decrypt mail. Simply making the login password the same as the mailbox password is a problem, because then there is no barrier to account takeover for someone with physical possession of your device and some technical know-how.

In ProtonMail’s one-password mode, the mailbox password is derived from the login password via a one-way cryptographic password hash. The input to this hash includes a salt provided by the server on login but not stored in the client. In this way, compromise of the mailbox password does not automatically lead to compromise of the login password.

In this scheme, however, the login password cannot be sent to ProtonMail directly, as it can be used to calculate the mailbox password and thus decrypt mail. To solve this problem, we have re-engineered our entire login process to never send the login password to our server, which has the added benefit of helping protect against MITM (man-in-the-middle) attacks.

Secure Remote Password (SRP) Protocol

The Secure Remote Password (SRP) protocol is widely-tested and widely-deployed password-authenticated key agreement (PAKE) protocol which mutually authenticates both the user and server while never sending any password-equivalent data over the network. Authentication attempts cannot be replayed, and the protocol remains secure even in the presence of active tampering by a third party. More information about SRP can be found here and here.

SRP 6a (the latest revision) has been protecting all ProtonMail logins for more than two months now, and with this improvement, we are now able to safely offer one-password mode to our users with no reduction in our security guarantee. When using SRP, even an attacker who can arbitrarily read, modify, delay, destroy, repeat, or fabricate messages between ProtonMail and a user in an undetectable fashion is limited to checking only a single password guess per login attempt, which is equivalent to just trying to log in directly. Even if ProtonMail is compromised and acts maliciously, password equivalent information is never revealed. Thus, with SRP, ProtonMail’s security is greatly strengthened against MITM attacks (particularly for the native clients).

Technical Implementation Details

This section may be difficult to follow without appropriate mathematical and security background and can be skipped.

The security of SRP, like that of Diffie-Hellman, is based on the difficulty of the discrete logarithm problem. One potential issue with this is heavy precomputation via a number field sieve done for a particular modulus to enable faster breaking of the protocol.

For ProtonMail’s implementation we use multiple moduli, randomly chosen every time a user’s password is changed. This offers a number of advantages, notably the possibility of rotating out old moduli with time and limiting the motivation for precomputation, as any modulus would only apply to a subset of users.

To further protect against precomputation, we choose our own primes rather than those recommended by the TLS specification or otherwise commonly used, as these are large targets and almost certainly have been worked on by the world’s security services. We do this by choosing a random 2048-bit integer, setting the top bit to ensure it is large, and picking the first safe prime greater than or equal which has 2 as a generator of the whole group. By using safe primes, we are not vulnerable to backdoored primes. The native (mobile) clients verify the safety of the primes before use, and we also cryptographically sign the moduli to prevent tampering.

2048-bit moduli are used because that proved to be the upper limit that existing web and mobile clients can handle with acceptable performance. This size should be beyond sufficient from a security perspective for the near- and medium-term future and can be increased by rotating in new moduli.

The most widely-used implementation of SRP is TLS-SRP as described in RFC 5054. Our implementation differs from it in several ways, none of which decrease security. First, SHA-1 is a poor password hash function, and in order to migrate our existing password database we were locked into using bcrypt for this purpose anyway. We do use semi-random password salts (one random part, one non-random part) but do not use the username as the non-random part to enable login with both email addresses and usernames. As noted above, we also choose our own moduli, and the entire transaction is embedded inside certificate-based TLS for added security.

There exist other PAKE schemes in addition to SRP. We chose SRP because it has been battle-tested, is well known, has many existing implementations, has thorough documentation about pitfalls to avoid, and no patent issues. A promising alternative scheme in the future may be AugPAKE, which benefits from the existence of a security proof. We should be able to seamlessly switch to AugPAKE in the future if necessary.

We have described additional details of our implementation in a somewhat outdated internal note, which is excerpted here. Source code can also be viewed here.


One-password mode is the culmination of many months of behind-the-scenes work to make ProtonMail more secure and easy-to-use than ever. While we will always support two-password mode, one-password mode will be the default for the future and we recommend that existing users consider switching for increased ease-of-use. A step-by-step guide for switching can be found here.

At ProtonMail, we appreciate more deeply than most that security is a rapidly moving target. Threats are constantly evolving, and every month, we see more and more complex attacks launched against ProtonMail. Because of this, we invest a considerable amount of resources on research and development to stay ahead of current and future threats. Most of this work happens behind the scenes, and is not as visible as new features or UI improvements, but nevertheless, they are a critical part of creating a solid secure email service.

If you would like to support these efforts, upgrading to a paid ProtonMail account or donating is a great way to do so. On the security side, our work is never done, so in the coming months, we will be releasing additional security features to make ProtonMail even more secure.

Best Regards,
The ProtonMail Team

2016-12-04: Some minor corrections and clarifications.

You can get a free secure email account from ProtonMail here.

ProtonMail is supported by community contributions. We don’t serve ads or abuse your privacy. You can support our mission by upgrading to a paid plan or donating.

About the Author

Bart Butler

Bart is the CTO of Proton Technologies AG and expert in email encryption. Previously, Bart was a physicist at CERN working on the ATLAS experiment. He was also a postdoctoral researcher at Harvard and received his PhD in Physics from Stanford University.


Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

53 comments on “Improved Authentication for Email Encryption and Security

  • Hi,
    As user , i support your work & improvement but restrictive laws & new attacks (hopefully analyzed/found/patched) let me a bit scared.
    I will switch on this new feature soon and will follow your innovations with a great pleasure even if i do not understand all the steps of your demonstration.
    Thx for this interesting article.

  • Hello.

    I like the idea of the increased ease of logging in with only one password – especially for the technically minded person this is a much easier method, and much more likely to encourage people who may not use password managers etc.

    However, one thing I did not pick up from the article – besides the ease of logging in with only one password, is one-password mode inherently more or less secure than two-password (even if only by a fraction of a percent)? Or is it completely equal?

    For those of us who have their password manager set up to handle two-password mode without any real difficulty, is there an advantage to switching to one-password mode? If so, what?


    • Two password could be slightly more secure because it has higher entropy, but from a practical standpoint, it is not a significant security benefit.

      • Thank you for replying.

        If I could just ask one more question – perhaps it is answered in the text but I am still unsure on it.

        Previously, one other advantage of two-password was that the mailbox password was not something you could be compelled to give away (if I understood correctly!) – so if, for example, the government demanded that you grant access to such and such account, you could clearly tell them it is impossible.

        Is this still the case under one-password, and if so how? Apologies if this is already answered in the text, would just like some clarification. Especially in the light of the Snoopers Charter… 🙂

  • hello,

    a – do i am protected against e-mail tracker software or/and these pixels hidden in the message (i answer & post like every body on some forum/blog/mailing-list) ?
    b – do i am protected against geo tracker (anti-thief software_some intel chipset have implemented this feature) ?

    1. Are a & b relevant concerning on protonmail ?
    2. Am i vulnerable even using protonmail ?
    3. Should it be one password -the new feature- or two password -the old feature- which be the better counter-measure ?
    4. Does it exist a rule(firewall) , a filter(spam) , a patch which should disconnect these trackers ?
    5. If i could fill up my email-page with a color , should i see the pixel hidden or instructions/code written in white ?
    6. Is it true that none tracks cannot be retrieve from the protonmail box ?

    Thank you very much for your improvement & works.

  • is not in https and reading the doc in wikipedia dated on 13 October 2016, i notice that the with openssl but i read that libressl should be better – anyway i am not a specialist just an user lambda.
    i am happy that a mitm will fail using one password.

  • Hi,

    I am still waiting to give you money, but I will only do so if there is IMAP/GPG support. I follow protonmail development for a year now, and back then the top-10 issues would all have been solved by giving us IMAP and support real GPG, like you promised for version 1.16…. I really do not understand why you spent so much energy on things that were not requested, while delaying the one which was issue number one for the entire last year. You seem to need money. Switching to one instead of two passwords will not make people give you money.

    Being able to
    a) send people outside of protonmail encrypted emails
    b) being able to use self-generated keys, where we control both private and public key
    c) being able to create a backup (e.g.using local mailclients)
    will make people give you money.
    Because why should I pay for a “encrypted email service” that does not give me those three things that I can do with *ANY* other email-provider, but not protonmail? Seriously, could you please give us something like “IMAP is on place number X on our priority list, and only Y and Z have higher priority because of [reason]”? Because if there is one more release with something unrequested but no progress report on IMAP/GPG I will stop waiting and go for one of the alternatives.

    • We do a user survey every year, and the priority is based off of that, and also the votes on uservoice. 2FA came first because simply more people requested it. If we had more resources, we would be able to develop faster. If you would like to support faster ProtonMail development, upgrading to a paid plan is the best way to do it. Without more resources, we obviously cannot do everything at once, as our ability to develop is limited by the number of staff we can hire.

  • Hi,with this new feature can i use Mozilla thunderbird? Couse i still have problem to set up account. Thanks for constantly trying to enhance user experience.

  • This sounds cool. But,

    (1) Where is the code? can you give a github link to specific files that implement SRP on a client and on a server.

    (2) Statement in post: “”” Even if ProtonMail is compromised and acts maliciously, password equivalent information is never revealed. “”” — sounded as if leak of a database with SRP verifiers and associated salts cannot allow for an offline attack against passwords.
    Given such data, offline calculation is simply split into two parts. In part one, we guess password, for which SRP verifier, v = g ^ saltedP, can be found. Once such password guess is found, an attacker performs calculation of SRP exchange for different s and c, random values. If calculation run fails for at least one pair of (s,c), new guess should be found. If calculation run ok for, say 10 (s,c) random pairs, there is a heavy chance that password is found.
    Most of guesses will die in the first phase. Thus, bulk of work will be comparable, in the same order, as work needed for brute-forcing bcrypt-ed passwords.
    In this context of server compromise, when verifiers and salts are stolen, SRP verifier is a password equivalent.
    I’d hope you can prove me wrong.

    • 1) You can look at the code for the web client here:
      2) That quote specifically is referring to actions taken by the server during a login sequence. A database leak of SRP verifiers and associated salts absolutely does allow for offline password attack, as it would for virtually any authentication system, but, as you note, this would be a slow brute-force attack, probably comparable to brute-forcing bcrypted passwords. Your final statement, however, is incorrect. If you have to dictionary-attack something, it’s not a password equivalent. By your logic, bcrypt password hashes would be password equivalents as well. Password equivalents can be used directly or with minimal computation to authenticate to the server–neither SRP verifiers nor standard password hashes can be used in that way without being brute-forced first, which takes considerable time/resources.

      • Ya, SRP verifier is password’s computational equivalent, which requires a bcrypt computation, currently in your case.
        But, with advent of graphic cards, even bcrypt starts to look less strong. Memory intense algorithms, like scrypt better be used these days. (On a side, there was a paper saying that scrypt is maximally memory hard, so no need to wait for another one).

        We still have to rely on hardness/length of pass->hash computation. And, since we do not send password to server, computation must be done on the client. But, when cryptographers write implementations for “password-stretching”, or whatever academic name this has, they never add a user-friendly callback to signal percentage of task done.

        My guess is, that you do bcrypt only somewhere at the start of the session, and only in relation with password entering UI. It is this point that will benefit greatly from a simple progress bar running. Start using harder scrypt, which objectively takes longer, but with a progress bar it may feel better. In fact, subjectively, the longer bar goes, the stronger the security feels. To make it happen, you need a bcrypt implementation with a progress callback.

        We have a blind rewrite of script in js (ts, actually) as part of 3nsoft/ecma-nacl on github. You can see how progress callback is added. It doesn’t require touching any crypto. Just do a call at certain estimated points. Do calculation in a web worker, with callback sending a message to UI.
        May be you can add callback to bcrypt’s implementation, or even move to using scrypt. Give it a thought. We are playing with this scrypt, written in js, using old arm and intel tablets, and the result is high security for password, available even in the worst places. And it is possible solely due to a visual feedback to user, thanks to a simple progress callback.

        I thought, I’ll share this with you.

        • Thanks Mikalai,

          We are definitely interested in using scrypt eventually, especially now that the password hashing is completely client-side and thus we do not have to worry aboout killing our servers. Performance has held us back though…as you say, it does take longer. We will think about it.

          • The name of the game becomes “subjective perception of performance”, versus “objective performance”.
            Display an actual progress bar (not a fake timer!), try it on users, and ask, if initial 10 seconds worth security. When a person knows why she has to wait, then it’s ok.
            Those 10 seconds can be on an android tablet, while desktop browser will be done in 1-2 secs. And it is a use of 128MB per computation — a luxury servers do not have 🙂

            BTW section.
            Code in our repo may be improved by using 32-bit (4-byte) lookups instead of original C-ish 8-bit (1-byte) at a time. Repo dchest/scrypt-async-js on github has this improvement (was dchest an author of this trick?). It misses on other fronts, though.

  • Thanks for all of the work.
    Waiting for search able to search through message bodies before switching completely and subscribing (difficult to accomplish, I’m sure, but we believe in you!)

  • Dear Protonmail team,

    Thank you for 2FA. It’s was a much-needed feature.

    Quite a few people requested Yubikey support, both before and after the recent 2FA release.
    Could you please comment on whether this is something you’re planning to implement?


  • Hi ProtonMail Team,

    thanks for this update!

    One more question. Could you recommend us (users) some Swiss VPN services (companies) with your approach?

    Kind regards from Prague!

  • Hi there. I am new to protonmail and looking forward to enjoy this service for many years to come. Any plans on having a confirmation email once your sent email has been read without encryption ?

  • Are you planning to open-source the serverside package? I assume it’s in Go? There are some SRP Go packages out there but I doubt they are compatible with your SRP implementation in WebClient since you made improvements to RFC 5054.

    • Yes, we might do this later as a separate project when the code is more stable. Currently, we’re still tweaking a bit and making improvements.

      • I hate to ask this but: is there a timeline on this? I would very much like to you the improvements you made. The JS is already open-sourced of course; but without back-end it is kind off useless. Duplicating your work will be inefficient and unlikely to yield a package that is as good as you’ve built.

        • We can look into open sourcing just the SRP part, we will put this onto the to do list, but it unfortunately won’t gain highest priority and could take some time.

  • salve vorrei sapere quando sara possibile di usare protonmail in lingua italiana visto che ora la lingua italiano e suportata solo nella prima pagina poi se vai nei impostazioni e bisogna usare il tradutore .grazie..

    • intendevo quando sara possibili avere configurato la lingua italiana anche per le sezioni interne del mail ci sono tantisime persone che vorrebero che sia suportata la lingua italiana .grazie.

  • When you say “Even if ProtonMail is compromised and acts maliciously, password equivalent information is never revealed”, what kind of attack are you referring to?

    If ProtonMail “acts maliciously” (possibly because ordered to do so), then it could collect the login password by sending a modified login page to the users.

    Is there any way to check that, from the user point of view? Any extension that can tell you “this page has changed since the last time you have visited it” or something like that?

  • Hi there

    It seems you lot at Proton are doing a very good cause project. I take my hat off to you!

    Excuse my lack of understanding but my question to you is:

    If I were to send an email massage to a gmail users email address who reads it direct from their inbox (therefore not sending a link to your servers) and it is set to delete after opening it say in 30 seconds. Would that message still be recorded and held by google on their servers and could be handed over to the authorities if requested to do so?
    if that is the case then it defeats the purpose of using protonmail to normal clients who are unlikely to want the same level of privacy.

    Can you please confirm the position.


  • Hello ProtonMail!
    I have a few questions regarding your modified version of SRP 6a.

    1. What is the advantage of using “semi-random password salts (one random part, one non-random part)” compared to fully random salt? How many bits of salt are random, how many bits are non-random? What does the non-random part consist of?

    2. What is the advantage of not allowing users to download their private key, when emails can be exported only in encrypted form?

    Thank you!

    • The advantage is that in the event another service’s password database is compromised, and the user used the same password on ProtonMail and this compromised third-party service (don’t do this!), and that service uses the same hash algorithm we do, the attacker would not be able to impersonate the ProtonMail server in the SRP auth sequence, because ProtonMail clients know that the salt begins with a non-random sequence and check this, whereas the salt stolen from 3rd party service would not.