The short answer is that when it comes to security, and especially when it comes to cryptography, don't roll your own. Use vetted schemes that meet the approval of the security community in general. Your home-grown method is practically guaranteed to have flaws that you haven't thought of.

For a longer answer, read Thomas Pornin's excellent treatise on how to securely hash passwords. Most of what I'll write here is contained in that answer.

For password hashing, there are three generally-approved hashing functions: PBKDF2, bcrypt and scrypt. I won't compare them in this answer; none of these is a wrong choice. Several threads on Security Stack Exchange compare them, in particular Do any security experts recommend bcrypt for password storage? and Are there more modern password hashing methods than bcrypt and scrypt?.

Now, getting to the technical answer to your question, there are two things wrong with using e.g. SHA-256(username + password) as the password hash. The first thing is that user names are not unique. This has several implications:

• In particular, this makes it obvious when a user has picked the same password on different sites, which can help for some targeted attacks.
• Using a weak, predictable “salt” also facilitates non-targeted attacks that focus on the most common user names, e.g. a rainbow table with the 1000 most common user names and the 1,000,000 most common passwords has the same size as a rainbow table with the 1,000,000,000 most common passwords for unsalted hashes, and still catches quite a few weak passwords. A truly unique salt makes precomputed table useless.

The salt technically doesn't have to be random, but it needs to be unique, and using a random string is the easiest way of meeting this requirement.

For more details about salts, see Why are salted hashes more secure? and Convincing my manager to use salts. A pepper may optionally be combined with the salt — it's a good defense against some common attacks (database dump by SQL injection).

A second problem with your approach is that something like SHA-2(salt+password) is not good either. A hash function must be slow — legitimate servers only compute one authentication value, whereas attackers must make a lot of failed attempts, so slowness penalizes the attacker more. General-purpose hash functions like SHA-1 and SHA-2 are designed to be fast, they are no good for password hashing. You can turn them into a good password hash function by repeating them many times — but don't roll your own, because the devil is in the details: PBKDF2 is based on this principle.

The short answer is that when it comes to security, and especially when it comes to cryptography, don't roll your own. Use vetted schemes that meet the approval of the security community in general. Your home-grown method is practically guaranteed to have flaws that you haven't thought of.

For a longer answer, read Thomas Pornin's excellent treatise on how to securely hash passwords. Most of what I'll write here is contained in that answer.

For password hashing, there are three generally-approved hashing functions: PBKDF2, bcrypt and scrypt. I won't compare them in this answer; none of these is a wrong choice. Several threads on Security Stack Exchange compare them, in particular Do any security experts recommend bcrypt for password storage? and Are there more modern password hashing methods than bcrypt and scrypt?.

Now, getting to the technical answer to your question, there are two things wrong with using e.g. SHA-256(username + password) as the password hash. The first thing is that user names are not unique. This has several implications:

• In particular, this makes it obvious when a user has picked the same password on different sites, which can help for some targeted attacks.
• Using a weak, predictable “salt” also facilitates non-targeted attacks that focus on the most common user names, e.g. a rainbow table with the 1000 most common user names and the 1,000,000 most common passwords has the same size as a rainbow table with the 1,000,000,000 most common passwords for unsalted hashes, and still catches quite a few weak passwords. A truly unique salt makes precomputed table useless.

The salt technically doesn't have to be random, but it needs to be unique, and using a random string is the easiest way of meeting this requirement.

For more details about salts, see Why are salted hashes more secure? and Convincing my manager to use salts. A pepper may optionally be combined with the salt — it's a good defense against some common attacks (database dump by SQL injection).

A second problem with your approach is that something like SHA-2(salt+password) is not good either. A hash function must be slow — legitimate servers only compute one authentication value, whereas attackers must make a lot of failed attempts, so slowness penalizes the attacker more. General-purpose hash functions like SHA-1 and SHA-2 are designed to be fast, they are no good for password hashing. You can turn them into a good password hash function by repeating them many times — but don't roll your own, because the devil is in the details: PBKDF2 is based on this principle.