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

Answer 1

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.

Answer 2

The problem with client-side javascript security is that the attacker can modify the javascript in transit to a simple {return input;} thereby rendering your elaborate security moot. Solution: use browser-provided (ie. not transmitted) RSA. From what I know, not available yet.

Answer 3

I've implemented a different approach

1. Server: user name and password-hash stored in the database
2. Server: send a challenge with the form to request the password, store it in the session with a timestamp and the client's IP address
3. Client: hash the password, concat challenge|username|passwordhash, hash it again and post it to the server
4. Server: verify timestamp, IP, do the same concatenation/hashing and compare it

This applies to a password transmission. Using it for data means using the final hash as the encryption key for the plain text and generating a random initialization vector transmitted with the cipher text to the server.

Any comments on this?

Answer 4

How can I send sensitive data over an insecure channel

With a pre-shared secret key. This is what you attempt in your suggested solution, but you can't send that key over the insecure channel. Someone mentioned DH, which will help you negotiate a key. But the other part of what SSL does is provide authentication, to prevent man-in-the-middle attacks so that the client knows they are negotiating a key with the person they intend to communicate with.

Chris Upchurch's advice is really the only good answer there is for 99.99% of engineers - don't do it. Let someone else do it and use their solution (like the guys who wrote the SSL client/server).

I think the ideal solution here would be to get Twitter to support OpenID and then use that.

Answer 5

You don't have to have a certificate on your server; it's up to the client whether they are willing to talk to an unauthenticated server. Key agreement can still be performed to establish a private channel. It wouldn't be safe to send private credentials to an unauthenticated server though, which is why you don't see SSL used this way in practice.

To answer your general question: you just send it. I think your real general question is: “How do I send sensitive data over an insecure channel—and keep it secure?” You can't.

It sounds like you've decided that security isn't worth the $10–20 per month a certificate would cost, and to protect Twitter passwords, that's probably true. So, why spend time to provide the illusion of security? Just make it clear to your users that their password will be sent in the clear and let them make their own choice.

Answer 6

If you don't want to use SSL, why not try some other protocol, such as kerberos?

A basic overview is here: http://www.kerberos.org/software/tutorial.html

Or if you want to go somewhat more in depth, see http://www.hitmill.com/computers/kerberos.html