Just use a hardcoded application salt (significantly large, >128 bytes is more than enough) in addition to your per-user salt (stored in the DB, or derived from a DB field). That way, an attacker would need both code access and DB access to crack the hashes, and if that happens you're basically screwed beyond redemption anyway.
We really want to go the extra mile with Authic (it's going to be main selling point of outsourcing your webapps authentication with us), so we'll consider adding as many different aspects as possible.
And yes, you do have big problems if someone has access to your db AND code, but if you have done your job properly at least it will be very difficult/expensive/time consuming for the attackers to crack your hashes.
In the worst case scenario of someone dumping your entire database, you want there to be as much time as possible to contact your user base to let them know of the breach so that they can update their passwords before the crackers have finished the job.
