0

I have been recently hired by an event-planning company to create a web application that will allow online payment for specific events and keep a list of registrants. My employers are asking for a documentation of the project's specifications/requirements before I can start coding the application to make sure I fully understand the idea behind this project to minimize the risk of error while working towards the final product.

This is my first time working with Paypal, Caledon and other online payment processors and I realize that I need to have a very secure database, as critical information is to be retained in the servers (i.e. the last four digits of the credit card used for payment).

I know that the following is good practice:

  • Keep the database on an independent machine (away from the webserver) and access it only when needed;
  • Secure the database behind a firewall;
  • Create long and "hard-to-guess" passwords for the root user and the users who will be accessing the database for maintenance/administration.

Aside from that, I do not know what else I could do to secure the database even more. Microsoft SQL 2005/2008 will be used to build the database.

Any tips/suggestions on how I should proceed with this?

Thank you in advance,

-Christopher

Christopher Richa
  • 113
  • 5

3 Answers3

2

The definitive guide for online credit card processing is the Payment Card Industry PCIDSS standard: https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml All of the things on your list (and much, much more) are in that document.

Doing it right is a lot of work, are you sure there isn't a already written app/service that will meet the client's needs?

mfarver
  • 2,576
  • 13
  • 16
  • I am certain there is some sort of similar written app/service out there that could do the job, but the company wants their software/apps to be developed in-house. – Christopher Richa Oct 01 '10 at 17:58
  • Plus, with what you just told me, I doubt that thirty-or-so hours is enough to do this right. – Christopher Richa Oct 01 '10 at 17:59
  • 30 hours is gonna be tough to do well. You can shortcut all of that crap by using the "Hosted Order Page" feature of your payment processor. This is one of the few advantages of Paypal, their default system requires the user to do all of the payment site on their approved webserver, your server never touches credit card data, so the security requirements are much more reasonable. – mfarver Oct 01 '10 at 18:03
  • Good thing that they'll let me work on it as much as needed: they'll just charge me thirty hours. As for the hosted order page, it's great but it's not within their requirements: they want the payment forms to be custom and, by using an algorithm, to detect what card the person is using to use the right "pre-assigned" processor. I know it may not make much sense. I might update my question to reflect this factor, although I do not know whether it is related to database security... – Christopher Richa Oct 01 '10 at 19:06
1

I'd consider:

mike42
  • 86
  • 7
  • Won't disabling SQL logins affect my coding? – Christopher Richa Oct 01 '10 at 18:00
  • Not as long as you have an AD account that has the proper permissions assigned to the DB -- look into SSPI authentication. However, you should probably have a separate development DB once your production site is up and running, so you'd have permissions to that instead. – nedm Oct 01 '10 at 21:32
1

First thin to do is check the local laws applying to where both the business and the server(s) are located. I was surprised to learn that where I am we are not allowed to keep any credit card details on record (on the server, printouts, etc.), not even a partial number.

Not just the root account but all accounts on the server need decent passwords. The root account shouldn't even be accessible remotely. It should only be used locally on the server by logging on as a "normal" user and issuing commands via sudo or su. I also like the idea of making the logon names as hard to guess as the passwords. Not just those accounts used to access the data but any and all accounts that can be logged on remotely, as this will help slow down brute force attacks.

I can't comment on MS SQL as I don't use it but the most important point to bear in mind, especially with anything Internet facing, is the Principle of Least Access. In other words, only grant the absolute minimum access required by any user or function.

John Gardeniers
  • 27,262
  • 12
  • 53
  • 108
  • WHen you speak of the Principle of Least Access, do you also include the root account in all this? – Christopher Richa Oct 03 '10 at 14:43
  • @Christopher - Yes, at least as far as practical. Because it's not generally viable to actually restrict the rights of the root account itself, access to the account itself must be restricted, both in regards to who can use it and from where. – John Gardeniers Oct 03 '10 at 20:33