eCommerce from the ground up

I want to build an eCommerce site what may be the security issues

[CIAimages]

I an working on buliding a eCommerce site from the ground up.What should be the security issues I have to take into considerations?

I use ASP to build the site, and I do write my codes by hand.

is their a good incryption system easy to implement? if yes which one?

Thanks for possible help.

[edited by: TallTroll at 10:35 am (utc) on Feb. 9, 2004]
[edit reason] tidy up [/edit]

[cashmere]

I would say - consider using a vendor to run the cart backend.

If you want to do it, you can use PGP/GPG to encrypt orders, store them and transmit them with something called XML-RPC, or even email. I have built a checkout which encrypts cc number with RSA algorithm, which is a public key method also. Or just use a verifier API and instantly transmit cc info to them. Of course in any case the pages where data is entered should be SSL.

[Jummna]

The webpage end should of course be SSL.

At the webserver end, if you're going to host the accounts on server (e.g. an SQL database or whatever) then take a look at a similar thread just started:

"Credit Card / Database Security":
[webmasterworld.com...]

on the issues of holding CC data on the server and specifically, on a *shared* server. This will likely be the case if you want to maintain customer information at the server so that customers can login and review their account, etc. a bit like Amazon or whatever.

Alternatively, you can encrypt the order and CC data using public key encryption (PGP/GPG with only the public keys held on the server) and email them back to your office where you decrypt them and process them man ually or via some bespoke software.

The business I work for, which handles a small number of web orders (e.g. 10 or so a day) uses the latter. It has the advantage that nothing is stored on the ISP's server and details are held only locally. The downside is that we don't/can't maintain customer information at the server and this means that we have to allocate customers a customer number that identifies an incoming order to their records on the database.

Have a search through the other topics on here as this has been discussed before.

Paul

[badtzmaru]

Just don't store the customer's credit card numbers at all. Having everything pre-populated, including expiration date, for a repeat customer and only requiring them to enter the CC number shouldn't make a difference. In addition, in some cases, storing the credit card numbers in a database is a violation of the merchant agreement.

Remember to encrypt the CC number as soon as your code receives it from the form post. That will reduce the likelihood that the CC number will show up in any sort of log files or core dump files.