Authenticating a user over HTTP (instead of HTTPS)

INITIAL NOTE: This is just for a personal tinkering project; I'm not writing enterprise security here, and if I were, I'd know better than to try to write my own scheme. :-D

EDIT: To stress the above point, I tried to tag this under "iKnowThisWouldBeABadIdeaInRealLife", but SO wouldn't accept it because it was >25 chars. Just be aware that I KNOW it's not commercial grade!

I need a way to authenticate a user over HTTP (can't use HTTPS in this case). I need to know that the person on the other end really is who they say they are (to some reasonably high degree of confidence). Once I'm sure the user is legit, I do not care if the content between the client and the server are sent as plaintext.

The trouble I'm looking at is in trying to send a password from the client to the server without sending it as plaintext. I've thought about trying some public-key crypto in javascript, since some Google searching has turned up some fun-looking libraries.

Here's the scheme I'm thinking about:

(suppose A and A' represent the private and public keys, respectively; also, enc(text, key) and dec(cyphertext, key) represent the encryption/decryption functions)

    +------------------------+------------------------------+
    |         SERVER         |            CLIENT            |
    +------------------------+------------------------------+
(1) | t = randomToken()      |                              |
(2) | enc(t, A)           -------->  c                      |
(3) |                        |       A' = getKeyFromUser()  |
(4) | p                 <--------    p=dec(c, A')           |
(5) | if (t==p)              |                              |
    |     allowAccess()      |                              |
    | else                   |                              |
    |     denyAccess()       |                              |
    +------------------------+------------------------------+

One weakness I see in this is that the BAD GUY who was listening to the exchange, while he doesn't have A, now has a known ciphertext/plaintext combo, which I remember from crypto class is a BAD IDEA. I figure some salting could alleviate this somehow?

So here are my [two] questions:

1. Is this a 'good' scheme? (remember that I don't CARE if anything following this initial exchange is plaintext - I'm ONLY trying to verify initial identity here)
2. What would be the best way to get around the "known plaintext/cyphertext pair" weakness mentioned above? Salting?

Thanks!

EDIT: Thanks for all the discussion! Just to clarify:

• I'm NOT worried about assuring the CLIENT that the SERVER is who they say they are. Only the opposite (assuring the SERVER the CLIENT is who they say they are)
• I know about MITM attacks. This scheme is NOT intended to protect against them.
• I know there exist plenty of solutions for this already. This is purely a learning exercise for me! I'm not trying to re-invent the wheel or build a better mousetrap. This is just for fun!

• Here was my thought-process for the scheme: (I know I'm not quite using public vs. private keys properly, but bear with me for a sec)

  • Bob walks up to Alice and says, "Hey, I'm Bob."

  • Alice says, "Okay. I know Bob's 'private key'. If you're really Bob, take this secret message I just encrypted (with Bob's private key), and decrypt it for me."

  • Bob replies with the correct message, and Alice is happy.