Not storing credit card info in my database

am i safe or is there more to think about?

[Drumat5280]

It seems often that you hear about some major company having some hacker steal credit card info from their database. So, since i am a small guy i am not even going to attempt storing credit card info.

So am I still safe or is there more do think about?

I have an SSL certificate for when my customers enter their info. But what other things to I need to think about? How else could a hacker get at this info?

[jatar_k]

if you don't store it and all communication is encrypted over https then that is pretty good.

securing their member accounts (if they have them) is another step. Any information you store about your users must be secured as much as possible.

[FalseDawn]

The best way to make sure you are secure is to have a security consultant do a full audit of your entire operation.
Unfortunately, at $several thousand for even a small system, this is not usually an option.

It is good to see that you are not attempting to store CC details - so many people are blatantly ignorant of even basic security issues that I'm not surprised at the number of people who are weary of shopping online.

I would advise you to make sure you are running the latest versions of all scripts (shopping cart, bulletin boards etc), and try to find out as much as possible about potential vulnerabilities they might have.

Make sure you use strong passwords for everything - eg at least 10 characters, using a mixture of letters and numbers, no dictionary words etc.

If you are using something like oscommerce, make sure to lock down any admin or private directories with password protection. Don't put private directories in your robots.txt file.

If you are on shared hosting, make sure they are reputable and have secured each user into their own account (ie no access to any direcory above "home") and are using phpsuexec (if running php)

Also, a point a lot of people overlook is their actual home network - if you are transferring any customer data via FTP, you should be using SFTP.

Have a wireless home network? Make sure it is protected with WPA for example. Make sure your PC is clear from all spyware, keyloggers etc and re-check regularly.

Finally, keep an eye on your website(s) - check logs often for suspicious activity. You are likely to get a lot of "script kiddie" attacks - like looking for FrontPage files, awstats exploits etc - these can generally be ignored.

Vigilance is the key!

[Wlauzon]

Make sure you use strong passwords for everything - eg at least 10 characters, using a mixture of letters and numbers, no dictionary words etc.

Actually, this is almost always a BAD idea.

The reason is that nobody can remember those kind of passwords, so the first thing they do is write them down.

Many years ago I was a US Navy crypto technician (which required a top-secret+ clearance), and one of the things that the NSA people stressed in the security school was passwords and combinations for locks.

For passwords they recommended something that was totally illogical and nonsense - but could be remembered. something like "43badgertomatoes" or "aardvark81copper4"

Some people don't agree with that, but a while back some security firm did a survey of a wall street firm, and found that over 40% of the employees had passowords written down someplace at their desk...

It is just like most people worry about their credit card number online, and then toss the receipt with that number in the trash bin.

[henry0]

For those interested I will post in PHP
PHPsuexec seems to run on its end of dev
so suPHP seems to be the way to go

Regards

[adamnichols45]

regarding the passwords i have found that using at least a 7 letter word and then at least a four number combination on the end of the word has always been very secure.

just dont stick to birthdays etc

[LifeinAsia]

So, since i am a small guy i am not even going to attempt storing credit card info.

I have an SSL certificate for when my customers enter their info.

If people enter their credit card information, but you don't store it, where does the information go? What do you do with the information once the user hits the submit button? Are you passing it directly to your payment processor? Either that or you are storing it in a database, storing it to a flat file (shudder), or e-mailing the information to yourself (bigger shudder).

[jsinger]

The advice, too, is to change PWs every 3 months. Of course that further encourages the writing down of PWs.

[FalseDawn]

Actually, this is almost always a BAD idea.

You say this, then you give examples which back up my suggestion, with "43badgertomatoes" or "aardvark81copper4"

I didn't say use "random" passwords that are very hard to remember - just not single dictionary words. A combination of dictionary words is obviously less prone to defeat by brute force methods.

If anyone is stupid enough that they can't remember their passord without writing it down, then there's little hope for them anyway...

Using initials or memorable dates (not birthdates) in combination with various words is also acceptable

[jecasc]

Another hint for remembering passwords is to form a sentence and then use the first letters of each word. That way you can easily remember the password and it is very secure too.

"Speak friend and enter, you stupid dwarf.

Would be "Sfaeysd".

[Red_Eye]

I would look at encrypting any customer information you store in you database. This does add and overhead in terms of performace and storage but if someone does gain access to your db they can't just read the customer information. And don't store password in plain text encrypt them, the store them.

[Peter Cornstalk]

You should read PCI Security Audit Procedures and Reporting from Visa.

[Network_Pay]

Why not just encrypt the data in the database - it is easy enough to do. Most php programmers can do that pretty easily with a MySQL database. That would give you an extra level of security of someone managed to get in, they would find everything encrypted and woujld probably just move on to an easier target.