Advice on authenticating client to server - in house solution

I am trying to develop a better authentication mechanism than what we currently have. I'm very new to cryptography and hacking so I'd like to see if my current idea has any major flaws.

Here is what we have:

1. Client sends username and password to server
2. Server checks DB, if valid, returns a ticket to be then used for future communications
3. Encryption is provided using SSL over HTTP

I want to emulate Kerberos method of never sending password over. Also making it harder for offline password guessing if the packet is spoofed. I've read about the possibility of the of using the pre-auth in Kerberos to guess the password by finding the datetime encoded.

My main goal at this point is how to transmit the ticket back to the user as securely as possible without making the solution too complex. So, here is what I came up with:

Client:
1. Generate an SHA2-256 hash of the password
2. Generate a GUID/UUID for the "shared secret" data
3. Generate a 1024bit RSA key
4. Encrypt "shared secret" and "public key (Modulus+Exponent)" using 3DES by providing first 24 bytes of SHA256 for key and last 8 bytes for IV.
5. Send username in plain text along with the encrypted shared secret and public key

Server:
1. Lookup account using plain text username
2. Decrypt the "shared secret" and public key using the password on file.
3. Generate a "ticket"
4. Encrypt the "shared secret" and "ticket" with public key
5. Send data to client - terminate connection

Client:
1. Decrypt the message with private key
2. If "shared secret" matches, server encrypted with your public key
3. Decrypt the "ticket" and use for future communications

There are two packets between client and server. If someone is sitting in the middle and gets a copy of both I am hoping it will be rather difficult to decrypt - or more importantly, guess the password. My assumption is based on this:

1. If I attempt to decrypt client request, I have no "magic" data that tells me it's a valid guid and valid public key. From what I've read, in Kerberos if you decrypted what looks like text version of timestamp, you probably guessed the correct password.

2. Even if you accidentally did stumble upon the correct decryption password, you would need to then find the private key of the public key used and then compare the shared secret.

What I am trying to achieve is a stand alone system - no ssl channel requirement, no need to purchase public certs, or setup a cert server. This is not NASA type of communication here - it's games/high scores/account management. But, I'd like to keep client's password secure because I know that some people use the same password for banks, video games, etc. Bad practice, shame on them, but I want to do my best to protect their password.

The current method scares me because miss-configured server will allow http without SSL and we also can not expose any other transport without coming up with an encryption mechanism. Kerberos has a decent solution and I simply added the single use RSA encryption to attempt to make life a bit more difficult for those who want to do an offline brute force.

It would also be preferred that clients be written in almost any environment and work. C#, VB, C++, Python, Ruby, and maybe even Javascript. I think most have libs for GUID, SHA256, RSA, 3DES.

So, is there any major flaw that will render this a 1 second crack? I'm concerned about the exponent. For all the random RSA keys I've generated (all 1024bits), it stays the same, which would then give the "magic" data to search for in first packet. Can I leave it out?

Your help is greatly appreciated.