As the llama says, there is little point in pre-hashing the password on the client side: SSL protects you. Of course this assumes that you use SSL for all communications; if you do not, then you already have much bigger problems that you should tackle first.
If an attacker sees "SHA-512(password + long_string)" then the attacker can run an offline dictionary attacks on that password, i.e. trying potential password values until a match is found. Of course, this assumes that the attacker knows "long_string" but since both client and server know it, and it has not been entered by the human user, then one must assume that the "long_string" is either provided by the server prior to user authentication, or is hardcoded in the client code. Either way, it is unreasonable to assume that the attacker does not have it. The dictionary attack will run at a rhythm of several millions of tries per second, because, let's face it, a basic PC is really good at computing SHA-512.
To some extent, if "long_string" is really long (we are talking megabytes here), then the cost of hashing may become non-negligible and thus slow down the attacker. Such slowness is half (but only half) of what makes a good password hashing function. Note that cryptographic algorithms are subtle: "SHA-512(long_string + password)" would be much weaker, in that respect, than "SHA-512(password + long_string)" (if you do not see why, then don't touch that keyboard again). The second half of good password hashing is about deterring parallel attacks, which, in this case, would mean that each user has his own "long_string" value, distinct from those of the other users. The "long-string" then acts as a salt.
Your alternative, with "SHA-512(username + password)", fails at the slowness parts, and imperfectly ensures the non-parallel part (because user names are not unique worldwide, and are also reused when the user changes his password). Depending on how "long_string" is chosen in the original system, your proposal may weaken or strengthen the security.
The answer to the exact question is that if the attacker see both values then he can choose which one he will attack, and this can only help him. However, a more thorough answer is that:
- You should send passwords only through a properly secured tunnel (SSL), at which point there is no good reason to hash the password on the client side; thanks to SSL, the client knows that it is sending the password to the right server, and only to that server. Simply send the password "as is".
- If you plan to use the hashing as a storage mechanism on the server (i.e. the server does the hashing, not the client, and the result is stored in the server's database) then your new system may be slightly better than the previous, or slightly worse, but both are weak anyway. Go read that answer; it would be most unwise to design cryptographic systems with password until you understand it thoroughly (you do not need to agree -- Science without debate is no longer Science -- but at least you should understand the concepts).
