SSL Alternative - encrypt password with JavaScript submit to PHP to decrypt

Question

I'm building a website and my payment methods will be Google Checkout and Paypal. There will be links/buttons which will redirect the user to the secure Google/Paypal sites for processing the payments. This means I do not need the $150/year added expense and complexity of installing SSL certificates for my site.

However I would like to encrypt user's passwords as they are logging in so that if they are on a network some malicious person running FireSheep etc can't read the user's actual password as it is being sent to the server. The rest of the site doesn't need encryption as it's not really sensitive data and would probably slow the user experience down significantly.

My thoughts are this could be implemented with public key cryptography. Lets say the process goes something like this:

1. Public key is in the JavaScript external file, private key in PHP on the server
2. User enters their username and password into the form and clicks submit
3. The JavaScript runs and encrypts the password, storing it back in the text field
4. Form is submitted to server and the password is decrypted with PHP
5. Plain text password in PHP is salted & hashed then compared to hash in database.
6. Possible similar process for the registration/change password functions.

I'm thinking something like RSA would do the trick. But I've hunted around the net for a working JavaScript library to do it but none seem to be compatible with the PHP libraries available. At any rate it needs to generate a set of keys that are compatible with the JavaScript and PHP.

Anyone know of an actual working solution for this? If not how about we write one then open source it. Unfortunately writing encryption/decryption code is pretty complex so I don't really know exactly what the existing libraries are doing and how to modify them to make it work. I already have protection for session fixation/hijacking so I'm not interested in that. Just interested in encrypting the data before it gets to the web server.

NB: Please don't post a bunch of links to standalone Javascript or PHP encryption libraries, I've found those already on Google. That's not actually useful. What I need is code for JavaScript encryption AND PHP decryption that actually works together harmoniously to produce the intended result outlined above.

Also if you could refrain from posting comments like "just use SSL". I'd actually like a solution to this exact problem even if it's not best practice, it would be interesting none the less.

Many thanks!

Answer 1

Only one problem: An attacker does not need to know the actual password. All he needs to see is the value that is sent to the server. This value allows the user to log in. It does not matter what that value is; whether it's plaintext, encrypted text or a picture of a cat. It's just a token that authenticates the user. If an attacker can see this token and repeat the same request and that same request allows him to log in, you gained nothing.

Answer 2

RSA is overkill; what you probably need is a simple challenge-response protocol. For example:

• Generate a random nonce value; this helps prevent replay attacks.
• Send that nonce value and the password salt to the browser along with the rest of the login form.
  • You are storing passwords in salted and hashed form, right?
• When the user enters a password, have the script on the form compute and send back hash(hash(password, salt), nonce) instead.
• When the server receives the form submission, have it compute hash(storedSaltedPassword, nonce) and verify that it equals the submitted value.
  • Retain the nonce value at the server; don't trust the client to echo it back to you, or your replay protection is gone.

The weakness of this scheme is that the password hashes in the database are in some sense password-equivalent; while it's likely infeasible to extract the original password used to produce those hashes, knowledge of the stored hash is sufficient to impersonate the user on your site.

SSL certificates serve an entirely different purpose: the purpose of an SSL certificate is to make it difficult for a third-party rogue server to claim to be your server, because it doesn't have a certificate signed by some mutually trusted third party that it belongs on your domain. On the other hand, if you can't stop a rogue server from impersonating yours, you can't protect your users from giving their password to that rogue server, cryptography notwithstanding.