Mark,
Here's a couple of tips which may be worth considering. I don't consider
myself a security expert so perhaps others on the list may agree/disagree
with some of these suggestions.
1) If possible, seperate the Database from the Web-server. Then use IPX/SPX
on the Web server to connect to the SQL Server machine. You can then add a
blocking filter on your router to block all incoming and outgoing IPX
traffic and make sure IPX is not set up on any proxies/firewalls. If set up
correctly this should pretty much eliminate any traffic directly to the
database except from your Web-server. If possible use non-routable IP
numbers on your LAN (some thing like 192.168.x.x) and use NAT (Network
Address Translation) on your router. This makes IP spoofing much more
difficult for a hacker. IP bans are only useful if a hacker is unable to
spoof their IP address. Also if the external IP number a hacker see's is
different to the IP address range in use on your LAN, it makes it
considerably harder to a hacker to scan ports on your network.Have a look at
Steve Gibsons "Shields Up" web-site http://www.grc.com
2) Remove all rights from the tables you wish to use for storing the numbers
and use stored procedures. This means that users can't link to the tables
from an ODBC product like Access and read/modify tables.
3) If you are going to separate your CC numbers by splitting the first 12
digits from the checksum, you could create a "View" of your UserID and 4
digit fields and give a stored procedure select rights only to this View.
4) Use a stored procedure with Insert rights only when first creating the
record. The script for collecting the CC number should use SSL.
5) Once a user has entered their number,never show them the first 12 digits
again, sounds obvious but you would be amazed by the silly things people do.
6) Finally some "in-house" processes will need to read CC numbers for
processing. Place any scripts which have Select rights on the first 12
digits in a separate virtual folder. Make these scripts read-only and place
an IP ban on them (only allow 1 or two machines on the LAN to have access to
them). If you are using your own scripts for CC processing and not a bought
in solution, add NT security to these scripts.
I hope I haven't gone over the top here. I also have a doc that I got from
the MS web-site called "Authentication and Security for Internet
Developers". Mail me if you would like a copy. Bit of a joke MS lecturing on
security when there products have been riddled with security holes.
Regards
Michael O'Reilly
TransAer
-----Original Message-----
From: Dan O'Keefe [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 22, 2000 7:21 PM
To: [EMAIL PROTECTED]
Subject: RE: Stored Credit Card Numbers. Best practice.
One thing that we have done in the past is to split the number into two
different tables, both encrypted. The first table, had the last 4 digits,
and would be displayed to the customer like:
**** **** **** 3456
And prompt them to enter the first 11 or 12 (AMEX or Non-AMEX). Then the
Java servlet for ClearCommerce would retrieve the 11 or 12 digits from the
2nd table, decrypt it, and match it to what the customer had.
You can implement any variance of this you like, as this type of situation
also helps with unnecessary viewing by employees who do not need access to
that info.
------------------------------------------
Dan O'Keefe
TriPoint Technologies
[EMAIL PROTECTED]
954.501.3113
|-----Original Message-----
|From: Mark W. Breneman [mailto:[EMAIL PROTECTED]]
|Sent: Monday, August 21, 2000 9:14 AM
|To: [EMAIL PROTECTED]
|Subject: Stored Credit Card Numbers. Best practice.
|
|
|
|I know the first tip I will hear is don't store CC numbers. But, in this
|case I have to store CC numbers. So, I am looking for any tips I
|can get on
|storing CC numbers.
|
|Lets start off by assuming the "client" info will be stored in one database
|and their CC numbers in another. In this case both on the same MS SQL
|server. Currently I am encoding the CC numbers with (CF) Encrypt. As I
|understand this encryption can be broken with a "hacking" tool. And with
|all the Microsoft bugs in IIS regarding viewing the source code. The (CF)
|encrypt key in it is not very safe to begin with.
|
|So, I am looking for a better method of encrypting my CC numbers. Perhaps
|MS SQL server can encode a field value? Any ideas, tips?
|
|Also, do I bother encrypting the relation ship id number between the two
|databases? (client info and client CC number)
|
|Any tips or ideas on database design or MS SQL encoding stored procs are
|welcome...
|
|
|Thanks
|
|Mark W. Breneman
|-Cold Fusion Developer
|-Network Administrator
| Vivid Media
| [EMAIL PROTECTED]
| www.vividmedia.com
| 608.270.9770
|
|-------------------------------------------------------------------
|-----------
|Archives: http://www.mail-archive.com/[email protected]/
|To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
----------------------------------------------------------------------------
--
Archives: http://www.mail-archive.com/[email protected]/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/[email protected]/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
