Question

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. 😀

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.

Answer 1

You basically want to implement SSL on HTTP; which is somewhat feasible, but will never be as good as the real thing.

Being able to send encrypted data back and forth is only half the problem. Another part of the problem is ensuring you are actually talking to the server (think of man in the middle attacks).

I am not really sure how the SSL works, but that is the way to go. You should read up on that. From the looks of your scheme, it seems totally pointless however. Why are you sending plaintext back to the server? That defeats the purpose of having this set up.

Here’s how I would do this:

1. Server sends a random token to the client. Server stores the token in a “pending” list. These can be purged in some interval (eg: every 15 minutes)
2. Client sends enc(comb(username, password, token), pubKey) back to the server, where comb() is some function that combines the username, password and the random token.
3. Server gets the username and password back using decomb(dec(message, privKey)) where decomb() is the inverse of comb().
4. Server checks if the token is present in the pending list. If it’s not, reject the login attempt. If it is, it server can proceed to perform authentication as usual.

If the generated tokens are never repeated, an attacker can’t just re-send the same encrypted message, nor can they decrypt the message to find out what everything was.