Why Windows 7/2008 mstsc asks for username password BEFORE server certificate warning?

When using Windows 7 mstsc to connect to an Windows Server 2008 (remote desktop), I notice a problem I cannot explain.

mstsc asks for username password first. If I provide a wrong one, mstsc tells me "The credentials that were used to connect to did not work".

Only after if I provide a correct one, mstsc warns me that the server's certificate is not trusted.

I think mstsc SHOULD prompt for "server certificate not trusted" before it verifies "whether my username/password is accepted by server".

So my question is: Is it possible that, in case the server I connect to is a forged one(hosted by an attacker), my credential will be compromised?

Even if my credentials will never be compromised in such situation, isn't it better for mstsc to prompt for server certificate problem BEFORE asking for username/password? At least, that could eliminate the worry of password being stolen for an average user.

What's happening here is a little complex, but if you read up on NLA and CredSSP you'll get a better picture.

http://technet.microsoft.com/en-us/library/cc749211%28WS.10%29.aspx

http://en.wikipedia.org/wiki/Network_Level_Authentication

Basically, to answer your question...No, a forged server wouldn't compromise your credentials. First thing they'd have to do to being with would be to spoof your DNS to an incorrect IP, but even then the way RDP works now (assuming we are talking a Win7 or Vista client and a Win2008 or newer server) the credentials are encrypted and not exposed (caveat is NTLM explained in the bottom of the Technet article).

Here's an excerpt that might help from the Technet article:

Unlike the experience in Windows Server® 2003 Terminal Server, the credential prompt is on the client computer and not the server. Most importantly, the client credential prompt is on the secure desktop. Therefore, not even the Terminal Services client can see the credentials, which is an important Common Criteria requirement. Furthermore, the credentials obtained from the prompt will not be delegated until the server identity is authenticated (subject to policy configuration). Finally, the terminal server will not establish a session for the user (which consumes a significant amount of memory and CPU processing time on the server) before authenticating the client, which decreases the chances of successful denial-of-service attacks on the server.

EDIT : let's add an example to clarify...

EXAMPLE #1 - USER HAS ACCESS TO REMOTE SERVER AND USES CORRECT PASSWORD

In this example, you'll enter the username and password, it will authenticate LOCALLY to the domain to verify it is a valid username/pwd and then try and connect to the remote server. At that point if it is the first connection you will probably get the "The identity of the remote computer cannot be verified" and you can choose to trust it or not.

EXAMPLE #2 - USER HAS ACCESS TO REMOTE SERVER AND USES INCORRECT PASSWORD

Here you'll see the pic you posted...The credentials did not work. Please enter new credentials. This is done locally on the client (validated against a kerberos ticket or the DC) without ever connecting to the remote server.

EXAMPLE #3 - USER HAS NO ACCESS TO REMOTE SERVER BUT USES A CORRECT USERNAME AND PASSWORD

Here you'll authenticate locally since it is a valid account and pwd, but once you connect to the server to pass the credentials you'll get:

Hope that helps...