Security

[contra]

Im almost through designing a low traffic e-comms site for a company in Europe, i`ll be using mySQL and PHP of course. My main concerns are that the only applicable method by which they can process their orders is manually via the web - that is, they log in to a web database front-end i'm writing, view the days orders then process them (and the transactions) by hand/phone. The database will store CC numbers and other such personal information. My armoury (!) at this time is secure (SSL) server, firewalls, PHP sessions and password gateways (PHP hard-coded and htpasswd).
The potential for a security compromise is giving me endless headaches! Is there anything else I can do ?

[crislewis]

Hmmmm, I remember that feeling.

I have done many things to help out here - although I now let someone else worry about it as a managed service with penalty based SLA.

The things I did when I could afford to do nothing but do it myself were:

CC numbers were hashed into the database
cc details and personal details were separated into seperate dbs foriegn keys into the cc db were generated on the fly so that there was NEVER a clear relationship between the two.

When I used to handle all cc trans offline (not doing enough busniess to get a decent trans charge from the thieving so and so's who hold the world to ransome) I simply stored trans details on-line but cc details were offlined and never stored on-line.

Hope (some of) this helps.

Cheers,

Cris

[[deleted]]

The trouble with CC numbers is that you need to be able to read them yourself. Unlike passwords, you can't use md5() to encrypt them.

What you can do however, is make sure that
no criminals can get theyr hands on your data.
By far the simplest method is the firewall.
Put your DB and Webserver behind a firewall and only allow WEB (HTTP/HTTPS) through to the webserver. That pretty much makes it impossible to gain aggess to the database server.

If you feel even more paranoid you can store the CC details in a seperate table that only you as a user have password protected read-access to. (if you want to you can also limit the access to your particular PC)

That way the webserver can still write new CC details into the table, but it can't read them back. If a hacker did somehow manage to hack into your webserver, he still can't read the CC details from the database, not even if he hacked all the passwords and became root.

[Anon]

You should also guard against your own programmatic errors. OK, so this sounds obvious, but doing simple things like keeping the credit-card access inside a single module, where you make sure you do all the nice security checks and/or encryption at every access. Only access the DB using this module, never try and access the CC database directly.

Don't use generic scripts that you pass SQL statements to, which return the results of queries...don't let anything like that near your web servers.

Make sure any administration interfaces are not available on the same webservers, and access is only from behind your firewall.

Regards

Umair

[Anon]

Also try keeping the actual databasse access in some library not available via PHP and the web server, i.e. a C library or a perl library(not CGI). Used your PHP3 scripts to transfer the data, but not to access the database, that way someone from the outside can't run your database access scripts without putting a new PHP3 file on your web server.

Write a quite security audit script to flag when the files on your webserver change (name/mod date/permissions) when you are not using them.