I want to set up the following:
An untrusted server should host user sessions and authenticate users without knowing their passwords or being capable of creating a fake user session in the user's name.
This is accomplished by making all sessions publicly verifiable by making public the information necessary to prove that the client was able to demonstrate their knowledge of a secret.
The secret the client holds is of password-level entropy.
Now, a few things come to mind here. For starters, either SRP or hash chain authentication could be used for this purpose, and would actually work pretty well if the secret was of key-level entropy.
Secondly, a password can be pushed towards key-level entropy by using key derivation.
So my question is this: Is it reckless to use a key derivation algorithm to create a secure password to use with an auth scheme like SRP or hash-chaining in which the untrusted server and the general public will know the resulting verifier or "public" key? Or are KDFs only suited for providing some hope that not all passwords are goners for when a trusted server is broken into by an attacker?
I know PBKDF2 is essentially "useless" against anyone with a GPU rig and I have read that bcrypt is "useless" to anyone with an FPGA setup. Scrypt, the final alternative people discuss is "young" and at the end of it, it seems intuitively like it's very hard to pretend low-entropy can ever truly become high-entropy, except by simply making it a bit harder for attackers of today.
So, is there any solution to this set up or is this ultimately a case where a user must have some key-like password? If so, would this be a good use case for assigned passwords that are actually keys translated through word lists? For example, if you enforce a Diceware password scheme of 10 words, you end up with what the author claims is 12.9 * 10 bits of entropy, or 129 bits of entropy which seems pretty good for being forced into remembering 10 words.
Let's also assume the users are somewhat onboard because they are motivated by the product itself but they also shouldn't have to put up with too much. They aren't lay-users being forced into a system more complicated then they are used to but they also shouldn't have a terrible experience with logins.