What are the legal implications of storing bank details and/or debit or
credit card details of customers in a database in the UK?

Assuming it's illegal to just simply store them unencypted, how do I store
them legally? What technical and legal processes should be followed in order
to do this?

Take a look at the website of the Information Commissioner and read the
relevant pages.

Peter Crosland

Dave wrote:

Why would you asssume that?

If you have a legitimate need to store them, and your customers' permission,
there will be no problem. I would imagine the only reason you would have,
other than temporarily while a transaction is pending (e.g. to retry if it
failed the first time, or to be able to make refunds to the card for goods
returned) is if you expect repeat orders from the customers and wish to
offer them the convenience of not having to re-enter their card details
every time.

I don't think there's a technical problem. Encrypt if you like, but
I don't think doing so has any great value unless you think it likely
that your systems are going to leak the information into the wrong
hands. Often such leaks would be an inside job, and any decryption
tools would be available to internal crooks anyway, hence encrypting
doesn't really gain you anything.

Naturally your systems ought to be impregnable to external attack.
That probably rules out Microsoft Windows.

On Sun, 04 Jun 2006 13:43:44 GMT, Ronald Raygun
<no.spam (AT) localhost (DOT) localdomain> wrote:
Erm, no if you fail to encrypt I think it highly unlikely that anyone
would consider you'd taken due care with the data, I would expect all
personal data to be encrypted beyond something basic like name/email
address.

Remember physical theft of computers or backup tapes etc. is something
that is surprisingly common, and you have to defend against it.
Encryption is of course part of that.

Jim.

Jim Ley wrote:

Nah. Physical theft of filing cabinets full of confidential paper
records are possible too. You wouldn't encrypt those either.

I'm not saying encryption would not be a wise thing to do, I'm just
disagreeing with the proposition that it would be "illegal" not to.

On Sun, 04 Jun 2006 14:10:06 GMT, Ronald Raygun
<no.spam (AT) localhost (DOT) localdomain> wrote:
Well it's certainly not illegal in that there's a law requiring it,
however there is a law requiring appropriate levels of security, I
would suggest that you're not going to convince a judge that not
encrypting was appropriate, given how trivial it is.

Jim,

Jim Ley wrote:

What law is that, then? And who's to say that "appropriate" would
not be satisfied by simply password-protecting login-access to the
machine, and setting appropriate file permissions?

In any case, it's not trivial at all, given the requirement that the
computer which is going to be stolen must itself already contain the
decryption capability, given that the purpose of holding the data is
to make them available on line. Typically you would present an online
customer with a payment form on which the card details are already
pre-filled in, so the customer can confirm the details or replace them
with those of a different card.

It would be the equivalent of storing paper records in a locked safe,
but leaving the key in the door, or, in the case of a combination
lock, writing the combination on a pice of paper taped to the door.

On Sun, 04 Jun 2006 14:42:08 GMT, Ronald Raygun
<no.spam (AT) localhost (DOT) localdomain> wrote:

I was imagining the Data Protection Act:



Well I certainly would, and so have every computer security expert
I've discussed it with.

Erm, no it doesn't! there are many reasons for securing passwords
that do not require the decryption ability be on the same machine,
indeed none of the ones you've mentioned do. The Refunds and Repeat
business are simply done by sending the encrypted version from the DB
to the seperate machine for decryption, that's how I've always seen it
implemented when done remote appropriately.

I've never seen a solution where full card details are echo'd back to
the user, nor a reason to (card number ending in 1234, is the normal
method) It's a really bad idea, it's also bad socially as it's
suggestive of weak security, so HCI people tend not to like it (just
like passwords are rendered as *'s even in plain text environments.)

I think you should spend more time in computer security, it's not at
all the same.

Jim.

"Dave" <dave (AT) gmailNOSPAM (DOT) com> wrote

Under the Data Protection Act, you have a legal obligation to make sure that
the data is secure - the 7th principle:
http://www.ico.gov.uk/eventual.aspx?...pmovie=1#About

From the Act:
"7. Appropriate technical and organisational measures shall be taken against
unauthorised or unlawful processing of personal data and against accidental
loss or destruction of, or damage to, personal data."
http://www.opsi.gov.uk/acts/acts1998...-l.htm#sch1ptI

How you actually do this depends upon how and where you are storing the
data. You would need to seek expert technical advise on this.

Iain

Jim Ley wrote:

That's all very well if the data are stored on a separate machine.
What if they're not?

*If* the data and the decryption recipes are on the same machine, then
it *is* the same. It is also somewhat the same if they're on different
machines, if the two machines can both be stolen together. To guard
against that, you would have to keep the machines on separate sites,
but even that would not make you totally safe from a really determined
effort to steal both the data and the decrytion keys by breaking into
both sites simultaneously and stealing both machines.

Going off-site also introduces risk of harm resulting from temporary
loss of access to data, should a break in connectivity arise.