homepage Welcome to WebmasterWorld Guest from 54.161.220.160
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Pubcon Platinum Sponsor 2014
Home / Forums Index / WebmasterWorld / Webmaster General
Forum Library, Charter, Moderators: phranque

Webmaster General Forum

This 37 message thread spans 2 pages: 37 ( [1] 2 > >     
Securing Data Passed in a Form or Payment Transaction
How do you send sensitive information from a form?
Harvs

10+ Year Member



 
Msg#: 10994 posted 11:47 am on Feb 17, 2006 (gmt 0)

Hi,

I am just finishing off a site for a small business and they have decided they want to do a small amount of sales online. So what they have asked for is a form that people can fill out with their order details and credit card information then send the form results to an email address. The business will then process the credit cards manually through their existing system.

As I understand it sending sensitive information to email accounts is never recommended even if using PGP for encryption. The problem is how do I get this senstive information from the customer to the business in a secure and cost effective way?

I would think this is a problem people have had before but I couldn't find an answer anywhere.

 

Scruffy

5+ Year Member



 
Msg#: 10994 posted 12:02 pm on Feb 17, 2006 (gmt 0)

This is a common question.
Your client is trying to get online sales on the cheap with scant regard for the customer's security.
Yes, it can be done, but it is an open invitation to any thief with a knowlege of internet systems. Any customer suffering identity theft will be able to take your client and you to law seeking punitive damages.

If you want to get involved, insist on doing it properly. Read up on SecPay or WorldPay and PSP's in general.

If you really want cheap 'n cheerful - consider PayPals

JKMitchell

5+ Year Member



 
Msg#: 10994 posted 3:00 pm on Feb 17, 2006 (gmt 0)

You may even find that the merchant agreement your client has with his card processor (bank) says that this is not allowed.

rocknbil

WebmasterWorld Senior Member rocknbil us a WebmasterWorld Top Contributor of All Time 5+ Year Member



 
Msg#: 10994 posted 7:55 pm on Feb 17, 2006 (gmt 0)

So what they have asked for is a form that people can fill out with their order details and credit card information then send the form results to an email address.

Hundreds of times I'm asked this. Here is how I present it to them:

Even if you submit this information on a secure server, once that data is passed to email it is NOT secure. A hacker will "scan" server ports, basically "listening in" and logging any data that passes through. If one of your orders happens to get picked up, that credit card is now compromised and guess what - you are liable. So by trying to save money and time, you're risking everything.

Add to this that most "free" email processors out there are filled with security flaws that give theives another point of attack.

GPG/PGP email is a GREAT solution but if someone's asking for the CC info to come to them in email, I can assure you setting up and using public and private encryption keys is going to be far beyond their ability.

ronburk

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 10994 posted 8:26 pm on Feb 17, 2006 (gmt 0)

how do I get this senstive information from the customer to the business in a secure and cost effective way?

Store the information, encrypted, in a database (where "database" might be as simple as a series of encrypted files in a directory, depending on your needs). Provide a passworded, HTTPS interface to the database so that employees can process and delete the information. Feel free to email them notifications that new orders have arrived. Feel free to email statistics that do not include sensitive information to an onsite database.

That will make you about as secure as 95% of small businesses who process their own CC info coming in via a website.

A hacker will "scan" server ports, basically "listening in" and logging any data that passes through.

Incorrect and irrelevant all at the same time. If you've got a hacker who can log all the packets for your server, you better get that looked at real quick :-)

JollyK

10+ Year Member



 
Msg#: 10994 posted 8:45 pm on Feb 17, 2006 (gmt 0)

Store the information, encrypted, in a database (where "database" might be as simple as a series of encrypted files in a directory, depending on your needs). Provide a passworded, HTTPS interface to the database so that employees can process and delete the information. Feel free to email them notifications that new orders have arrived. Feel free to email statistics that do not include sensitive information to an onsite database.

Pretty much what we've done as well in similar situations. I don't like it as much as I might other solutions, but LOADS better than emailing cc data.

Incorrect and irrelevant all at the same time. If you've got a hacker who can log all the packets for your server, you better get that looked at real quick :-)

Aw, be nice. There's a difference between a "trojan" and a "worm" and a "virus," but the only word I use when talking to my mom is "virus" because she just doesn't get the others. :-)

On most shared hosting services I've seen, someone could set up a sniffer pretty easily to capture everything coming in on the ethernet interface(s). I think it's fair to say "a hacker will scan server ports ... listening in ... and logging."

:-)

JK

DrDoc

WebmasterWorld Senior Member drdoc us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 10994 posted 8:45 pm on Feb 17, 2006 (gmt 0)

First, remember that the CVV/CVV2 codes cannot be included in the email (or stored anywhere, for that matter).
Second, wouldn't it be better to include contact information (such as a phone number) and verify the credit card info over the phone?

Harvs

10+ Year Member



 
Msg#: 10994 posted 10:30 pm on Feb 17, 2006 (gmt 0)

Thanks for all the suggestions.

I think I will have to go with ronburk's suggestion of storing them in a database and then notifying the business via email.

In all likelyhood the information will only be on the server for a very short amount of time before someones processes the card and deletes the information. As I stated before there will only be a very small amount of sales (3 or 4 a week) using this system.

Demaestro

WebmasterWorld Senior Member demaestro us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 10994 posted 10:31 pm on Feb 17, 2006 (gmt 0)

I think you are making a mistake storing them.

Once you store them in the db then is the form that the sales people use to retrieves the data so they can complete the transaction going to be behind SSL? It better be. And only doing 3-4 sales a week is not a reason to keep them in a db. Is it ok if only 3 people's CC get maxed out because of unsecured data transfer?

Also don't forget when a sales person brings up the CC info to fulfill the order that the form data may be saved by the browsers cache and may end up in the drop down history of text boxes. And will they be in the brswer cache itself? YES! Unencyped? YES!

Don't do it. Just don't it is the wrong way to do it. It is just wrong. I don't want my CC in someones office computers browser cache history.

Also don't forget what your privacy policy would have to state. And as mentioned above you may be violating some agreement with your credit card transaction company.

The fact is if you want to do this you want to be able to tell your client that for no reason do you store their credit card info. And there is not reason you should be storing it.

If they want a cheap and dirty way of doing it then have them submit an order with no payment info then give them a 1-800 number to fulfill the order by phone to give their CC info. Store there order in the db and when they phone in the the order number call it up and complete the order by phone.

That is the cheap and dirty way.

As a sophiticated user I would never submit my credit card if the sites policy states that for one reason or another they will be storing my card info electronically.

LifeinAsia

WebmasterWorld Administrator lifeinasia us a WebmasterWorld Top Contributor of All Time 5+ Year Member



 
Msg#: 10994 posted 11:05 pm on Feb 17, 2006 (gmt 0)

As a sophiticated user I would never submit my credit card if the sites policy states that for one reason or another they will be storing my card info electronically.

So you don't shop at Amazon?

physics

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 10994 posted 11:33 pm on Feb 17, 2006 (gmt 0)

The best thing to do is to get a payment gateway (with e.g. Authorize.net) and then you can send the card info directly to the online processor for verification. Note that PayPal also offers payment gateway services now in addition to the standard methods (though I haven't used them):
[paypal.com...]
So basically people can pay with a credit card even though they don't have a PayPal account.

ronburk

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 10994 posted 12:41 am on Feb 20, 2006 (gmt 0)

I don't want my CC in someones office computers browser cache history.

Then you cannot shop online. You must be envisioning some kind of fantasy world where CC transactions never have to be examined manually by human beans. Sorry, you can use PayPal or whatever you like, but there's always a certain percentage of transactions that end up involving a human. That percentage is never zero. I guarantee you that the PayPal employees involved in that task are doing it electronically.

As a sophiticated user I would never submit my credit card if the sites policy states that for one reason or another they will be storing my card info electronically.

Ah, you prefer to shop at sites that lie rather than those that tell the truth. There are many available for your shopping pleasure.

If you're going to do your own CC transactions (e.g., get a merchant account, as thousands of small businesses do), then you're going to store card info electronically. How do you figure merchants handle chargebacks, refunds, reconciliation, etc. -- scribble card numbers on post-its that they stick on the wall for 90 days?

People are superstitious about what they don't understand. Thus, we have people worried about their CC information residing in some merchant's browser cache, but not the least bit worried when they hand their credit card to a minimum-wage waiter who looks like a meth addict (or better yet, shows their debit card number to the teenage cashier and then punches in their PIN in plain site of same).

If you shop online regularly with a credit card, then your CC number is already residing on hard disks around the nation -- often completely unencrypted. Just bothering to encrypt the info before it makes it to disk will put this developer ahead of many of the folks you do business with. (As usual Amazon is at the top of the game here, at least if you believe their claim of piping the CC info into a secure machine that uses a custom protocol and does independent checks for suspicious requests. But of course, they still have to store CC info on disk, and they still have to be able to manually inspect it when things go wrong.)

BeeDeeDubbleU

WebmasterWorld Senior Member beedeedubbleu us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 10994 posted 9:48 am on Feb 20, 2006 (gmt 0)

If the business model would support it have you thought about using Paypal Invoicing? This would allow the customer to place the order without submitting credit card details. Your client could then send them Paypal invoices. (Google it)

Harvs

10+ Year Member



 
Msg#: 10994 posted 10:49 am on Feb 20, 2006 (gmt 0)

BeeDeeDubbleU, I had a look at the Paypal Invoicing that you suggested and I don't think it could really sell that sort of idea to this customer.

The idea behind creating this online payment system is to make the process of purchasing products easy. If after placing an order the customer then needs to receive an invoice, follow payment instructions and then transfer money it seems a bit counter effective.

Plus there is the extra cost of using Paypal for each of the payments received. As much as I understand the need for securtiy it is hard sometimes to convince a small business owner to spends hundreds on development or 4% per transaction on something as untangable as security.

Has anyone ever had first hand experience with being on the wrong end of legal action when it came to site security?

john_k

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 10994 posted 2:20 pm on Feb 20, 2006 (gmt 0)

Our system doesn't store CC data - and I am surprised at the number of customers that are surprised that we can't simply pull up their CC data from an old order.

As JKMitchell pointed out, if your client doesn't have a merchant account that specifically allows internet transactions, then they are leaving themselves open to some hurt from the bank.

This whole topic is why I use virtual CC numbers when I shop online. Each one is only valid through the end of next month and they are only valid with one merchant.

swones

10+ Year Member



 
Msg#: 10994 posted 2:37 pm on Feb 20, 2006 (gmt 0)

>First, remember that the CVV/CVV2 codes cannot be included in the email (or stored anywhere, for that matter).

That's not always strictly true, as I understand it you must not keep a permanent record of them along with the card details, however it is reasonable to have them recorded either on paper or whatever for as long as it takes to process the transaction. As long as you securely destroy them after you have taken payment then that is acceptable. I have had this confirmed to me by my payment processor, however I'm in the UK and things might be different where you are so always check.

Simon.

Sarvesh

5+ Year Member



 
Msg#: 10994 posted 3:09 pm on Feb 20, 2006 (gmt 0)

- Store starting 4 digits and ending 4 digits along with expiration date, CVV/CVV2 (if required) in encrypted database.
- Email middle 8 digits of credit card via email to authorized business partner (Use POP3 with Message Delete after Downloading).

This method makes sure that your data is spread over 2 networks and thus chances of hacking go further down. Of course, there is overhead but with 3 or 4 orders per week it should be ok.

This is not a substitute to Internet Merchant account but a work around while you want to process cards offline.

wheel

WebmasterWorld Senior Member wheel us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 10994 posted 3:44 pm on Feb 20, 2006 (gmt 0)

Yikes! Do not store credit card information on your server. I mean, are you that confident that the security on your server is such that there's no way someone could get at what is probably just a flat text file of credit card numbers stored on your server?

Best way is to use a payment processor. It costs a few bucks, but that way you're pretty much off the hook.

I played with OScommerce a while back and I think what they do is split the card number, email half and store the other half. Not my idea of high security.

If you're accessing them through an https connection, then the card number will be secure from the consumer to your server, and from the server to the vendor when they do a lookup. But you've still got the issue of storing it unencryted on your server....very bad. And even then you'd better make sure that apache is set up so that the vendor can't access the page through a regular http connection.

In short, really the only way that I see to do this is to bite the bullet and get a payment gateway. I really don't think they're that expensive these days. Like what, $25 a month maybe?

jwolthuis

WebmasterWorld Senior Member 5+ Year Member



 
Msg#: 10994 posted 3:50 pm on Feb 20, 2006 (gmt 0)

... scribble card numbers on post-its that they stick on the wall for 90 days?

With PayPal Website Payments Pro, there is no need to store the customers' CC number, expiration date, or CVV. PayPal (via the issuing bank, AmEx or Discover) authorizes the transaction using a digitally-signed, encrypted SOAP transaction. They hand back a "transaction number", and a "approved/declined" indicator.

Using this "transaction number" I can completely capture, partially capture, completely refund, partially refund, or void the authorization up to 30 days later.

No need to store CC info on my server.

notsleepy

10+ Year Member



 
Msg#: 10994 posted 3:51 pm on Feb 20, 2006 (gmt 0)

Use a payment gateway like Authorize.net. Don't store the CC info. You simply send it to A.net. They store it for you. If you ever need to issue a refund its there for you. Simple. Easy. Fairly secure.

Noname_Nick

5+ Year Member



 
Msg#: 10994 posted 4:23 pm on Feb 20, 2006 (gmt 0)

Harvs, go with RonBurks suggestion. I thank that has to be the easiest way to make it work with a very small business. Just give them the password and force it through ssl.

You could write a small custom app that transfers them over an encrypted channel (encrypted remoting), but that will most likely be more work.

I'd be very interested in hearing how other people with large distributions (i.e. sending cc's to thousands of computer illiterate businesses around the world) make it work. What I've come up with definitely isn't fully secure, but it works.

Rodney

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 10994 posted 5:00 pm on Feb 20, 2006 (gmt 0)

Use a payment gateway like Authorize.net. Don't store the CC info. You simply send it to A.net. They store it for you. If you ever need to issue a refund its there for you. Simple.

I process a lot of credit card transactions and this is definitely the most secure way.

Use a credit card payment gateway like authorizenet or linkpoint and a secure order form on your site that interacts with the gateway.

The customer visits your secure order form, enters their payment details, clicks ORDER and at that very second, the data is electronically sent via the authorize or linkpoint gateway to the customer's bank to verify that the funds are available. No payment data is stored on your server.

If the funds are available, the customer gets a thank you message that the order is processed. If the funds aren't available or if the customer entered the payment information correctly, they get an error message in realtime that shows them what went wrong.

Once the transaction is successful, you get an email notifying you of the successful payment (with no credit card details in the email). That lets you know you can ship the order because the funds have already been verified.

The normal way this works is that you do an "authorization" at the time of purchase. This just verifies that the funds are available and holds them for you until you ship the merchandise.

Once the merchandise is shipped, you login to your payment gateway and mark the order as "shipped" and this converts the authorization to a "sale" and the funds get sent to your bank account in a few days.

If you never ship the merchandise, the authorization will "fall off" the customers bank so they can use the funds again.

incrediBILL

WebmasterWorld Administrator incredibill us a WebmasterWorld Top Contributor of All Time 5+ Year Member Top Contributors Of The Month



 
Msg#: 10994 posted 6:29 pm on Feb 20, 2006 (gmt 0)

You can use any free ecommerce system that stores encrypted credit cards on the server for later secure access via SSL.

Sending CC's via email can cost them their merchant account as Visa/MC/etc. have a zero tolerance policy for such nonsense plus some real hefty fines so I'd advise them against such an ill-fated concept.

Not to mention that people like me will report them, and have done so, when we stumble across email forms that ask for credit cards as companies doing business haphazardly like that tarnish ecommerce and make it more difficult for the rest of us.

sun818

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 10994 posted 6:36 pm on Feb 20, 2006 (gmt 0)

For what its worth, when I first started out - I used Mal's eCommerce (free version) which allowed me to capture credit card numbers for manual processing. I'd log into ProPay (no annual at the time) and key it in manually. I had access to the credit card numbers for 90 days online - all done over HTTPS (SSL). At the time they did not offer it, but you could also use the paid version of Mal's eCommerce and upgrade to their pay service which supports Paypal Website Payment Pro.

Whether you have a merchant account with a bank or using Paypal, if you aggregate the four credit cards, 4% or more per transaction (fees / gross) is normal. If you process a lot more Discover or American Express, Paypal is definitely the better deal due to their flat rate pricing for all cards.

aspdaddy

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 10994 posted 6:43 pm on Feb 20, 2006 (gmt 0)

You dont need to be overly paranoid with this, just read your merchant agreement or if you dont have one use a brand like paypal/worldpay. Most banks are fine with using SSL/128bit encrytion.

If you start re-inventing the wheel and try to do some custom encryption/storage of finacial data you are likely to get sued.

twist

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 10994 posted 8:23 pm on Feb 20, 2006 (gmt 0)

Sorry if this has already been mentioned but have you thought about using an Amazon merchant account? I don't have one, but I read a little about it once and it looked like a good option.

They have teams of people working on security, if something happens, they take the blame. People who already have Amazon one-click accounts can buy your products from your website with one click of a button. They handle returns, chargebacks, and the works. They probably take a decent cut but think about the amount of overhead you'll save, especially since your talking about 3-4 sales a week.

Harvs

10+ Year Member



 
Msg#: 10994 posted 10:11 pm on Feb 20, 2006 (gmt 0)

I had a good look at Authorize.net and I really like the way that it operates. This will allow me to code my own interface and have them handle all the security issues which is exactly what I wanted.

The only thing I couldn't find on the site was prices and because I'm in Australia there are no resellers here. I will send an email off to them and see what I get back. I will also have a look and try and find a similar company in Australia that sells the same service.

Thanks for the tips!

duckhunter

10+ Year Member



 
Msg#: 10994 posted 12:34 pm on Feb 21, 2006 (gmt 0)

So many people are saying not to store CC info in the DB.

How are any of you conducting returns/credits/refunds without a CC number?

Even Lowes/Home Depot these days don't need your card to issue back a credit. Just the receipt.

For those of you that need to store it (like most true e-com companies) be sure to encrypt it with Blowfish, or something of the like, before storing it. That way the DB without the Decryption routine is useless to a hacker. Granted if the hacker gets to the DB, he can probably get to the webserver too ;)

LifeinAsia

WebmasterWorld Administrator lifeinasia us a WebmasterWorld Top Contributor of All Time 5+ Year Member



 
Msg#: 10994 posted 4:44 pm on Feb 21, 2006 (gmt 0)

So many people are saying not to store CC info in the DB.

Visa/MasterCard security procedures DO allow for storing CC info (but not CVV info), as long as proper security procedures (firewalls, segmented access, updates of virus definitions and system updates, etc.) are followed.

I think what people may mean is that you should not store the CC info on a publicly accessible DB. If you are going to store it in your own DB, the DB should reside behind a firewall and not be accessible from the public web site.

At first blush that sounds illogical- after all, if it's not accessible from the web, how do you get the info to the DB in the first place? Ah, Grasshopper, you give write access, but not read access, to the web application. Make read access only available from behind the firewall.

For the newbie who doesn't understand all the technical requirements or have the money to invest in the proper H/W & S/W, then local storage is obviously NOT recommended.

incrediBILL

WebmasterWorld Administrator incredibill us a WebmasterWorld Top Contributor of All Time 5+ Year Member Top Contributors Of The Month



 
Msg#: 10994 posted 9:53 pm on Feb 21, 2006 (gmt 0)

So many people are saying not to store CC info in the DB.

As long as it's highly encrypted (never plain text) and secure, and only accessed via HTTPS it's not a big deal but you're better off letting your payment gateway deal with the transaction and you just store whether it was ACCEPTED or DECLINED.

How are any of you conducting returns/credits/refunds without a CC number?

My payment processing company has an admin control panel and/or API where you can do this using the authorization or transaction number only. They are audited verified to be secure and they hold the CC #s so I don't have to worry about it.

For those of you that need to store it (like most true e-com companies) be sure to encrypt it with Blowfish, or something of the like, before storing it. That way the DB without the Decryption routine is useless to a hacker. Granted if the hacker gets to the DB, he can probably get to the webserver too

The safest way of decrypting the orders is to download them and decrypt them locally as hackers that get into ecommerce servers install (if possible) little scripts that email your decryption password and then they come back and decrypt them all.

Seen it happen muliple times on servers that weren't maintained well, cheap web hosting and not my sites, it's not pretty, which is why I *DO NOT* recommend storing or decrypting credit cards on a server whatsoever as it's just a carrot being dangled taunting the hacker to try until they get the loot.

If you must store CCs on the server purge them the minute the transaction is completed on a daily basis which greatly limits your exposure to theft.

FWIW, think of ecommerce hackers more in the organized crime areas these days as it's low hanging low risk fruit if they can get it. They order a ton of merchandise from all sorts of places and have it shipped to all sorts of locations, then collect it and fence it on the black market.

P.S. Change your ecommerce encryption code and password regularly like once a week and keep an eye on the code in your server that decrypts passwords for a sudden date change.

This 37 message thread spans 2 pages: 37 ( [1] 2 > >
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / WebmasterWorld / Webmaster General
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved