3
$\begingroup$

I was reading the AugPAKE rfc and noticed that there is no mention of key stretching anywhere. The protocol does mention use of a hash function, and the hash function that is provided as an example is SHA2.

It appears the protocol does not utilize computationally expensive key stretching anywhere. I would like to ask how the protocol can remain secure with regards to low entropy passwords. What prevents an attacker from brute forcing the weakest link in the chain?

It seems like there must be some form of rate limiting in order to slow down the search through such a limited set of possibilities. The only mention of this I saw was the standard recommendation of only allowing X incorrect password attempts per unit time.

Could it improve security to use a key stretching algorithm such as pbkdf2/bcrypt/scrypt/argon2 on the password, or would that defeat the purpose/efficiency of the protocol?

$\endgroup$
  • 1
    $\begingroup$ I haven't read it, but assuming things are like with SRP, you get to do exactly one password guess per connection, at which point simple rate limiting does the job. The only problem with not using a proper PBKDF here is that if your database gets breached and the password verifiers leak, you're basically back to (unsalted?) SHA-256 hashes (more or less). But my guess is that the low-power / high-speed crowd won the discussion in the WG and thus we don't have a proper PBKDF here and the database breach was excluded from the threat model. $\endgroup$ – SEJPM Aug 31 '16 at 22:08
3
$\begingroup$

It seems like there must be some form of rate limiting in order to slow down the search through such a limited set of possibilities.

There is. Due to the nature of AugPAKE an attacker can only try a single password per connection attempt with the server, meaning offline attacks against the handshake transcript are not possible. Thus if the connection-rate is limited, the search speed is limited accordingly as well, protecting even weak passwords, if something like 10 attempts per second and further penalties for bursts are implemented.

The fact that you can't guess anything from a passive view of the transcript is documented (and proven) in section 3.2.
Section 3.3 in turn talks about what active attacks can do and argues that even an active attacker can do no better than an on-line dictionary attack, which means one password attempt per connection.

Could it improve security to use a key stretching algorithm such as pbkdf2/bcrypt/scrypt/argon2 on the password, or would that defeat the purpose/efficiency of the protocol?

It would certainly improve the security of the protocol to use a strong password-based key derivation function (PBKDF) in so far as it hardens the server's password database in the sense that a leak of the database isn't directly equal to "many, easy-to-break real-life password hashes". However this would also impose high loads on the clients of such a connection, which may be unfavourable, especially as there's no one-size-fits-all for password hashing given how different desktop computers and smartphones are, where the former needs maybe 100ms for something the latter needs 3s. This is very likely the reason why there's no such strong PBKDF in place here, as the designers decided that speed is more important than "security in case of database leaks".

This is also part of the security discussion of the document (section 3.5) which says that a protocol is secure against server compromise as long an attacker can do no better than running off-line dictionary attacks on the database.

What prevents an attacker from brute forcing the weakest link in the chain?

The weakest link in the chain is the password database (which is secured using standard access control) or by the nature of the protocol, making guesses really slow and controllable.

| improve this answer | |
$\endgroup$

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.