Two-way password encryption without ssl

Question

I am using the basic-auth twitter API (no longer available) to integrate twitter with my blog's commenting system. The problem with this and many other web APIs out there is that they require the user's username and password to do anything useful. I don't want to deal with the hassle and cost of installing a SSL certificate, but I also don't want passwords passed over the wire in clear text.

I guess my general question is: How can I send sensitive data over an insecure channel?

This is my current solution and I'd like to know if there are any holes in it:

1. Generate a random key on the server (I'm using php).
2. Save the key in a session and also output the key in a javascript variable.
3. On form submit, use Triple DES in javascript with the key to encrypt the password.
4. On the server, decrypt the password using the key from the session and then destroy the session.

The end result is that only the encrypted password is sent over the wire and the key is only used once and never sent with the password. Problem solved?

Answer 1

1. Generate a random key on the server (I'm using php).
2. Save the key in a session and also output the key in a javascript variable.
3. On form submit, use Triple DES in javascript with the key to encrypt the password.

This avoids sending the password in the clear over the wire, but it requires you to send the key in the clear over the wire, which would allow anyone eavesdropping to decode the password.

It's been said before and I'll say it again: don't try to make up your own cryptographic protocols! There are established protocols out there for this kind of thing that have been created, peer reviewed, beat on, hacked on, poked and prodded by professionals, use them! No one person is going to be able to come up with something better than the entire cryptographic and security community working together.

Answer 2

Your method has a flaw - if someone were to intercept the transmission of the key to the user and the user's encrypted reply they could decrypt the reply and obtain the username/password of the user.

However, there is a way to securely send information over an unsecure medium so long as the information is not capable of being modified in transit known as the Diffie-Hellman algorithm. Basically two parties are able to compute the shared key used to encrypt the data based on their conversations - yet an observer does not have enough information to deduce the key.

Setting up the conversation between the client and the server can be tricky though, and much more time consuming than simply applying SSL to your site. You don't even have to pay for it - you can generate a self-signed certificate that provides the necessary encryption. This won't protect against man-in-the-middle attacks, but neither will the Diffie-Hellman algorithm.