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!

Solution 1

http://www.jcryption.org/ -- Is the combination you are looking for.

Solution 2

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.

Solution 3

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.

Solution 4

You don't need to encrypt the password. You need to hash the password. You really really don't want to have any access to the plaintext password yourself whatsoever, otherwise you lose non-repudiation, which has serious legal consequences. You need to investigate the meaning of this thoroughly before proceeeding.

View more solutions

Comments

[Jeffrey Hantin]

@deceze: Not really. See my answer for a replay-resistant cleartext login protocol.

[Admin]

But if it is PKI and the public key is on the client side, how will they have the key to decrypt?

[Gromski]

@0A0D That's the point, they don't need to actually decrypt it.

[Gromski]

@Jeffrey Indeed, some sort of nonce needs to be used. Upvoted your answer. Without SSL this may all still be susceptible to simple session hijacking, if the session token is not discarded immediately as well.

[Jeffrey Hantin]

@deceze Point taken. SSL certificate pricing is finally getting within hailing distance of domain registration pricing now, so there's really little excuse. However, I do rather wish that browsers would support anonymous SSL without throwing up a big scary warning AND without displaying any "secure connection" chrome, so it looks just like a regular unsecured connection. If nothing else, that would make life somewhat more difficult for hijackers -- they'd have to MITM instead of just sniff.

[zuallauz]

@deceze I already have protection in place for session hijacking, fixation etc. So even if they sniff the Session ID and cookie being sent it won't be usable for the attacker. I'm interested in protecting the actual plaintext password before it's sent.

[zuallauz]

@Jeffrey wouldn't the attacker be able to sniff the nonce and salt as the page got sent to the client. Wouldn't they be able to recreate the hash? Also with the GoDaddy SSL certs I think you have to be hosting your site with them. Also you have to renew each year so the price could go up.

[Jeffrey Hantin]

@zoszsoz You certainly don't have to host with them to use their certificates. The verification process is faster if you registered the domain with them, though. As for the protocol: hash must be a one-way function - given y and z such that z = hash(x, y), it must not be feasible to compute x. In order to compute the response value, the client has to know hash(password, salt) -- the server supplies salt so the client can derive it from password. nonce is just to prevent reuse of a response.

[zuallauz]

@Jeffrey Thanks yes I see how this could work and I may implement it like this. I would however still be interested in a JavaScript encryption/PHP decryption solution in case I want to encrypt other fields and use the decrypted plaintext at the server end. Would be educational at least.

[Admin]

@deceze: I'm sorry, I'm not following you. That's the point of asymmetric encryption, right? I can send you my public key encrypted data in the clear and it does not matter if you do not have the private key to decrypt.

[Gromski]

@0A0D And I'm saying I'm not even interested in decrypting your encrypted password. :) I'll just sniff the encrypted password you're sending to the server and forge the exact same request, sending the same encrypted password to the server, which will allow me to log in the same way you do. Without a nonce this replay attack is trivial and I don't care whether or how or how often you encrypt your password.

[Admin]

@deceze: Right, now I see what you are getting at.

[Admin]

except he still needs to pass a salt or nonce to the client-side and store that on the server side so that he can compare the hashes.

[Admin]

@zoszsoz: Why not use self-signed SSL certificates if you are concerned about the cost?

[zuallauz]

@Jeffrey How long do I need to keep the nonce for on the server? The duration of the session? Or in the database permanently? @0A0D Potentially I could use self signed certs, but don't they throw up a nasty warning page in the browser before you can accept them? Kinda don't want potential customers seeing that.

[zuallauz]

@Jeffrey Regarding the second step of 'sending the salt to the browser with the form'. Each salt should be unique to each user account and stored in a separate database field along with another field for the hashed password. When the user enters a username on the form I'd have to use AJAX to check the database for that username then send the salt corresponding to that user account back to the page. If their browser remembers the username/pw and they submit the form immediately the AJAX wont have returned the salt in time so will not work.

[Jeffrey Hantin]

@zoszsoz If you're not doing it as two separate pages (username on one, password on the other) then you probably can't use a submittable form -- instead, the whole thing needs to be AJAX. When the login button is clicked or enter is pressed, fire off the AJAX request with the username to retrieve a challenge, then send the response in a second call.

[zuallauz]

@Jeffrey Many thanks, I actually got it working! And it works quite well! Check out the implementation. Does it look alright? I'm unsure how I'd get it to work for the register or edit-password pages though. These pages would need to store the hashed (password + salt) in the database. So if the page is sending through the hashed (salt+password+nonce), I won't be able to extract just the salt+password hash. Any ideas?

[Jeffrey Hantin]

@zoszsoz This protocol only works for password verification, not for account creation or password change. Account creation is a tough one, since you don't have an existing trust anchor, but Diffie-Hellman key agreement, then using the resulting key to encipher the password, would suffice to stop a passive sniffer.

[user2867288]

@deceze That would work if you only ever generate one key. Have the server send a new public key to the client before each request, invalidating that key after the next request and sending a new one. Whamo, copypasta of the RSA encrypted password string doesn't work anymore.