If the hash is stored with an account, then an attacker attacks each account by performing the hash on each potential password (dictonary, exhaustive search, et

If the hash is stored with an account, then an attacker attacks each account by performing the hash on each potential password (dictonary, exhaustive search, etc) and checking to see if it is equal to the stored one. If the hash is stored independently in another table as you suggest, then an attacker attacks each account by performing the hash on each potential password and checking to see if it is in the set. If that set is small enough to fit in memory (and they could likely store billions) then a simple contains check doesn't buy you very much. It is simpler to raise the work factor of the hash. If someone is using dedicated hardware it may make it a bit trickier to implement, but it also makes things trickier for you to manage. Better to use a hash designed to thwart such an attacker (like scrypt) up front.