| 7:03 am on Feb 22, 2006 (gmt 0)|
We do big sites with Verisign and PayFlowPro.
We do the medium sized DB sites with the split CC#. Half is stored on server accessible only through SSL and password .htaccess, the other half emailed to client.
We do the small sites with SSL and PGP/GPG through email. PGP can be a pain to set up client-side, but it works. Clients print the packing slip and receipt to process order but CC# is not included. It is only displayed after entering PGP passphrase, then it is only displayed long enough to process the CC.
For returns, they all require phone calls to refund the money and then they get the CC# at that time, just long enough to process the refund.
| 8:41 am on Feb 22, 2006 (gmt 0)|
|A hacker will "scan" server ports, basically "listening in" and logging any data that passes through....Incorrect and irrelevant all at the same time. |
The original context of the question was that the customer wanted the credit card info delivered to them directly in a plain text email. Customers such as the one Harvs describes don't understand, they don't want to understand, and without insulting anyone's intelligence you need to have some level of ability to put it into terms they can digest. So what do you do, dazzle them with the technobabble of your superiority or come up with the plain and simple explanation that email is not a secure method of communication? Which do you think such a customer is going to understand?
|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. |
So tell me, how would you decrypt this data? A key in another file stored somewhere? By the mysql crypt method or something similar, whose salt must be retrieved from somewhere and in memory at runtime to decrypt? If someone gets into this server, they can access any stored encrypting salt or keys you may have so cleverly sought to hide, and once they figure out what lock they go to it's all over.
If you're storing anything sensitive with any method that is not PGP/GPG or similar and using a carefully guarded private key that is not stored on the server, you're liable, and it can happen.
| 4:46 pm on Feb 22, 2006 (gmt 0)|
|come up with the plain and simple explanation that email is not a secure method of communication |
Just explain that e-mailing CC info is forbidden by Visa/MasterCard (and probably AMEX/Discover as well- I just haven't read their specs) and that they will fine you thousands of dollars WHEN (not IF) they discover what you're doing. So never EVER send CC info in e-mail.
Don't dance around with details like encrypting the e-mail. Just tell them it's forbidden. Period. End of discussion.
| 8:09 pm on Feb 22, 2006 (gmt 0)|
No I don't shop at Amazon! As I said I will NOT give CC info if they are storing it.
I do not live in a fantasy world where humans need to bring up my CC info on a screen. Unless it is at one of the said payment gateways that everyone on here is telling people to use.
So many people are giving reason to store it in the DB and how it can be safe, no-one is address the forms that call that data to repopulate things to be read by humans. This is a big deal. If I stole your computer and start typing in a webform and a drop down box appears with the 100 last CC you looked at in it then lucky day for me. It isn't just about the DB being safe it is about the data being retrevable by a machine that simply has viewed the data. Anyone who has done data retieval from re-formated boxes will tell you what data can be found just because it was called to the screen.
I am sure that the big companies terminals are safer then Joe Blows terminal at some small company which may be in his basement. Seeing as I worked at one for 3 years designing webforms and interfacees and making sure that the default settings on the CC human processors cahce settings was set to not cache and to store 0 bytes of data.
Does that get it all?
No but at least the preform population doesn't return a bunch of CC numbers that were called into the form. Not to mention the secured area that the terminals lived requiring securty passes to access and all the goodies.
I would bet this years pay that what the original poster's computer, that will be grabbing the CC info to process manually has none of this. And that is the point here, if you aren't a data protection expert then you have no business storing anything CC related in a DB, or calling that data into forms on unprotected PCs. Especially webforms read by browsers.
In fact in some countries including the USA I would even wager that if you do, and CC info is harvested by someone who is looking for that stuff then you may be liable for being so careless with that data.
Is it worth saving a few bucks? NO! So don't do it. The original question is how do I do it in a cost effective manner and the answer is.
Have them call into a 1-800 number to complete their online order by giving their CC info over the phone and you punching it into your machine for auth. You cn store their order info in the db and call it up when they call in with some lookup number you email them
Get a western union account that people can transfer funds to and hold shipping until payments recieved.
| 1:07 am on Feb 23, 2006 (gmt 0)|
KA-CHING! <No Sale>
Personally I don't see why people want to know HOW to do it as it's been done solidly over and over in good free and paid ecommerce software.
Get something off the shelf and don't risk it, sheesh.
| 4:23 pm on Feb 23, 2006 (gmt 0)|
incrediBILL you are right, I wouldn't complete the sale under my 2 examples either, but I would do both those before I would give 'some guy' my CC number to store.
The fact is you want to do business over the Internet, so please do it right. This isn't like some joke where if something goes wrong then, "oh well"
Credit Card fraud is a massive problem in North America and the banks are just looking to pass off some of the blame/expense to other people.
Don't give them a reason to look to recoup $10,000 of fradulaent charges from your company because you were to cheap to take proper steps to ensure that no-one can steal that type of information from you. Trust me, that is a lot more expensive then paying ceridian or monaris a few bucks a month to do it right.
Do it right or tell the company that they aren't big enough to take this on yet if a simple transaction fee is too much for them to consider paying.
| 3:55 pm on Feb 24, 2006 (gmt 0)|
After the discussion that has been going on back on forth in this forum plus the conversations I've had with a few people in the industry I would have to say I'm much more security aware than I was before.
I didn't realise that companies such as Visa and Mastercard had it written into their merchant agreements that the credit card information be handled in a certain way. As a small business one thing you don't want is big companies like those coming after you because you decided to save a few dollars on your website development.
I guess in the end if you are going to operate a business either online or offline you have to accept that there are costs involved when it comes to setting up and running a company. I mean you wouldn't buy a shop front at the local shopping centre and not buy locks for the door would you? In the same regard you shouldn't really start up an online store if you can't afford the proper security procedures.
The real debate comes down to how much security is really enough. As an individual web developer, I can always give that responsibility over to a more qualified person (ie authorize.net) which will then alleviate me of any wrong doing and hopefully give my clients piece of mind as well.
| This 37 message thread spans 2 pages: < < 37 ( 1  ) |