Centralizing your logins with inherent lack of local fallback isn't necessarily a good thing. If you're trying to mitigate your password DB being stolen, inser

Centralizing your logins with inherent lack of local fallback isn't necessarily a good thing. If you're trying to mitigate your password DB being stolen, insert canary accounts and have a passive device on the network scream bloody murder when it detects anything logging into one of the canary accounts. Another approach is just to have the random data be local. (Have a large chunk of random data. The hash is a couple iterations of a standard password hash, but each time used as an index into the random data. You want multiple iterations as otherwise someone walking off with a relatively small section of the data can still crack many passwords.) If you're preventing brute-force, there are better methods. For example, having the client submit a proof-of-work. (As a bonus to this, you can adjust the proof of work if you're under (D)DOS.)