Can I use JS encryption instead of SSL for credit

Question

I have an HTML form where people can make payments on my sites. Instead of using SSL, I'm wondering whether I could use a JS lib that would encrypt the credit card information and send it to the server in clear text but encrypted, than the server would decrypt it. I found several libs that do that, they basically ask for a key pair from the server, encrypt it and send it to the server encrypted. Those are the ones I found:

http://www.jcryption.org/

http://www.hanewin.net/encrypt/

http://www.vincentcheung.ca/jsencryption/

Is that secure enough for credit card payments? I know the session is not encrypted but the only thing that really matters is the credit card information, right?

Answer 1

Absolutely NO

If you want to take credit card payments and you don't want to do it yourself properly, there are service organizations that specialize in exactly this.

Here's a few:

2CheckOut, Affero, BTClick&Buy, CCAvenue, CCBill, CCNow, ClickBank, DigiBuy, DigitalCandle, FastPay, iBill, iKobo, ImagineNation, InstaBill, Jettis, Kagi, MembershipPlus, Moneybookers, MultiCards, MyPaySystems, NoChex, PartyKey, Pay-Line, Paymate, Process54, ProPay, Reg.Net, RegNow, RegSoft, Share*It, StormPay, SWREG, V-Share, Verotel, VolPay, Yahoo! PayDirect.

Here's a more complete list

Give them a call!

And of course there's always PayPal

Answer 2

The PCI DSS standards are now a requirement so you even if you could do this with JS (which as has been extensively discussed on this page - you can't) then you still wouldn't get PCI approval so you wouldn't be allowed to use it.

If you absolutely want to avoid buying an SSL certificate then look into your payment providers service. Most of them provide a third party hosted solution such as Paypal, SagePay, etc where you are passed out from your site over to the providers website to take the credit card details and then passed back.

This removes the burden from you to a) be compliant and b) buy an ssl cert.

Answer 3

No, because you're still susceptible to a man-in-the-middle attack.

But you can use it to lower your PCI compliance requirement considerably, because if you encrypt credit card numbers with a public key to which you don't have the private key, then you shift the burden of compliance.

This is encouraged even by the payment processors. See for instance Braintree's write-up on client-side encryption.

Answer 4

What if the user disables JavaScript in their browser? I would say, play it safe and stick with SSL.

Answer 5

The potential legal trouble you could get in from this is way not worth avoiding the cost of SSL.

Answer 6

You could do this, but don't. It requires javascript on the client side and while you get the encryption part you probably are going to lose the other portion of SSL which is authentication. Using your method a man in the middle attack is possible while with SSL certificates it is much less likely.