PAKE - What to do when a weakness is found?



  • In the case of a password hashing function like Argon2, I know that when a weakness is found, you use another password hashing function, wrap it around the existing hashes and calculate the hash of the password directly when the user logs in again.

    What happens when a password-authenticated key exchange (PAKE) protocol, like SRP, is shown to have a weakness? Can you wrap it inside another protocol until the user logs in, or do you have to store the verifier data that may be subject to being cracked in case of a data leak?

    I am concerned for the case where the password can either be calculated from the verifier or guessed in a reachable upper limit of guesses when knowing the verifier. The issue is that, in case of a data leak, all passwords are stored in a way that it is realistic for someone to crack the passwords. (Compare it with the case that someone is using MD5 for password hashing)



  • That depends on your architecture, what you have in place, and the kind of weakness. I'm afraid your question is too broad to answer meaningfully.

    For example, if the PAKE algorithm is subject to a MITM attack, using it inside TLS will most likely defeat the attack. And maybe TLS is already in place and just updating the PAKE protocol software would suffice.

    If the clients are operated by humans, you could also deactivate this protocol, put in place a new one, and use the access recovery mechanism (AKA "I forgot my password").

    Most likely, the PAKE provider will issue a statement on how to remediate the specific issue.

    What you can do in advance to plan for the unknown, is to have a second, maybe less convenient, way to authenticate. Also, using a second authentication factor can help mitigate a vulnerability in the PAKE protocol and ensure you have enough time to plan how to properly remediate your issue. If such an event occurs, you could then ask the same question here, but with specific details.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2