[njohnson41]

> ... all possible combinations of 8-16 characters with 100 character possibilities ...

Yes, but this doesn't even come close to describing the typical users' password, which is most likely a 6-letter English word with a capital letter and a 1! appended to the end. Your calculation here isn't really relevant, because it's all about the worst or common case. (You also assume that people are using a GPU for a compute-bound problem, when much faster FPGAs are also available, but either way it's moot.)

Security through obscurity, which is what you're proposing with the shuffled salt idea, is also not normally considered the right way to go. If you wanted to use a similar but much simpler and straightforward method, you could just encrypt the salted hashes before storing them in the database.

[brokenwren]

Simple passwords are mitigated by salting and slat modification. The guide covers both of these and hashing. This should be sufficient even against thousands of GPUs.

[aj-code]

In short, it's not. A robust scheme should be secure if the attacker knows the algorithm or not. The secret should not be the algorithm, the secret should be a sufficiently long secret value.