Generate a random 256-bit salt, and compute H = HMAC-SHA256(salt, password). Then compute K = 2^H mod P where P is the Diffie-Hellman group #14 modulus 2^2048 - 2^1984 + 2^64 * floor(2^1918 pi + 124476) - 1, and store (H, K).
At least, that's how I do it. A nice, expensive computation -- not only expensive in software, but also expensive for custom silicon, since 2048 bit modular exponentiation needs a lot of gates -- and as an added benefit you can do password verification using DH and thereby separate the password from its verifier.
EDIT: Ok, that's not quite how I do it. I actually compute K = 2^(2^258 + H) mod P, because I can do that using two exponentiations with blind exponents. But that's just me being paranoid about side channel attacks.
So, in other words, you do SRP, but you don't want to call it that.
Suggesting that people invent new cryptographic protocols to solve the password storage problem, which has been solved adequately tens of times over now --- whether or not the person you're addressing knows the difference between MD5 and SHA1 --- is just about the worst conceivable advice you could give.
At least, that's how I do it. A nice, expensive computation -- not only expensive in software, but also expensive for custom silicon, since 2048 bit modular exponentiation needs a lot of gates -- and as an added benefit you can do password verification using DH and thereby separate the password from its verifier.
EDIT: Ok, that's not quite how I do it. I actually compute K = 2^(2^258 + H) mod P, because I can do that using two exponentiations with blind exponents. But that's just me being paranoid about side channel attacks.