embedded response
"Tony Gravagno" <address.is.in.posts@[EMAIL PROTECTED]
> wrote in
message news:6l5tt3hiki3a99gr3f3vgbe3rukno72qm7@[EMAIL PROTECTED]
> Misc thoughts...
>
> mark.fuller wrote:
>>Peter, It doesn't matter how secure the passwords to your MV system
>>are, if the credit card information is not encrypted on disk then it's
>>very easy to get to it!
>
> There are a some rules of thumb to follow with credit cards.
> 1) Don't store the numbers together or in one place. Take the 12
> digits, break them up and put them in different files. This way the
> data can't be compromised outside of the context of the running
> application.
Interesting idea, actually there are 16
> 2) Encrypt the data. If the data is broken up then heavy encryption
> isn't required.
The point of my query, are the encryption algorithms worth a pinch of salt
if one can buy the crackers referred to. NB cracking a password is no
different to carcking any other data
> 3) Never store the track data from scans or the Card Verification
> Value Code (CVV2, CVC2, CVV2, CID, CCID, CSC, ) on the system. This
> is forbidden by some card issuers for specific countries. The CVV
> data shouldn't even be written down by people taking orders.
I think that this needs some analysis of methods as it is impossible to
follow. It can only work where the value of the order is known at the
time
and the order is being taken over the telephone by a person directly
connected to the bank. Personally I can see many cases where this is not
so. In my system (which does not store CVV as it is rarely required in
Australia) a person will request a tank fill be it petrol, diesel, heating
oil whatever, when the driver returns the invoice is keyed in and then
when
the bill is due to be paid (typically 7 or 30 days) we prepare a file for
transfer to the bank. Interestingly enough the bank requires this
information to be transferred in open ASCII flat file format. This has
resulted in some hilarious audit requirements never mind the good old
SoreBones et al. One very large American company required the bank
connection PC to be unconnected to any network and locked in an office.
Ahhah! how does the information get transferred you say, obviously you get
a
junior clerk to copy the plain text flat file to a floppy and use sneaker
net to deliver it to the secure office :-) This is a true story.
Personally when booking hotels in Europe I have been required to fax the
data to hotels who then use other facilities to bill me. I often use
words
rather than numbers to try and reduce the risk so 5353 becomes five three
five three but if the person at the other end files it!
> 4) If your system allows for manual key entry of data when the swipe
> doesn't work, track the usage of key entry and identify equipment,
> locations, and people where incidence of keying is out of the norm -
> then fix the problem.
Utterly impossible in a small company as the norm is everybody does it and
many NCP situations do not have swipe machines.
> 5) If your application accepts credit cards, put a flag/datestamp in
> the customer master that can be set when a customer calls with
> suspicion or complaint about card use. Periodically (nightly
> re****ting?) generate a count of calls across the customer base where
> inquiries are made about cards. If the incidence rate goes up a
> trigger should be activated for management. Use different metrics to
> identify short-term and longer-term increases in customer inquiries,
> and of course balance this with increased sales or customer counts.
Again this is only an internal check that is bound to fail when the party
involved takes the call.
> 6) Do not use ROT13 and call it encryption. That code was broken over
> 3000 years ago. (Like Mark said though, if you watch History Channel
> or Discovery, there have been some very good encryption techniques
> handed down from ancient times and it's helpful to look back before
> writing algorithms from scratch.)
>
>> There are various techniques to accomplish
>>encryption including host level add ons, hardware encryption etc.
I wanted to know what does work and if the standard encryption used by QM
and or D3 and others is suitable.
>
> 7) Try to avoid this:
> EXECUTE "!os.cmd.for.transaction ":CARD.INFO CAPTURING OUT
> A simple PS command at the OS level will show all the data. If you do
> that, encrypt the data so that the OS-level process needs to decrypt
> it before processing.
> 8) Similarly, avoid this:
> EXECUTE "!openssl ":CARD.INFO CAPTURING OUT
> Sure, it's nice to use standard tools for encryption but the benefit
> is compromised if the data is too easily visible in transit.
In fact the use of EXECUTE is essential if one is to use the available
standard programs outside of MV and this is the least likely area of
intrusion as it requires on the spot system intervention by a system
programmer who could achieve the same thing a thousand other ways.
>
>
> When I need basic encryption I will use a custom routine that makes
> use of a combination of bit/byte ****fting, ROTnnn, and several other
> (sometimes ancient) techniques. I then encrypt an ID for the
> algorithm itself into the data. Then the algorithm is locked, never
> to be changed again. When I get a piece of data with a certain
> algorithm code, I know the routine that needs to be used to decrypt
> it. When I retire an algorithm or come up with improvements I just
> use a new code. Someone may be able to break an algorithm but if
> there are more than one being used then the risks are reduced.
I hope that you have a really good way of ensuring that you can always
recover the data files when you have to go back to an archive. I wonder
where you store the information that says which algorithm was used.
>
> We do have the advantage of some security through obscurity - even if
> some bad guy does get a disk with an MV database, he probably won't
> know what to do with the data because it doesn't conform to structures
> found in more common environments. If the data elements have just
> some basic encryption, those elements are obscured even further among
> bits of data that represent MV data structures, and it would be tough
> to tell what's DBMS from object code from data, etc.
"security through obscurity" I am sure IBM U2 with 40% of the companies
database clients in MV might be a tad miffed at this statement. However
getting customers to agree to encrypt in the first place is a more
difficult
hurdle.
Peter McMurray
> T
>
|
