Theoretical home grown password options, or what is it that SCrypt, BCrypt, PBKDF2 does that is so special?

Question

I'm developing a personal web framework, nothing internetty, and probably not even anything that will ever go on my personal LAN. And looking for password advice people seem to only recommend those libraries in the title. I'm doing this to learn security from a development perspective, and again, I'm aware this isn't best practice I want to learn by implementing it myself (and hassling the community with relentless questions).

Currently my routine does 4096 rounds of salted SHA512 (a number plucked out of thin air - I'll concede thats one thing they probably have sorted) like so:

string randomdatabasesalt = "whateverdatabasesalt"  
user = "username"
string password = "whateverpassword"  
for (int i = 0; i < 4096; i++)  
{  
  password = SHA512(user + randomdatabasesalt + password);  
}   
store (user, password);  

Now if I feel the need at a later date I can add more rounds to everyones hash (pre-breach of course) and can strengthen it without anyone needing to reset passwords, all reasonably easily. Or if SHA2 becomes completely broken with regards to cracking speed, I can rehash those hashes and add it into the routine with noone being any the wiser though that may be an undesirable waste of cycles. So whats wrong with this approach - other than the random rather than computed selection of rounds? Is it just the lack of peer review or do the aforementioned libraries do something I'm not taking into account?

Secondary question, would adding the salts each pass somehow weaken the hashing? Is it better to salt just the initial hash then loop through? Example:

string password = "whateverpassword" 
password = SHA512(user + randomdatabasesalt + password); 
for (int i = 0; i < 4095; i++)  
{  
    password = SHA512(password);
}   
store (user, password);  

Answer 1

Well, it is a mixture of "no peer review" and "something you do bad". The thing you are (apparently) doing poorly is your salt selection: you call it "randomdatabasesalt", which hints at the idea that you would use the same salt value for several hashes, if you had to store several password hashes (e.g. because your framework has several users). This is a sin: it voids most of the reason why you would use a salt in the first place. Salts should be per-instance: each user should have his own salt, and the salt must be changed when the user changes his password.

As for the rest: anybody can create a cryptographic scheme that he cannot break. The hard part is to create a scheme that nobody else can break it either. The really hard part is to make sure that nobody else can break it (because we want security, but we also want to sleep at night).

Cryptographers thus rely on peer review and slow-paced development. When they want to design a new function, they organize a competition in which people are encouraged to submit candidates, complete with specification, test vectors and reference implementations; and then they spend some time (years) to try to break each other's creations. Survivors are then deemed "probably secure". This is what was done for AES and SHA-3, for instance. And, right on cue, there is an ongoing competition for password hashing functions.

This presentation is a nice introduction on password hashing, and lists some features that good password hashing functions should have. Have also a look at that answer.

(One way of designing cryptosystems which does NOT work is a fast comment-modify cycle. It usually happens as a dialogue between a wannabe designer, and an amicable and knowledgeable cryptographer. The designer, full of zeal, will submit an endless stream of minor variants of his scheme, each adding some random construct to answer to the last comment from the cryptographer. This always ends up with the cryptographer being fed up and ceasing to respond; the designer then claims victory and writes a colourful Web page, and then fails to become rich overnight when the rest of the World does not acknowledge the genius of the new algorithm.)