1

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)

1

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.

2
  • Thank you very much, 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)
    – Gamer2015
    Jun 17 '21 at 19:45
  • @Gamer2015 That's another issue, unrelated with PAKE. You should enforce a minimal strength for password (at the very least 12 characters) and if you think it is still too risky, enforce 2FA. Other more complex methods are also possible, but that would be the subject for another Q&A. For your concerns about leaks exploitation, verify the configuration of your PAKE implementation: it should use strong salts.
    – A. Hersean
    Jun 18 '21 at 8:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.