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?
> 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:
> 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,
Why would you asssume that?
> how do I store them legally?
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.
> What technical and legal processes should be followed in
> order to do this?
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
<> wrote:
> 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.
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:
> 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.
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
<> wrote:
>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.
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:
> On Sun, 04 Jun 2006 14:10:06 GMT, Ronald Raygun
> <> wrote:
>>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.
>
> 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.
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
<> wrote:
>Jim Ley 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.
>
>What law is that, then?
I was imagining the Data Protection Act:
| Having regard to the state of technological development and the cost
| of implementing any measures, the measures must ensure a level of
| security appropriate to-
| (a) the harm that might result from such unauthorised or unlawful
| processing or accidental loss, destruction or damage as are
| mentioned in the seventh principle, and
| (b) the nature of the data to be protected.
> 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?
Well I certainly would, and so have every computer security expert
I've discussed it with.
>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,
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.
>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.
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.)
>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.
I think you should spend more time in computer security, it's not at
all the same.
Jim.
"Dave" <> wrote in message
news:rNygg.3912$
> 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?
Under the Data Protection Act, you have a legal obligation to make sure that
the data is secure - the 7th principle:
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."
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:
> On Sun, 04 Jun 2006 14:42:08 GMT, Ronald Raygun
> <> wrote:
>>
>>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,
>
> 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.
That's all very well if the data are stored on a separate machine.
What if they're not?
>>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.
>
> it's not at all the same.
*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.
On Sun, 04 Jun 2006 16:43:54 GMT, Ronald Raygun
<> wrote:
>That's all very well if the data are stored on a separate machine.
>What if they're not?
you're building a secure system here, you simply do not do that, it's
unsafe, it's insecure.
>*If* the data and the decryption recipes are on the same machine, then
>it *is* the same.
Yes, but that's like saying "if I leave the front door open, it's the
same as leaving the key under the mat" well sure, but in discussing if
it's a good idea to not secure your house it's irrelevant, both are
wrong, and you do secure your house.
> 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.
Of course, but seperate machines at seperate sites is a bloody good
start, and is certainly reasonable - remember we only ever discussed
doing what is reasonable, and encrypting is certainly a minimum
requirement.
Jim.
In message <>, Jim Ley
<> writes
>On Sun, 04 Jun 2006 14:10:06 GMT, Ronald Raygun
><> wrote:
>>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.
>
>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.
That puts about 95% of the data stored in trouble then!
--
John Boyle
"Iain" <> wrote:
>"Dave" <> wrote in message
>news:rNygg.3912$
>> 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?
>
>Under the Data Protection Act, you have a legal obligation to make sure that
>the data is secure
>
>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.
I imagine the OP posted here because he was seeking "expert technical
advice". Where should he go?
On Sun, 4 Jun 2006 17:50:49 +0100, John Boyle
<> wrote:
>In message <>, Jim Ley
><> writes
>>On Sun, 04 Jun 2006 14:10:06 GMT, Ronald Raygun
>><> wrote:
>>>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.
>>
>>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.
>
>That puts about 95% of the data stored in trouble then!
Unlikely as the reasonableness is also related to the damage the data
can do, names, email addresses, how much someone has been paid etc.
has very little damage that can be done.
Credit cards with addresses and cv numbers however have a lot of
potential for damage...
Jim.
Jim Ley wrote:
> On Sun, 04 Jun 2006 16:43:54 GMT, Ronald Raygun
> <> wrote:
>
>>That's all very well if the data are stored on a separate machine.
>>What if they're not?
>
> you're building a secure system here, you simply do not do that, it's
> unsafe, it's insecure.
No, building a secure system is not the principal aim here. It is doing
what's reasonable within the overall constraints given, and even the Act
acknowledges that cost is one of them. If you're running only a very
small business, for example, it is entirely possible that you may have
only one machine available, and so the option of storing the data
elsewhere simply does not exist.
>>*If* the data and the decryption recipes are on the same machine, then
>>it *is* the same.
>
> Yes, but that's like saying "if I leave the front door open, it's the
> same as leaving the key under the mat" well sure, but in discussing if
> it's a good idea to not secure your house it's irrelevant, both are
> wrong, and you do secure your house.
You may well lock your house, but hey, if the burglar can just
kick the door in, or smash a window, you might as well leave the
key under the mat.
>> 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.
>
> Of course, but seperate machines at seperate sites is a bloody good
> start, and is certainly reasonable - remember we only ever discussed
> doing what is reasonable, and encrypting is certainly a minimum
> requirement.
I would agree encryption is a jolly good idea, but if data and
programs are on the same machine (and as I've illustrated, it
is not entirely unreasonable, in some circumstances, for this to
be the case), then there seems not an awful lot of point. So no,
it's not a "minimum requirement" at all.
John Boyle <> wrote:
>In message <>, Jim Ley
><> writes
>>On Sun, 04 Jun 2006 14:10:06 GMT, Ronald Raygun
>><> wrote:
>>>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.
>>
>>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.
>
>That puts about 95% of the data stored in trouble then!
Yes, but 95% of the data stored is publicly available. It raises an
interesting question. The data I have stored about the members of my
tennis club is not encrypted but there is no data stored that is not
in the telephone book. However, their record in my database reveals
the, otherwise secret, fact that they _are_ members of the tennis
club. Might I be obliged to encrypt the data to obscure this fact?
On Sun, 04 Jun 2006 17:10:27 GMT, Ronald Raygun
<> wrote:
> If you're running only a very
>small business, for example, it is entirely possible that you may have
>only one machine available, and so the option of storing the data
>elsewhere simply does not exist.
I doubt a single bank would issue a merchant account in such a
situation, realistically a 3rd party option is the only one that would
make economic sense, and there's little chance of getting anyone else
to provide a non-hosted solution.
>> Of course, but seperate machines at seperate sites is a bloody good
>> start, and is certainly reasonable - remember we only ever discussed
>> doing what is reasonable, and encrypting is certainly a minimum
>> requirement.
>
>I would agree encryption is a jolly good idea, but if data and
>programs are on the same machine (and as I've illustrated, it
>is not entirely unreasonable, in some circumstances, for this to
>be the case),
Are you an expert in the field? Would a judge consider your advice
when ruling, I'm not an internet security expert (despite newspapers
having claimed I am) but I have talked to a lot, and I can't see any
who would give the advice you're giving, so I can't see any judge
receiving similar expert advice in a resulting court case.
Jim.
"David Segall" <> wrote in message
news:
> "Iain" <> wrote:
>
>>"Dave" <> wrote in message
>>news:rNygg.3912$
>>> 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?
>>
>>Under the Data Protection Act, you have a legal obligation to make sure
>>that
>>the data is secure
>>
>>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.
> I imagine the OP posted here because he was seeking "expert technical
> advice". Where should he go?
My mistake! I realised after posting my reply that it had been cross-posted
to other newgroups other than uk.legal where I read it.
Iain
"Dave" <> wrote in message
news:rNygg.3912$
> 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?
Ideally, you should implement British Standard 7799 (ISO17799) - Information
Security Management. Whether you also choose to be audited to the Standard
depends on whether you need to satisfy others as to your compliance.
Personally, I use Protx for most transactions, so I never see those card
details, and, if I do take a card number, I destroy all records of it once
the payment is accepted. For one thing, it increases customer confidence if
they know you don't hold their data on file.
Colin Bignell
On Sun, 04 Jun 2006 13:47:48 GMT, (Jim Ley) wrote:
>On Sun, 04 Jun 2006 13:43:44 GMT, Ronald Raygun
><> wrote:
>> 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.
>
>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.
>
Well your expectations are not going to be met then.
I have worked for numerous organisations, many of which hold quite
sensitive personal data.
I have never yet come across one where any of it is encrypted.
The only data that is routinely encrypted is password data.
--
Alex Heney, Global Villager
Enough research will tend to support your theory.
To reply by email, my address is alexATheneyDOTplusDOTcom
On Sun, 04 Jun 2006 14:19:46 GMT, (Jim Ley) wrote:
>On Sun, 04 Jun 2006 14:10:06 GMT, Ronald Raygun
><> wrote:
>>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.
>
>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.
>
Unless your systems are particularly vulnerable to physical theft, you
would have no difficulty whatsoever in persuading a judge that normal
processing is perfectly fine.
--
Alex Heney, Global Villager
Enough research will tend to support your theory.
To reply by email, my address is alexATheneyDOTplusDOTcom
On Sun, 04 Jun 2006 14:42:08 GMT, Ronald Raygun
<> wrote:
>Jim Ley wrote:
>
>> On Sun, 04 Jun 2006 14:10:06 GMT, Ronald Raygun
>> <> wrote:
>>>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.
>>
>> 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.
>
>What law is that, then?
The DPA.
>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?
>
It will.
That is the norm. It is what every large business I am aware of does
with customer data.
Even very sensitive data, such as child protection registers held by
councils is only protected that way.
--
Alex Heney, Global Villager
Don't worry, I'm fluent in weirdo.
To reply by email, my address is alexATheneyDOTplusDOTcom
On Sun, 04 Jun 2006 15:02:50 GMT, (Jim Ley) wrote:
>On Sun, 04 Jun 2006 14:42:08 GMT, Ronald Raygun
<snip>
>> 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?
>
>Well I certainly would, and so have every computer security expert
>I've discussed it with.
>
Which is zero.
You may have discussed it with somebody claiming to be a computer
security expert, but if he claimed that "appropriate" would not be
satisfied by the above, then he was only a wanabee expert.
--
Alex Heney, Global Villager
We're all in the same boat: I fish, you row.
To reply by email, my address is alexATheneyDOTplusDOTcom
On Sun, 04 Jun 2006 21:38:10 +0100, Alex Heney <>
wrote:
>On Sun, 04 Jun 2006 15:02:50 GMT, (Jim Ley) wrote:
>
>>On Sun, 04 Jun 2006 14:42:08 GMT, Ronald Raygun
><snip>
>
>>> 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?
>>
>>Well I certainly would, and so have every computer security expert
>>I've discussed it with.
>>
>
>Which is zero.
>
>You may have discussed it with somebody claiming to be a computer
>security expert, but if he claimed that "appropriate" would not be
>satisfied by the above, then he was only a wanabee expert.
Oh right, based on what exactly?
Jim.
On Sun, 04 Jun 2006 16:50:01 GMT, (Jim Ley) wrote:
>> 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.
>
>Of course, but seperate machines at seperate sites is a bloody good
>start, and is certainly reasonable - remember we only ever discussed
>doing what is reasonable, and encrypting is certainly a minimum
>requirement.
It isn't even a requirement, never mind a "minimum" one.
It might be a good idea with PC based systems, although proper
passwording and restricted access to the data (which would presumably
be held in a database, not plain text files) will more often than not
be sufficient, even there.
It isn't even a particularly good idea with anything else.
--
Alex Heney, Global Villager
Hard work must have killed someone!
To reply by email, my address is alexATheneyDOTplusDOTcom
On Sun, 04 Jun 2006 21:34:25 +0100, Alex Heney <>
wrote:
>That is the norm. It is what every large business I am aware of does
>with customer data.
Odd, I don't know of a single internet company that does that with
credit card data, nor a bank that would accept it as part of their
conditions
>Even very sensitive data, such as child protection registers held by
>councils is only protected that way.
I would love to see that challenged in court in the result of a
compromised, of course though such data is not at a large risk, unlike
credit card data which is regularly stolen. I am sure the children
would be getting a large payout.
Jim.
On Sun, 04 Jun 2006 21:42:57 +0100, Alex Heney <>
wrote:
>On Sun, 04 Jun 2006 16:50:01 GMT, (Jim Ley) wrote:
>
>
>>> 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.
>>
>>Of course, but seperate machines at seperate sites is a bloody good
>>start, and is certainly reasonable - remember we only ever discussed
>>doing what is reasonable, and encrypting is certainly a minimum
>>requirement.
>
>It isn't even a requirement, never mind a "minimum" one.
Again, based on what?
Jim.
On Sun, 04 Jun 2006 21:42:57 +0100, Alex Heney <>
wrote:
>It isn't even a requirement, never mind a "minimum" one.
The Payment Card Industry Data Security Standard at
says:
| 3.4 Render sensitive cardholder data unreadable anywhere it is stored
| (including data on portable media, backup media, in logs, and data
| received from or stored by wireless networks) by using
| any of the following approaches:
|.. One-way hashes (hashed indexes), such as SHA-1
|.. Truncation
|.. Index tokens and PADs, with the PADs being securely stored
|.. Strong cryptography, such as Triple-DES 128-bit or AES 256-bit with
| associated key management processes and procedures.
|The MINIMUM account information that needs to be rendered
|unreadable is the payment card account number.
Which looks to me like Visa certainly consider it a minimum
requirement, and certainly all banks I've ever been involved with in
the UK require similar.
Why are you so confident this is not the case?
Jim.
On Sun, 04 Jun 2006 17:00:11 GMT, David Segall <>
wrote:
>"Iain" <> wrote:
>
>>"Dave" <> wrote in message
>>news:rNygg.3912$
>>> 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?
>>
>>Under the Data Protection Act, you have a legal obligation to make sure that
>>the data is secure
>>
>>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.
>I imagine the OP posted here because he was seeking "expert technical
>advice". Where should he go?
Well there are a few groups he could try, such as uk.comp.security, or
alt.computer.security, or comp.security.misc.
--
Alex Heney, Global Villager
But what if I'm a figment of my OWN imagination?
To reply by email, my address is alexATheneyDOTplusDOTcom
In message <>, Jim Ley
<> writes
>On Sun, 04 Jun 2006 13:43:44 GMT, Ronald Raygun
><> wrote:
>> 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.
>
>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.
I think you have no knowledge of small users such as IFAs, GPs
surgeries, Local Councils, dentists, solicitors, opticians, etc.,. I
dont believe any of their stuff is encrypted et they all hold
potentially very private data indeed.
--
John Boyle
On Sun, 4 Jun 2006 22:50:28 +0100, John Boyle
<> wrote:
>I think you have no knowledge of small users such as IFAs, GPs
>surgeries, Local Councils, dentists, solicitors, opticians, etc.,.
What ones of these are handling credit card details?
> I
>dont believe any of their stuff is encrypted et they all hold
>potentially very private data indeed.
Yes, but very low danger of it being stolen and used expensively,
unlike credit cards, I don't believe the majority of such stuff should
be encrypted (other than the medical details and the council at risk
we've discussed) but the topic at hand is credit card details on
internet servers. These should.
Jim.
In message <>, Jim Ley
<> writes
> but the topic at hand is credit card details on
>internet servers. These should.
I agree, but I was challenging your assertion - " I would expect all
personal data to be encrypted beyond something basic like name/email
address."
Do you still stand by that in the circs I described?
--
John Boyle
On Mon, 5 Jun 2006 00:14:03 +0100, John Boyle
<> wrote:
>In message <>, Jim Ley
><> writes
>> but the topic at hand is credit card details on
>>internet servers. These should.
>
>I agree, but I was challenging your assertion - " I would expect all
>personal data to be encrypted beyond something basic like name/email
>address."
>Do you still stand by that in the circs I described?
I would expect it yes, I wouldn't be surprised that most organisations
don't, but I would expect it, I'm not so sure what the courts or the
information commisioner would think, it's the sort of thing that is
only likely to be tested once something embarrassing happens.
Fortunately whilst most of the personal data you list is highly
personal, it has very little value so is not really worth anything in
the general case, so for specific people it's much easier to just pay
off a bent policeman or council worker etc. to get the individual
data, rather than bothering to secure the machine.
Jim.
In message <>, Jim Ley
<> writes
>On Mon, 5 Jun 2006 00:14:03 +0100, John Boyle
><> wrote:
>
>>In message <>, Jim Ley
>><> writes
>>> but the topic at hand is credit card details on
>>>internet servers. These should.
>>
>>I agree, but I was challenging your assertion - " I would expect all
>>personal data to be encrypted beyond something basic like name/email
>>address."
>>Do you still stand by that in the circs I described?
>
>I would expect it yes, I wouldn't be surprised that most organisations
>don't, but I would expect it, I'm not so sure what the courts or the
>information commisioner would think, it's the sort of thing that is
>only likely to be tested once something embarrassing happens.
That would put a huge overhead on many businesses that are now only
holding the same data on PC that was previously held in filing cabinets.
Also, AIUI, the DPA does not differentiate between paper and electronic
data storage methods. So should hand written details of credit cards and
the data held in the manner described also above be encrypted? would I
need to employ Bletchley park to do this by hand for me?
Why would *you* expect encryption? (putting court opinions to one side)
>
>Fortunately whilst most of the personal data you list is highly
>personal, it has very little value so is not really worth anything in
>the general case, so for specific people it's much easier to just pay
>off a bent policeman or council worker etc. to get the individual
>data, rather than bothering to secure the machine.
What input does this have to the point?
--
John Boyle
On Sun, 04 Jun 2006 20:53:52 GMT, (Jim Ley) wrote:
>On Sun, 04 Jun 2006 21:34:25 +0100, Alex Heney <>
>wrote:
>
>>That is the norm. It is what every large business I am aware of does
>>with customer data.
>
>Odd, I don't know of a single internet company that does that with
>credit card data, nor a bank that would accept it as part of their
>conditions
>
Well the only place I have worked directly on customer payment systems
certainly did.
The data was held in an ICL IDMSX database, but was not otherwise
encrypted.
This was the Direct Debit payment system for Hyder domestic
Electricity supplies. (and did include the AUDACS electronic DD
system, so no paper forms were necessary).
Also the payroll system I worked on at another company had the bank
details of the employees, for payment purposes, and those were not
encrypted.
And the Social Services systems that contain bank account details
(usually for payments to people in their care or the carers) do not
have them encrypted.
I have worked on computer systems containing sensitive customer data
for several other organisations, even if not actual banking details,
and I have never come across one where the data was encrypted.
>>Even very sensitive data, such as child protection registers held by
>>councils is only protected that way.
>
>I would love to see that challenged in court in the result of a
>compromised, of course though such data is not at a large risk, unlike
>credit card data which is regularly stolen. I am sure the children
>would be getting a large payout.
>
In some ways, the risk is more serious.
I agree there are not going to be as many people trying to get at it,
but the consequences of the wrong person getting that data could be
worse.
--
Alex Heney, Global Villager
Shift key? this keyboard is an automatic!
To reply by email, my address is alexATheneyDOTplusDOTcom
On Sun, 04 Jun 2006 20:42:27 GMT, (Jim Ley) wrote:
>On Sun, 04 Jun 2006 21:38:10 +0100, Alex Heney <>
>wrote:
>
>>On Sun, 04 Jun 2006 15:02:50 GMT, (Jim Ley) wrote:
>>
>>>On Sun, 04 Jun 2006 14:42:08 GMT, Ronald Raygun
>><snip>
>>
>>>> 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?
>>>
>>>Well I certainly would, and so have every computer security expert
>>>I've discussed it with.
>>>
>>
>>Which is zero.
>>
>>You may have discussed it with somebody claiming to be a computer
>>security expert, but if he claimed that "appropriate" would not be
>>satisfied by the above, then he was only a wanabee expert.
>
>Oh right, based on what exactly?
>
Experience.
If there was a general requirement to encrypt sensitive customer data,
then most large organisations would do so. But they don't.
--
Alex Heney, Global Villager
If it's stupid and works, then it ain't stupid
To reply by email, my address is alexATheneyDOTplusDOTcom
On Mon, 5 Jun 2006 00:49:41 +0100, John Boyle
<> wrote:
>In message <>, Jim Ley
><> writes
>>On Mon, 5 Jun 2006 00:14:03 +0100, John Boyle
>><> wrote:
>>
>>>In message <>, Jim Ley
>>><> writes
>>>> but the topic at hand is credit card details on
>>>>internet servers. These should.
>>>
>>>I agree, but I was challenging your assertion - " I would expect all
>>>personal data to be encrypted beyond something basic like name/email
>>>address."
>>>Do you still stand by that in the circs I described?
>>
>>I would expect it yes, I wouldn't be surprised that most organisations
>>don't, but I would expect it, I'm not so sure what the courts or the
>>information commisioner would think, it's the sort of thing that is
>>only likely to be tested once something embarrassing happens.
>
>That would put a huge overhead on many businesses that are now only
>holding the same data on PC that was previously held in filing cabinets.
>Also, AIUI, the DPA does not differentiate between paper and electronic
>data storage methods. So should hand written details of credit cards and
>the data held in the manner described also above be encrypted? would I
>need to employ Bletchley park to do this by hand for me?
>
No, the act requires that "appropriate" security measures are in
place.
In *general*, making sure that access to the data is properly secured
by access restrictions, together with physical security of the
location(s) where the computers actually are will suffice for
electronic data.
While just the physical security aspect would be required for paper
files.
--
Alex Heney, Global Villager
Daddy, what does FORMATTING DRIVE C: mean?
To reply by email, my address is alexATheneyDOTplusDOTcom
On Mon, 05 Jun 2006 00:53:25 +0100, Alex Heney <>
wrote:
>>Oh right, based on what exactly?
>>
>
>Experience.
>
>If there was a general requirement to encrypt sensitive customer data,
>then most large organisations would do so. But they don't.
We're talking about Credit card numbers here, not "sensitive customer
data" in the general case... Especially as I'm sure you're not using
sensitive in the DPA's definition, as most large organisations don't
collect such stuff.
Jim.
On Mon, 05 Jun 2006 00:52:28 +0100, Alex Heney <>
wrote:
>This was the Direct Debit payment system for Hyder domestic
>Electricity supplies. (and did include the AUDACS electronic DD
>system, so no paper forms were necessary).
>
>Also the payroll system I worked on at another company had the bank
>details of the employees, for payment purposes, and those were not
>encrypted.
Neither of which are credit cards, so I'd say pretty irrelevant for
you to speak with such authority on the subject.
Jim.
On Mon, 5 Jun 2006 00:49:41 +0100, John Boyle
<> wrote:
>That would put a huge overhead on many businesses that are now only
>holding the same data on PC that was previously held in filing cabinets.
No it wouldn't encryption is essentially cheap, certainly cheap as a
proportion to the cost of the rest of the system.
>Why would *you* expect encryption? (putting court opinions to one side)
because it's cheap and trivial to implement and as the act requires
you to take into account the state of technological data, it's a
reasonable step.
>>
>>Fortunately whilst most of the personal data you list is highly
>>personal, it has very little value so is not really worth anything in
>>the general case, so for specific people it's much easier to just pay
>>off a bent policeman or council worker etc. to get the individual
>>data, rather than bothering to secure the machine.
>
>What input does this have to the point?
The cost and value of obtaining data is highly relevant to the
decisions on how to protect it. A collection of credit cards is
valuable because all of them can be used fraudalent, information about
individuals related to their health or criminal records is only
relevant in the individual case, so the threats to the data are
different.
Jim.
John Boyle <> writes:
> Also, AIUI, the DPA does not differentiate between paper and
> electronic data storage methods. So should hand written details of
> credit cards and the data held in the manner described also above be
> encrypted? would I need to employ Bletchley park to do this by hand
> for me?
No. Encryption is often likened to storage in a secure safe. So things
like credit card details should be stored securely, have appropriate
procedures for who is allowed access to the information, only be taken
out of storage (access the un-encrypted data) while being worked upon
and never left on an unattended desk.
On Mon, 05 Jun 2006 02:00:21 GMT, (Jim Ley) wrote:
>On Mon, 05 Jun 2006 00:53:25 +0100, Alex Heney <>
>wrote:
>>>Oh right, based on what exactly?
>>>
>>
>>Experience.
>>
>>If there was a general requirement to encrypt sensitive customer data,
>>then most large organisations would do so. But they don't.
>
>We're talking about Credit card numbers here, not "sensitive customer
>data" in the general case... Especially as I'm sure you're not using
>sensitive in the DPA's definition, as most large organisations don't
>collect such stuff.
Sorry, I thought we were talking about what you said in your first
post in this thread:
------------------------------------------------------------ ---------
I would expect all personal data to be encrypted beyond something
basic like name/email
address.
------------------------------------------------------------ --------
That is certainly what *I* have been talking about since.
But you are right about the way I am using "sensitive personal data".
I am using that in the sense I believe most people would understand,
rather than the DPA definition.
--
Alex Heney, Global Villager
Gargle twice daily - see if your neck leaks.
To reply by email, my address is alexATheneyDOTplusDOTcom
Jim Ley wrote:
> On Mon, 5 Jun 2006 00:49:41 +0100, John Boyle
> <> wrote:
>
>>That would put a huge overhead on many businesses that are now only
>>holding the same data on PC that was previously held in filing cabinets.
>
> No it wouldn't encryption is essentially cheap, certainly cheap as a
> proportion to the cost of the rest of the system.
>
>>Why would *you* expect encryption? (putting court opinions to one side)
>
> because it's cheap and trivial to implement and as the act requires
> you to take into account the state of technological data, it's a
> reasonable step.
It's not cheap and trivial, because if your software doesn't do it
already, and oesn't have a configuration option to do it, you have to
throw it away and buy and install new software which does, and re-train
your staff to learn how to use it. That's hugely expensive.
It's only trivial if you've written your own software and can just
slot in some scrambling and descrambling stuff. I could. But most
small data users couldn't.
> A collection of credit cards is
> valuable because all of them can be used fraudalent,
You can't easily obtain cash or goods from a credit card number unless
you use it to manufacture a card, and then cash only if you know the
PIN. You can't order stuff by mail order except to the card holder's
address. So why are mere card details so valuable? I don't see it.
On Mon, 05 Jun 2006 12:08:52 GMT, Ronald Raygun
<> wrote:
>> because it's cheap and trivial to implement and as the act requires
>> you to take into account the state of technological data, it's a
>> reasonable step.
>
>It's not cheap and trivial, because if your software doesn't do it
>already, and oesn't have a configuration option to do it, you have to
>throw it away and buy and install new software which does, and re-train
>your staff to learn how to use it. That's hugely expensive.
to have something encypted on the disk? what systems don't provide
encrypted filesystems in use today? windows does, OS-X does, linux *
does, of course that's pretty weak in that it's tied to log-on users,
but it's a 5 minute activity that you never need to think of again.
To have it integrated within a single application certainly may depend
on the application, but again it's cheap.
>> A collection of credit cards is
>> valuable because all of them can be used fraudalent,
>
>You can't easily obtain cash or goods from a credit card number unless
>you use it to manufacture a card, and then cash only if you know the
>PIN. You can't order stuff by mail order except to the card holder's
>address. So why are mere card details so valuable? I don't see it.
There are a lot of non goods ability to turn credit cards into money
without a strip, there's lots of services that aren't physical goods.
Jim.
Jim Ley wrote:
> On Mon, 05 Jun 2006 12:08:52 GMT, Ronald Raygun
> <> wrote:
>
>>> because it's cheap and trivial to implement and as the act requires
>>> you to take into account the state of technological data, it's a
>>> reasonable step.
>>
>>It's not cheap and trivial, because if your software doesn't do it
>>already, and oesn't have a configuration option to do it, you have to
>>throw it away and buy and install new software which does, and re-train
>>your staff to learn how to use it. That's hugely expensive.
>
> to have something encypted on the disk? what systems don't provide
> encrypted filesystems in use today? windows does, OS-X does, linux *
> does, of course that's pretty weak in that it's tied to log-on users,
> but it's a 5 minute activity that you never need to think of again.
Really? The asterisk suggests there's a footnote to come, but you didn't
add one. My linux does not, as far as I'm aware, have such an option.
> To have it integrated within a single application certainly may depend
> on the application, but again it's cheap.
No it's not cheap, because unless you have control over it, the originator
has to build it in for you, and they won't unless they're happy to do so
on a one-off basis (which will cost) or unless they can see a wider market
(in which case it'll still take time).
>>> A collection of credit cards is
>>> valuable because all of them can be used fraudalent,
>>
>>You can't easily obtain cash or goods from a credit card number unless
>>you use it to manufacture a card, and then cash only if you know the
>>PIN. You can't order stuff by mail order except to the card holder's
>>address. So why are mere card details so valuable? I don't see it.
>
> There are a lot of non goods ability to turn credit cards into money
> without a strip, there's lots of services that aren't physical goods.
>
> Jim.
On Mon, 05 Jun 2006 13:33:41 GMT, Ronald Raygun
<> wrote:
>Jim Ley wrote:
>> to have something encypted on the disk? what systems don't provide
>> encrypted filesystems in use today? windows does, OS-X does, linux *
>> does, of course that's pretty weak in that it's tied to log-on users,
>> but it's a 5 minute activity that you never need to think of again.
>
>Really? The asterisk suggests there's a footnote to come, but you didn't
>add one. My linux does not, as far as I'm aware, have such an option.
The * acvtually meant a multitude of linux like things, are you sure
EncFS doesn't run for you? I understood it did for just about
anything. I would be amazed if there were any linux like things
knocking about that didn't have an encrypted file-system.
Jim.
Jim Ley wrote:
> On Mon, 05 Jun 2006 13:33:41 GMT, Ronald Raygun
> <> wrote:
>
>>Jim Ley wrote:
>>> to have something encypted on the disk? what systems don't provide
>>> encrypted filesystems in use today? windows does, OS-X does, linux *
>>> does, of course that's pretty weak in that it's tied to log-on users,
>>> but it's a 5 minute activity that you never need to think of again.
>>
>>Really? The asterisk suggests there's a footnote to come, but you didn't
>>add one. My linux does not, as far as I'm aware, have such an option.
>
> The * acvtually meant a multitude of linux like things, are you sure
> EncFS doesn't run for you? I understood it did for just about
> anything. I would be amazed if there were any linux like things
> knocking about that didn't have an encrypted file-system.
Never heard of it, but my friend google obliged. It appears it
wouldn't be suitable, because it seems to rely on you unmounting the
filesystem in order to perform the actual encryption. That's not
much use if the data is required to be on line 24-7.
On Mon, 05 Jun 2006 14:56:13 GMT, Ronald Raygun
<> wrote:
>Never heard of it, but my friend google obliged. It appears it
>wouldn't be suitable, because it seems to rely on you unmounting the
>filesystem in order to perform the actual encryption. That's not
>much use if the data is required to be on line 24-7.
There are certainly others, including ones which work just like the
mac/window solutions, I'm sure asking in the relevant group will sort
you out.
Jim.
Jim Ley wrote:
> On Mon, 05 Jun 2006 14:56:13 GMT, Ronald Raygun
> <> wrote:
>
>>Never heard of it, but my friend google obliged. It appears it
>>wouldn't be suitable, because it seems to rely on you unmounting the
>>filesystem in order to perform the actual encryption. That's not
>>much use if the data is required to be on line 24-7.
>
> There are certainly others, including ones which work just like the
> mac/window solutions, I'm sure asking in the relevant group will sort
> you out.
You don't understand. I'm not interested in being "sorted out", I don't
have an encryption requirement, and if I did, I'd fill it my own way.
I'm merely claiming there is no trivial solution which non-experts can
just slot into their systems. You are claiming the opposite, and I'm
damned if I'm going to do the research for you to help you disprove my
claim.
On Mon, 05 Jun 2006 15:53:44 GMT, Ronald Raygun
<> wrote:
>I'm merely claiming there is no trivial solution which non-experts can
>just slot into their systems. You are claiming the opposite, and I'm
>damned if I'm going to do the research for you to help you disprove my
>claim.
If we're talking non-experts, then we're not talking linux users, as
we're not talking linux users, then Windows contains a trivial
methods, you can't have it both ways, if they're using simple off the
shelf packages on commercial O/S's then all you need to do is right
click and select "encrypt" - do that to any data folder and it's done.
It's trivial.
If you're not using off-the shelf consumer level stuff, then you
certainly have the ability or the ability to specify it when
purchasing, given the triviality of it, it won't impact the cost a
lot.
Jim.
"Jim Ley" wrote
> ... Windows contains a trivial methods, you can't have it
> both ways, if they're using simple off the shelf packages on
> commercial O/S's then all you need to do is right click and
> select "encrypt" - do that to any data folder and it's done.
> It's trivial.
Not everyone uses the latest version of Windows.
How do you expect someone running,
say, Windows 2000 to set up encryption?
Jim Ley wrote:
> If we're talking non-experts, then we're not talking linux users,
"All linux users are experts"? Hahahaha.
On Mon, 05 Jun 2006 17:19:46 GMT, Ronald Raygun
<> wrote:
>Jim Ley wrote:
>
>> If we're talking non-experts, then we're not talking linux users,
>
>"All linux users are experts"? Hahahaha.
that's not what I said at all...
Jim.
Jim Ley wrote:
> On Mon, 05 Jun 2006 17:19:46 GMT, Ronald Raygun
> <> wrote:
>
>>Jim Ley wrote:
>>
>>> If we're talking non-experts, then we're not talking linux users,
>>
>>"All linux users are experts"? Hahahaha.
>
> that's not what I said at all...
Oh yes it is. Not literally, but in terms of meaning.
What you said amounts to "if a person is not an expert, this
implies he is not a linux user".
By the rules of basic logic, "A implies B" is equivalent to "(not B)
implies (not A)".
In this case, you said the second half, where B is "person is expert"
and A is "person is linux user". This is equivalent to the first
half "anyone who is a linux user must be an expert".
So there!
On Mon, 05 Jun 2006 17:25:39 GMT, (Jim Ley) wrote:
>On Mon, 05 Jun 2006 17:19:46 GMT, Ronald Raygun
><> wrote:
>
>>Jim Ley wrote:
>>
>>> If we're talking non-experts, then we're not talking linux users,
>>
>>"All linux users are experts"? Hahahaha.
>
>that's not what I said at all...
Yes it is.
You said that all non experts are not linux users. Which means that
all linux users are experts.
--
Alex Heney, Global Villager
No! No! Windows isn't a virus. Viruses do something.
To reply by email, my address is alexATheneyDOTplusDOTcom