Just an idea I had, and I am sure there is a lot of material about this subject, so I am looking for a pointer as to where I can find more information.
My idea is this...
When storing a password in a database, it is common to store it as a hash. This is weak against rainbow tables, which is mitigated by adding salt, and is also weak against brute force attacks.
I am thinking that it is possible to store the hash, modified with a small random string...
mypass -> 2b643a4d56186389d84dbb3a9a483e99
If you have the hash, the password can be found by simply hashing all possible passwords, and comparing the hash, so...
// append a random 3 character string of a-z characters, we can use "xth" for this example mypassxth -> 02a2247c788681af6ce1bb5fa66dd4c0
The random string is never stored, never shared, and only resides in memory on the server at the time of storing the hash.
This makes lookup of passwords less efficient, because the server must check any incoming requests by brute forcing the partly complete input against the stored hash, which in this case would mean an upper bound of 17576 (26^3) checks to validate the password.
It would also make brute force attack much harder in this case, an upper bound (assuming a-z only) of 5429503678976 (26^9) rather than 308915776 (26^6).
I guess it is like using a very small salt, that is not stored anywhere, requiring brute forcing during lookup operations.
Assuming I am not completely missing something obvious that makes this not work, can someone tell me what this concept is called, or point me somewhere where I can read about it?