Secure login: public key encryption in PHP and Javascript

Question

I'm trying to make a "normal" username/password login form secure, without needing HTTPS. My idea is this:

• Server generates a keypair for some kind of assymetric encryption algorithm. It stores this keypair in a temporary table of sorts (or perhaps the local session data).
• Server sends the form to the client and includes the public key.
• User fills in the form.
• Before it's sent to the server, Javascript encrypts the password using the given public key.
• Form is sent.
• Server decrypts the password with it's private key (which it gets from the temporary table, using the public key to find it).

What I need to know for this is:

• Which encryption method is the best to use? RSA?
• How can I decrypt the password in PHP?
• And probably the most difficult one, how can I make Javascript encrypt the password?

Answer 1

This is a very good idea, and it's already been done. See jCryption.

Answer 2

It looks like a lot of what you want to do is supplied by the jquery plugin JCryption. It even assumes PHP as the backend, so a good fit for you.

Answer 3

jCryption looks interesting, I've not seen it before.

But I have to ask what is wrong with SSL?

Encryption code is notoriously hard to do right, and you can bet that the SSL implementations found in browsers and http servers are much more rigorously tested and reviewed than the jCryption stuff.

That said, jCryption looks neat if you absolutely need to avoid SSL, and you're not dealing with super-sensitive information.

Answer 4

This doesn't seem that secure from the perspective of the client. Two (related) problems:

1. How does the client trust the server? How can it verify that the key the sever's presenting is the one that belongs to it?
2. It's possible to do man-in-the-middle attacks. A malicious proxy could strip out and store the public key before the client sees it, substituting its own, then decrypt the password when the client authenticates, store it, and re-encrypt and send the response on so the client doesn't realise something's up.

What's wrong with ordinary SSL? There has to be a consensus that it's secure, otherwise vendors and organisations would drop support for it overnight. By contrast, most attempts to invent a funky new way to do security "on the cheap" usually miss something fundamental.

Answer 5

In advance: I'm sorry for being negative, however;

Implementing you're own security protocol is never a good idea, unless you're a highly trained security expert, or you actually don't really care about the security and only want to create an impression of security (marketing) and stop the script kiddies.

SSL is definitely not a fingerprint lock, as so say in your comments, JCryption and your proposal are equal to having a door where you can enter a two-digit code to open the door and you have infinite many retries. Its hard to break if you're not really interested and just passing by, but if you want to get in that house (and you probably do, else security wouldn't be needed), you will get in.

Another point is that people often forget to mention what they want to achieve. Security has the famous three components called CIA, namely confidentiality, integrity and availability. Is it for you important that the data you transport is confidential, or is integrity important (i.e. you're sure that the sent data comes from the one you expect and not the man in the middle)?

To make it concrete in this case, the only thing that you achieve here is that an passive attacker cannot see whats passing by on the line. As soon as your attacker gets active and changes the messages on their route, you're whole security falls apart. So my advice would be to just stick with the solution the experts have come up with (TLS in this case, not ssl since that is the old version of it) and just make sure you're server supports it.

edit:

Btw, SSL/TLS cannot work without certificates. The whole point in public key crypto is that there should be at least somewhere some trusted party.

On the other hand, if you don't care that you're users will get an "invalid certificate" message, you can just create you're own certificate which is really easy. In that case your certificate isn't trusted by the browsers, however, you can be sure that at least your communication is safe (okay, there are exceptions in this case, but still ...)

The argument that certificates should be for free is really from a perspective point of view. I think people who claim it is bogus/idiotic don't know what it takes to be a certification authority. These companies invest millions in order to keep the communication secure, and sure they make nice money out of selling certificates, but hey its their job and they also deserve to make money, just like any others.

edit2: after comments

I indeed say that you have a secure communication. However, you miss the point that with self signed certificates you dont know to whom you talk securely. Imagine a dark room which is completely isolated from eavesdropping a conversation. Now imagine the difference between such a room with and without light. If the room has light, you can actually see to whom you're talking securely and only choose to talk to people you like to trust. Now imagine doing the same in a completely dark room. You can only hope that the guy you talk to inside this dark room is just a ally and not your adversary. However, you cannot know that, just hope that its oke. And although your conversation itself is secure, nobody can listen in, you still dont have "full" security.

If I, being a crook, do a man-in-the-middle attack, I can create a self signed certificate without the user noticing. So the advantage of using tls with self signed certificates is that you have at least the implementation of the protocol corrent (and even implementing this is far from easy). Moreover you can avoid the ugly warnings by advising you're users to manually trust the certificate once. However, this is only possible if you have a relatively small group of returning visitors, for a public website this is not really a solution.

Answer 6

Livejournal does something similar to what you want where:

1. Server generates a challenge string, inserts this into form. [1]
2. Client generates response by MD5 hashing the password, then MD5 hashing the previous hash with the challenge prepended [2].
3. Server gets response, checks challenge validity, then does same as step 2, comparing the result to the response.