Credit Card Details

[Griff]

If sensitive information (such as a credit card) has to be saved to a
database then there is a duty of care to protect this information.

If the data is saved in plain text, then there is a concern that a hacker
gaining access to the server will therefore gain access to the credit card
data.

One option is therefore to encrypt it. This means that the data is stored
on the server in an encrypted format. However, at some stage, the software
will legitimately need to decrypt the data in order to use this information.
To achieve this, it has to have access to the key to decrypt the
information. If the software has access to this decryption key then surely
so will any hacker. It would be equivalent to buying a secure safe and
hanging the keys next to it.

There must be a more secure implementation - could someone describe it>

Many thanks

Griff

 

[jwgoerlich@gmail.com]

Hello Griff,

You may want to spend time researching the Payment Card Industry (PCI)
Data Security Standard. This lays out in detail the best practices for
handling credit card information.

My advice is to not store the credit card at all. Process the
transaction and then flush the card information after confirmation. If
you abosolutely must keep the data, consider encrypting it at the
database level. This incurs a performance penalty but is likely the
most straight forward implementation.

Regards,

J Wolfgang Goerlich

Related Links:

Payment Card Industry Data Security Standard Compliance Planning Guide
http://www.microsoft.com/downloads/...F1-D0D0-469F-A6FC-B53987BD74C2&displaylang=en

Implementing Row- and Cell-Level Security in Classified Databases
Using SQL Server 2005
http://www.microsoft.com/technet/prodtechnol/sql/2005/multisec.mspx


On Dec 20, 7:15 am, "Griff" <griffithsj_...@hotmail.com> wrote:
> If sensitive information (such as a credit card) has to be saved to a
> database then there is a duty of care to protect this information.
>
> If the data is saved in plain text, then there is a concern that a hacker
> gaining access to the server will therefore gain access to the credit card
> data.
>
> One option is therefore to encrypt it. This means that the data is stored
> on the server in an encrypted format. However, at some stage, the software
> will legitimately need to decrypt the data in order to use this information.
> To achieve this, it has to have access to the key to decrypt the
> information. If the software has access to this decryption key then surely
> so will any hacker. It would be equivalent to buying a secure safe and
> hanging the keys next to it.
>
> There must be a more secure implementation - could someone describe it>
>
> Many thanks
>
> Griff

 

[Ron H]

Hi, I would like to know more on what you mean by :Flush the card
information after confirmation. If i've made purchases using a card #
where would that number be hiding on my computer. Thank You Ron

"jwgoerlich@gmail.com" wrote:

> Hello Griff,
>
> You may want to spend time researching the Payment Card Industry (PCI)
> Data Security Standard. This lays out in detail the best practices for
> handling credit card information.
>
> My advice is to not store the credit card at all. Process the
> transaction and then flush the card information after confirmation. If
> you abosolutely must keep the data, consider encrypting it at the
> database level. This incurs a performance penalty but is likely the
> most straight forward implementation.
>
> Regards,
>
> J Wolfgang Goerlich
>
> Related Links:
>
> Payment Card Industry Data Security Standard Compliance Planning Guide
> http://www.microsoft.com/downloads/...F1-D0D0-469F-A6FC-B53987BD74C2&displaylang=en
>
> Implementing Row- and Cell-Level Security in Classified Databases
> Using SQL Server 2005
> http://www.microsoft.com/technet/prodtechnol/sql/2005/multisec.mspx
>
>
> On Dec 20, 7:15 am, "Griff" <griffithsj_...@hotmail.com> wrote:
> > If sensitive information (such as a credit card) has to be saved to a
> > database then there is a duty of care to protect this information.
> >
> > If the data is saved in plain text, then there is a concern that a hacker
> > gaining access to the server will therefore gain access to the credit card
> > data.
> >
> > One option is therefore to encrypt it. This means that the data is stored
> > on the server in an encrypted format. However, at some stage, the software
> > will legitimately need to decrypt the data in order to use this information.
> > To achieve this, it has to have access to the key to decrypt the
> > information. If the software has access to this decryption key then surely
> > so will any hacker. It would be equivalent to buying a secure safe and
> > hanging the keys next to it.
> >
> > There must be a more secure implementation - could someone describe it>
> >
> > Many thanks
> >
> > Griff
>
>

 

[jwgoerlich@gmail.com]

Hello Ron,

I mean flushing the information on the ecommerce web and database
servers. This is not on your own computer.

Some companies, like Amazon.com, store the credit card information and
keep it on file after your purchase. This is a concern because, should
the data fall into the wrong hands, the credit card numbers could be
misused.

Other companies, like Solarbotics, do not store the credit card
information. They process the transaction and flush all identifying
information. Should the information fall into the wrong hands, there
is nothing to outright misuse. More companies should operate like
Solarbotics, in my opinion.

Consumers have control over this insofar as spending their money with
companies with stringent security and privacy guidelines.

J Wolfgang Goerlich


Solarbotics
http://www.solarbotics.com/info/privacy-policy/

On Dec 20, 9:13 am, Ron H <R...@discussions.microsoft.com> wrote:
> Hi, I would like to know more on what you mean by :Flush the card
> information after confirmation. If i've made purchases using a card #
> where would that number be hiding on my computer. Thank You Ron

 

[Ron H]

Mr, Goerlich, Thanks for the come back. Your always very informative,
I've read many posts. Enjoy your Hollidays. Ron

"jwgoerlich@gmail.com" wrote:

> Hello Ron,
>
> I mean flushing the information on the ecommerce web and database
> servers. This is not on your own computer.
>
> Some companies, like Amazon.com, store the credit card information and
> keep it on file after your purchase. This is a concern because, should
> the data fall into the wrong hands, the credit card numbers could be
> misused.
>
> Other companies, like Solarbotics, do not store the credit card
> information. They process the transaction and flush all identifying
> information. Should the information fall into the wrong hands, there
> is nothing to outright misuse. More companies should operate like
> Solarbotics, in my opinion.
>
> Consumers have control over this insofar as spending their money with
> companies with stringent security and privacy guidelines.
>
> J Wolfgang Goerlich
>
>
> Solarbotics
> http://www.solarbotics.com/info/privacy-policy/
>
> On Dec 20, 9:13 am, Ron H <R...@discussions.microsoft.com> wrote:
> > Hi, I would like to know more on what you mean by :Flush the card
> > information after confirmation. If i've made purchases using a card #
> > where would that number be hiding on my computer. Thank You Ron
>

 

[jwgoerlich@gmail.com]

Thanks, Ron. I hope you enjoy the holidays as well.

On Dec 20, 10:18 am, Ron H <R...@discussions.microsoft.com> wrote:
> Mr, Goerlich, Thanks for the come back. Your always very informative,
> I've read many posts. Enjoy your Hollidays. Ron
>
>
>
> "jwgoerl...@gmail.com" wrote:
> > Hello Ron,
>
> > I mean flushing the information on the ecommerce web and database
> > servers. This is not on your own computer.
>
> > Some companies, like Amazon.com, store the credit card information and
> > keep it on file after your purchase. This is a concern because, should
> > the data fall into the wrong hands, the credit card numbers could be
> > misused.
>
> > Other companies, like Solarbotics, do not store the credit card
> > information. They process the transaction and flush all identifying
> > information. Should the information fall into the wrong hands, there
> > is nothing to outright misuse. More companies should operate like
> > Solarbotics, in my opinion.
>
> > Consumers have control over this insofar as spending their money with
> > companies with stringent security and privacy guidelines.
>
> > J Wolfgang Goerlich
>
> > Solarbotics
> >http://www.solarbotics.com/info/privacy-policy/
>
> > On Dec 20, 9:13 am, Ron H <R...@discussions.microsoft.com> wrote:
> > > Hi, I would like to know more on what you mean by :Flush the card
> > > information after confirmation. If i've made purchases using a card #
> > > where would that number be hiding on my computer. Thank You Ron- Hide quoted text -
>
> - Show quoted text -

 

[Griff]

Excellent - thanks!

 

[Roger Abell [MVP]]

<jwgoerlich@gmail.com> wrote in message
news:abc666cc-3c04-4ebe-b40a-3f6e78eb59fa@i12g2000prf.googlegroups.com...
> Hello Ron,
>
> I mean flushing the information on the ecommerce web and database
> servers. This is not on your own computer.
>
> Some companies, like Amazon.com, store the credit card information and
> keep it on file after your purchase. This is a concern because, should
> the data fall into the wrong hands, the credit card numbers could be
> misused.
>
> Other companies, like Solarbotics, do not store the credit card
> information. They process the transaction and flush all identifying
> information. Should the information fall into the wrong hands, there
> is nothing to outright misuse. More companies should operate like
> Solarbotics, in my opinion.
>
> Consumers have control over this insofar as spending their money with
> companies with stringent security and privacy guidelines.
>

Hi Wolfgang,

Perhaps in the EU consumers have a handle with which to
exert control over this, but in my experience not in the USA.
One is rarely told that the info is being retained, let alone
asked that it may be, it is just done - and not by the big, major
etailers that might expect one's return business but by even the
little mom-and-pop type companies that have gone online (and
you know that the data is sitting on a little, old Windows PC
that is under the desk in the store's office).

The situation is in my opinion very bad. I rarely join into
advocacy groups, but if there were a lobby group trying to
get laws passed to define "my" rights over "my" information
and get some better practices in use, I would be on board.

Roger
Roger


> J Wolfgang Goerlich
>
>
> Solarbotics
> http://www.solarbotics.com/info/privacy-policy/
>
> On Dec 20, 9:13 am, Ron H <R...@discussions.microsoft.com> wrote:
>> Hi, I would like to know more on what you mean by :Flush the card
>> information after confirmation. If i've made purchases using a card #
>> where would that number be hiding on my computer. Thank You Ron

 

[Roger Abell [MVP]]

"Griff" <griffithsj_520@hotmail.com> wrote in message
news:OIEd0HwQIHA.4196@TK2MSFTNGP04.phx.gbl...
> If sensitive information (such as a credit card) has to be saved to a
> database then there is a duty of care to protect this information.
>
> If the data is saved in plain text, then there is a concern that a hacker
> gaining access to the server will therefore gain access to the credit card
> data.
>
> One option is therefore to encrypt it. This means that the data is stored
> on the server in an encrypted format. However, at some stage, the
> software will legitimately need to decrypt the data in order to use this
> information. To achieve this, it has to have access to the key to decrypt
> the information. If the software has access to this decryption key then
> surely so will any hacker. It would be equivalent to buying a secure safe
> and hanging the keys next to it.
>
> There must be a more secure implementation - could someone describe it>
>
> Many thanks
>
> Griff

With Windows the keys are not quite hanging next to the safe.
In order to access the keys one must be running in the context of
the correct account, and must have done so without resetting the
account's password. That, along with finding out what account,
at least places some hurdles in the path to the keys.

Roger

 

[Anne & Lynn Wheeler]

"Griff" <griffithsj_520@hotmail.com> writes:
> If sensitive information (such as a credit card) has to be saved to a
> database then there is a duty of care to protect this information.
>
> If the data is saved in plain text, then there is a concern that a hacker
> gaining access to the server will therefore gain access to the credit card
> data.
>
> One option is therefore to encrypt it. This means that the data is stored
> on the server in an encrypted format. However, at some stage, the software
> will legitimately need to decrypt the data in order to use this information.
> To achieve this, it has to have access to the key to decrypt the
> information. If the software has access to this decryption key then surely
> so will any hacker. It would be equivalent to buying a secure safe and
> hanging the keys next to it.
>
> There must be a more secure implementation - could someone describe it>

in the x9a10 financial standard working group for the x9.59 standard
.... it eliminated information from previous financial transactions as a
vulnerability.
http://www.garlic.com/~lynn/x959.html#x959

the current situation places diametrically opposing requirements on the
credit card information ... 1) it has to be readily available for large
number of different business processes (not just the initial
transaction) and 2) because the same information can be used by crooks
for fraudulent transactions ... the information has to be kept
confidential and never divulged. this is source of our periodic comments
in the past that even if the planet was buried under miles of encryption
.... it still wouldn't prevent information leakage.

we had been called into consult with small client/server startup that
wanted to do payments on their server ... they had this technology
called SSL they wanted to use ... and it is now frequently referred
to as electronic commerce
http://www.garlic.com/~lynn/subnetwork.html#gateway

one of the issues was that the application of SSL was only able to hide
the transaction information while it was being transmitted thru the
internet ... and didn't do anything to address the major points of
exploits.

we were then dragged into working in the x9a10 financial standard
working group which in the mid-90s had been given the requirement to
preserve the integrity of the financial infrastructure for all retail
payments.