What you describe is very similar to the idea behind Kerberos, but it stops short of actually solving the problems Kerberos solves.
Knowing both AES(A,B) and AES(B,A) would certainly help an attacker by allowing them to authoritatively test for a valid decryption; if they knew neither, but found some candidates for A,B with m1=AES(A,B), they could test that AES(B,A)=m2 where m2 is the other intercepted message. However, this is really the least of your worries.
AES keys have to be a particular length. You haven't mentioned how your key derivation works, so I won't talk about that.
Really, the correct model for doing this kind of thing is to derive a key from the user's password on the client node. The server knows a key that can be used to encrypt data such that the client can decrypt it, and on request creates an authentication token which it sends to the requester thus encrypted. The token is useless to anyone who doesn't know the user's (private) key, so it's safe to send to whoever. The user then decrypts it and is authenticated.
The user doesn't need to immediately send this token back; the server can assume whoever can present it is authenticated as the user it was issued for.
Now, I'll solve some other problems by adding to the model: the thing sent from the server to the client is not a token, but another key. The user, provided they can decrypt the key, can use that key to sign requests. That way, nothing sensitive has to traverse the network in the clear and there isn't even much need for establishing a trusted channel.
Kerberos takes this a step further by allowing this key to be used to issue still more keys, and has some other concepts, which allow a user to sign in one place to authenticate to another. There are also some nonces to prevent replay attacks, and stuff. However, so far as your solution deviates from this model, it is suboptimal.
The highlight here is that you don't want the plaintext password anywhere, least of all on the server, and you really don't need to be sending it across the network or verifying it. But, instead of redesigning your system to match, just use one of the numerous challenge-response authentication methods already implemented and audited and available.
Attacks against your scheme are possible, but what attacks in particular depends on whether your token (the big number you refer to) is properly treated as an nonce, how big it is, how you derive keys from passwords (and nonces), how you treat the password on the server, how the nonce is generated, and some other things. The primary line of attack I would choose is to predict the nonce and use that to decrypt the password, validating against the traffic in the other direction.