I get that this is a bad idea that won't work, blah blah security by obscurity and so on. But when I was asked why it doesn't work, I was unable to give a very satisfying answer.
I mean, there is a certain logic to what you're suggesting. Let's say you're cpervica and you know what you're doing. You make mistakes like any human being, but you know crypto. So, some cracker gets access to your database. OK, they're probably not smart enough to find a weakness in what you've done and might not even be able to figure it out. But there might be a weakness there.
Plus, you have to think: what if someone gets my code and my database? Then they have the modification you made. If the modification doesn't require more computation, then it's just unknown without the source code. So, with the source code, we're back to the trivial to cracking case.
The thing is: there are solutions out there to handle this by making the calculations take longer. PBKDF2, bcrypt, and scrypt all exist. They deal with this specific problem in a way that even if someone gets your hashes, salts, and code, you're less vulnerable.
tl;dr: with the obscure case, you're not gaining protection if they get your code along with your database.
Edit: See udk1 below -- he's right, sha1 is an outdated algorithm for this purpose. Poor example choice on my part.
I've heard it referred to as a pepper (to go along with salt) and is in the application code.
bcrypt(password, salt, pepper) => hash. So even if they grab the db with the salt, the effective password to crack turns into 'password3jkl453jklgfuja9oph4mn" instead of just 'password'. Impossible.
And if they do get your site's code, you're back to a strong hashing algo and a salt.
Most people should use bcrypt with enough rounds to make it difficult to brute force. scrypt is also an option, though newer (good / bad: http://security.stackexchange.com/questions/26245/is-bcrypt-...).
That's the "theoretical" answer. The real answer is, popping someone's database virtually always --- you know what, let's just assume always for now --- gives you a remote shell, and from the the actual code.
The point you and others make that if the database is compromised then the code almost certainly is too, is clearly the best answer though. I am now prepared for the next time I encounter my interlocutor at extended family dinners!
Cryptographically, you can address the problem you've set out for yourself simply by hashing a 128 bit random number along with the password, and keeping that number a secret. If attackers can get your code, it doesn't matter how you obscure your hash, because they'll have the algorithm. But through trial and error, an attacker might figure out how you tweaked an algorithm; all the atoms in the solar system (or something like that, I can never remember) could be computers trialing and erroring against a 128 bit random number and they'd never figure it out.
2^128 = 3.4028E38
solar mass = 1.9884E30 kg or about 9E56 atoms.
256 bits is the one where the hosting costs start getting not merely planetary but intergalactic.
2^256 = 1.1579E77
atoms in Milky Way = 2.9E76 atomsThis secure stuff is hard. Remember when debian made a "simple fix" to open ssh and made all the ssh keys for 2 years brute forcible? Do you think you can do better? It's wiser to leave this to the experts
This could have (and often does) happen to any software. It's not a good example of someone attempting to design their own or modify an existing crypto primitive algorithm.
It's called "salting" the password. Everyone does it. It works really well.
Of course, if they can steal your salt (from your source, or a config file) then you lose.
Since salts are random, and unique per password, you shouldn't be storing them in a config file.
The long answer is that security experts are expensive and trying to figure out security systems from first principles is very hard and fraught with disaster. The result is that almost all security practices are transmitted via folklore.
Also, the documentation for security software is often dense and hard to understand, while the documentation for non-security software provides advice that is simple, actionable, and terrible: http://dev.mysql.com/doc/refman/5.7/en/encryption-functions....
* The undocumented-algorithm PASSWORD() function that mysql uses to hash passwords apparently defaults to unsalted double-SHA1
* You are helpfully advised not to use this function to store user passwords, instead you're advised to use MD5 or SHA2.
* Salting is not discussed at all.
* Key stretching functions are not provided or discussed.
Many tutorials and reference documents use MD5 and SHA1 in their coding examples, so right from the get-go novice developers are at an automatic disadvantage.
An attacker could simply put together a dictionary of 10,000 common passwords then hash them against each user's salt value and see they they get a match for that user's password Hash. Assuming Hashes are stores as SHA-256, with a GPU hashing setup they'll be able to scan through 50 million users in very little time at all.