A proper cryptographic implementation does not rely on obscurity. It should still hold up even when the methods of hashing and/or encryption are known, so long as the key (e.g.: password) is still protected.
As others have pointed out, you should not be using a static salt for your password database. This would quite nearly defeat the purpose of a salt, by enabling an attacker to pre-compute a rainbow table that will be useful against a large number of passwords.
Instead, each password should have a unique salt which is randomly generated when the account is created. The method for generating the salts, and for hashing the passwords, may be public. The salts and password hashes should be kept in a secured database.
This is not a panacea, however. You still must take appropriate measures to protect the confidentiality of the password database. Of course, if your site is vulnerable to SQL injection, the password database could be taken. And then, of course, it's only a matter of time before all passwords are cracked regardless of the salting or hashing mechanism.
The per-user, unique salt doesn't entirely prevent the password from being compromised. It only delays it by adding another element to the process which an attacker will not have foreknowledge of. Compare the following scenarios:
- Unsalted hash: The attacker could already have a pre-computed rainbow table for your hashing mechanism, and may have all passwords cracked within the same day of retrieving the database.
- Static salt (public or private): Once the static salt is known (either via inclusion in open source code, or system compromise), the attacker only needs to generate one rainbow table in order to break any password in your database. I'm not much familiar with how these things go, but it seems like it might be something worth waiting for if the target password database is fairly large or protects something of real value.
- Unique salt, securely stored: No amount of pre-computation can be expected to work effectively against this, unless the attacker has an inconceivably large database containing rainbow tables for all possible salts. Absent that, the attacker will have to brute-force each password individually. Given a proper cryptographic implementation, this will likely take more time than the attacker, or any of his foreseeable descendants, can afford.
There's a lot of good guidance in the answers and comments here. I strongly suggest you look into it. Also, remember Rule #1 of Cryptography: Don't roll your own crypto.