User ID hashing?
Pass Username through uuid (RFC 4122) to get hashed Username (this is mostly to generate a fixed length string so that the DB can index it tidily)
Select uuid from database to get ID.
This is pointless -- databases can index variable-length strings just fine. In fact, they'll do it better than a UUID since most usernames are less than 32 characters long, so you're just:
- Making your program more complicated
- Making your indexes larger
Salt = md5(Hashed Username + db ID + Password)
Why? Salt is just supposed to be a unique value, so this massive overkill and arguable less useful than a completely random salt. Just grab some random data from somewhere (
/dev/random or whatever Windows has) and store it in the database. You're looking up the password anyway, so grabbing the salt too won't slow you down at all.
The fact that you're salting these values suggests that you don't really understand what's happening.
- If this value was stored anywhere, your password hashing scheme is broken (because
md5(user+id+password) is much easier to bruteforce than
PBKDF2-sha512(password, salt, rounds). You probably know better than to store it, but someone else may come along later and "optimize" it..
- If it's not stored anywhere, there's no point in hashing it. Just use
user+id+password as the salt directly.
Where rounds = 2 ^ ((days between now - 1st Jan 2008)) / 365) * factor (50000 perhaps).
So what happens when you look it up tomorrow? Suddenly the number of rounds is different and your passwords don't match. You'll need to store this somewhere, and the database is the easiest place. Also, if your hardware can support a higher number of rounds, why not just start with the highest number you can come up with?
If you want to get a new hash every time someone logs in, just generate a new salt every time.
You can get everything you want, with none of the security vulnerabilities by just doing things the standard way (bcrypt or PBKDF2, with random salts, and
rounds set the highest value you can handle).