how to make sure the BlowFish key is transferred securely

Ok, bunch of issues there.

1) you can transfer the key to them securely over https. but if you *can* transfer securely over https, why bother with blowfish at all? Https is designed for this role, and blowfish really isn't.

2) If they have the key and can intercept traffic, they can use the key to decrypt that traffic.

3) unencrypted data is fine if the link is secure, but IP filtering wont' cut it if there is any possibility of interception.   Firesheep was a wake-up-call for many providers in this respect.

4) *any* method that uses a fixed symmetric key is going to need to look hard at replay attacks (simply re-sending the encrypted form unchanged) and similar issues.

5) the usual method of handling a password is challenge-response - so normally a web service will expect a username (unencrypted) and respond with a random string (called a nonce in the lit; the same concept is given by salt, but that implies different usage). The client then concatenates the nonce and the password, applies a hash, and sends back the hashcode.  The server can perform the same calculation and compare its result to the result it gets back - so no need of a key, no chance of a replay attack, and no way to get the password back from the hash actually sent.

i didn't design this thing, but based on my understanding, the reason they did this is:

if only the client and the server have the blowfish key, sending an encrypted username/UID to be decrypted is in a way like passing in username/password,

i still like the https approach (mutual SSL), where the server and client both have certificates to authenticate themselves.  this saves the hassle of transfering the key using some sort of web page UI and https, and having to encrypt and decrypt everytime you want to call a method.
i also didn't understand why when the client is sending the encrypted username/UID, it's also sending the unencrypted username/UID along with the encrypted one.

Well, yes, if you encrypt the username with the key, then they can decrypt the username and that's fine. however, that raises the possibility that you can encrypt *any* username with the key, and if the key is not per-username, you can log in as anyone.

Second, it means the username-encrypted-with-key is itself an *access token*. You don't need to know what it reads, just need to pass it *exactly as sent last time* and you will get access. That makes the encryption essentially worthless - its obviously not practical to remember the encrypted version, but Eve doesn't need to worry about that, just replay.

So, overall this is poor design. you would get better traction from a challenge/response scheme using a per-user password and a simple hash, or a simple https POST with user+password.

well, they are attaching a timestamp behind the UID before encryption to prevent replay attacks by checking against some sort of time threshold.  

i didn't quite understand this statement:

"however, that raises the possibility that you can encrypt *any* username with the key, and if the key is not per-username, you can log in as anyone."

" if a party a has a blowfish key x, and normally encrypts "party a/timestamp" that is fine. however, if there is no external indicator of the user id, then by definition all parties must use the same blowfish key (as there is no way for the app to know which key to use) hence party b could encrypt "party a/timestamp" just as easily, and have access to the account of party a."

i am assuming the above is possible only if the attacker has the key and knows party a's UID.

"S>C "[SSL Certificate]"
C>S "ssl handshake([SSL Certificate])"
C>S "encrypt([SSL KEY],"I am [username] and my password is [password]")"
S>C "encrypt([SSL KEY],"Thankyou [username], you are now accepted")""

if we are using mutual SSL (i know it's harder to set up), mutual authentication is already done without user interaction, is there a need username/password to be sent?  i can understand if you are sending only the username just so the server knows who you are and can then log your history.

i am assuming the above is possible only if the attacker has the key and knows party a's UID.

That depends on if the key is different. IF *I* have the same key as another user, and can get a copy of his traffic (from sniffing at a wifi router, say) I can decrypt his transmission, and simply update the timestamp.
IF I can't intercept the traffic, but do share a key, then I would need to know any corresponding info for the person I wish to spoof; in some cases, that can be obtained by another route, but yes, the more unique info that is in the encrypted packet, the harder it is to reproduce.  If the keys are different, then you are in the realm of a replay attack (only) but need to have some external reference to the account so that you know which key to use.

if we are using mutual SSL (i know it's harder to set up), mutual authentication is already done without user interaction, is there a need username/password to be sent?  i can understand if you are sending only the username just so the server knows who you are and can then log your history.

No, if you are using clientside certificates, then they can both act as a gatekeeper to the solution, and as identification of the user. You then have to worry about the security of THAT access token, as it will then need to exist on the user's machine and would not be trivial to re-type from memory :)