I have an HTML form where people can make payments on my sites. Instead of using SSL, I'm wondering whether 开发者_StackOverflow中文版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?

This is not secure in any way, shape, or form.

A man-in-the-middle can replace the public key with his own. Any kludge you devise with "referer" or anything else besides SSL is not going to restore security to this atrocious scheme.

When you can get a marginal certificate for free, or a decent certificate for next to nothing, why would you screw around with people's credit card number? By failing to secure a credit card number in transit, you are violating PCI, and probably exposing yourself to a liability many times greater than the cost of obtaining and using a certificate. Or maybe you are just figuring that's the cardholders' problem?

You cannot bootstrap a secure channel entirely in-band. You need some secure medium for exchange of key material. That might be the distribution of a Certifying Authority's public key. Or perhaps meeting face-to-face to share a secret key.

Regardless of the scheme, you cannot build security out of insecurity.

No. Do not use javascript to secure credit card payments.

If you did, it would be trivial for someone to copy all your source code, and then poison the DNS cache or even setup phishing sites and send your users' payments into their bank account.

Here's a scenario.

You complete your website, example.com, and put everything online. Site launches, yay. You've used javascript to secure your credit card payments system.
Someone named Nefarious Hacker notices that you're not using a tried-and true method of securing vital personal information, so he downloads all of your HTML, JS, and CSS.
N. Hacker strips out all the js based encryption, leaving only the form. He then hosts it at evil-example.com. It looks exactly like your site, and behaves exactly like your site. Except that it submits unencrypted credit card data to N Hacker's database.
N. Hacker sends out some phishing emails that point users to evil-example.com. A few users, believing the evil site to be valid, submit payments. Their credit card is now stolen.
N Hacker is able to successfully poison a DNS cache, so some users going to example.com instead are served up evil-example.com. They have no reason to believe the site is fake (the url is what they expect), so they submit payments. Their cards are now stolen.

If you had an SSL cert, the users would know IMMEDIATELY that the evil-example.com was not trusted, or that evil-example.com pretending to be example.com was fake.

(I'll make it big so it's obvious)

Bottom line - javascript is not secure enough to do CC payments.

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.

You could use JS encryption and chose to ignore the fact that it wasn't secure.

The problem you'd have then is that people wouldn't want to enter their credit card details on a page without an SSL connection. It wouldn't just be techies; a lot non-technical users know to look for the padlock before entering their Credit Card number, even if they have no idea what TLS or SSL are.

Not at all. Remember that SSL also allows the client (the browser) to verify the authenticity of the remote party (your server). You have to make sure that the server you get the keys from is actually the one you want to get the keys from and not an entirely different machine. (cf. Man in the middle)

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

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

@stimms explains well why this is dangerous - SSL does both encryption and ensures that the encrypted data is going to the right place as well. On top of that, browsers treat SSL and non-SSL caching differently - if you're not serving these pages over SSL, the user's browser may store vital information in the clear on the user's computer.

Even if perfectly safe, this wouldn't be a good idea either. Many users have had the rule "look for the lock icon for e-commerce" drilled into their brains by IT staff, tech-savvy relatives, etc. Spring for the $25 for a SSL cert.

edit: Another potential issue - most credit card companies require transmission over SSL. Doing it with just JS may well violate your merchant agreement - fines and termination might ensue.

Ggolo, seriously dude, don't do this. Any site passing credit card details is going to get attention from hackers, who WILL find some mistake or exploit in your hand-rolled approach if they try hard enough. Just stump up for the SSL cert.

While technically the data encrypted in JS would be similar to encrypting it with a real cert, I think you are missing a key element here; TRUST. When using a real SSL cert from a trusted provider, you are making a circle of trust:

Customer trusts Microsoft
Microsoft trusts GoDaddy/Verisign/whoever (by virtue of Windows or any other web browser shipping with the root certificates)
GoDaddy/Verisign/whoever trusts You (by virtue of you having bought a cert from them, and they verify your identity)
Green lights and locks appear in web browser, and user can inspect the certs themselves if they want, Which in turn means Customer trusts You.

When you just have an unsecured web site, with the words "your data is secure, just ignore what your web browser is telling you", then the customer does not trust you.

(and if they do, then forward me their info, I have a bridge to sell them...)

Also, for what it's worth, there are standards from the major CC companies on how to handle and store credit card info. Google "PCI DSS" for details, or: https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml

In addition to the points everyone else has made, SSL is an established standard and every Web browser has built-in support for that standard. The browser GUI changes in some way to let me know that I'm using a secure connection and I can inspect the certificate details if I want to.

Browsers don't have any support for whatever home-grown scheme you come up with.

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.

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.

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