The problem with challenge/response and nonces is that the server and the client both need to have access to something secret to encrypt the nonce with. This usually means storing the plain text password on the server or at least a hash of it which then would be used to encrypt the nonce.
But this also means that when your user database gets lost, all accounts are instantly compromised without the attacker having to do any kind of brute-forcing.
Unless you notice an intrusion immediately, the damage that can be done in such a configuration is way bigger than if the server gets the secret thing from the client and does the hashing there, because now an attacker has to individually brute-force the various accounts (keeping at least those who chose a strong password safe).
Even if perfect forward secrecy was not doable, I assume it's far less likely for an attacker to brute force my SSL private key than it is for them to acquire my user database - not that I want that to happen of course.
That's a good point. On the other hand, with the ECDHE / PFS scheme, aren't you still at risk for an implementation specific bug like the Debian incident? (I.e. the server or client only ever picks the a/b factors from a very limited range?)
Anyways, your suggestion sounds much better than my initial nonce suggestion. :)
The problem with challenge/response and nonces is that the server and the client both need to have access to something secret to encrypt the nonce with. This usually means storing the plain text password on the server or at least a hash of it which then would be used to encrypt the nonce.
But this also means that when your user database gets lost, all accounts are instantly compromised without the attacker having to do any kind of brute-forcing.
Unless you notice an intrusion immediately, the damage that can be done in such a configuration is way bigger than if the server gets the secret thing from the client and does the hashing there, because now an attacker has to individually brute-force the various accounts (keeping at least those who chose a strong password safe).
Even if perfect forward secrecy was not doable, I assume it's far less likely for an attacker to brute force my SSL private key than it is for them to acquire my user database - not that I want that to happen of course.