[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [WEB SECURITY] Hashing and entropy

------_=_NextPart_001_01C8D32B.2C753A56
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Yes, most definitely the best solution is to avoid the problem =
altogether. Storing PANs is clearly not an easy problem, but we know =
lot's of people out there are cobbling together solutions, and likely =
pass their PCI audits.

I first came across this issue several years ago doing a design review =
for a service that wanted to do regular monthly billing against a =
payment processor. Changes to the service were to require the credit =
card be re-entered and verified against the card on file for security =
purposes. Of course they wanted to store unsalted MD5 hashes of the =
credit card number for the verification step ... which we luckily pulled =
from the design.=20

PCI is a good initiative, but I shudder to think how it gets enforced as =
it's so vague. None of the solutions suggested in the bit I quoted are =
much better than storing the PAN in the clear, except truncation, =
perhaps.

(I'm not sure how "index tokens and pads" is meant to be interpreted, =
but if it means one time pads, it actually might be a pretty good =
option)


-----Original Message-----
From: Martin O'Neal [mailto:martin.oneal@corsaire.com]
Sent: Fri 20/06/2008 17:33
To: Lavery, Oliver; Glenn.Everhart@chase.com; aksecurity@gmail.com; =
nhoyle@hoyletech.com
Cc: websecurity@webappsec.org
Subject: RE: [WEB SECURITY] Hashing and entropy
=20

I've provided some crypto guidance for a couple of UK high street
retailers PCI projects, and the general rule is that the right solution
is based mostly on context, and what you actually want to do with the
PAN (or a derivative of it).  No one size fits all. =20

As a first port of call though, only keep the data you absolutely must
keep, and only for as long as you need to.  Many people use the PAN as a
key for marketing or purchase history, which is just isn't suitable for.
If you can ruthelessly remove PCI data, then you reduce the problem
(often by several orders of magnitude).

For example, many merchant services will wrap the whole CC handling
process for you.  Which means that you should never have to store any
PCI related data at all; you hold it transiently whilst the transaction
is authorised, and then you store the transaction reference, and destroy
the PAN/CVV etc.

Martin...


-------------------------------------------------------------------------=
---
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives:=20
http://www.webappsec.org/lists/websecurity/

Subscribe via RSS:=20
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA



------_=_NextPart_001_01C8D32B.2C753A56
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7652.24">
<TITLE>RE: [WEB SECURITY] Hashing and entropy</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Yes, most definitely the best solution is to avoid the =
problem altogether. Storing PANs is clearly not an easy problem, but we =
know lot's of people out there are cobbling together solutions, and =
likely pass their PCI audits.<BR>
<BR>
I first came across this issue several years ago doing a design review =
for a service that wanted to do regular monthly billing against a =
payment processor. Changes to the service were to require the credit =
card be re-entered and verified against the card on file for security =
purposes. Of course they wanted to store unsalted MD5 hashes of the =
credit card number for the verification step ... which we luckily pulled =
from the design.<BR>
<BR>
PCI is a good initiative, but I shudder to think how it gets enforced as =
it's so vague. None of the solutions suggested in the bit I quoted are =
much better than storing the PAN in the clear, except truncation, =
perhaps.<BR>
<BR>
(I'm not sure how &quot;index tokens and pads&quot; is meant to be =
interpreted, but if it means one time pads, it actually might be a =
pretty good option)<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Martin O'Neal [<A =
HREF=3D"mailto:martin.oneal@corsaire.com";>mailto:martin.oneal@corsaire.co=
m</A>]<BR>
Sent: Fri 20/06/2008 17:33<BR>
To: Lavery, Oliver; Glenn.Everhart@chase.com; aksecurity@gmail.com; =
nhoyle@hoyletech.com<BR>
Cc: websecurity@webappsec.org<BR>
Subject: RE: [WEB SECURITY] Hashing and entropy<BR>
<BR>
<BR>
I've provided some crypto guidance for a couple of UK high street<BR>
retailers PCI projects, and the general rule is that the right =
solution<BR>
is based mostly on context, and what you actually want to do with =
the<BR>
PAN (or a derivative of it).&nbsp; No one size fits all.&nbsp;<BR>
<BR>
As a first port of call though, only keep the data you absolutely =
must<BR>
keep, and only for as long as you need to.&nbsp; Many people use the PAN =
as a<BR>
key for marketing or purchase history, which is just isn't suitable =
for.<BR>
If you can ruthelessly remove PCI data, then you reduce the problem<BR>
(often by several orders of magnitude).<BR>
<BR>
For example, many merchant services will wrap the whole CC handling<BR>
process for you.&nbsp; Which means that you should never have to store =
any<BR>
PCI related data at all; you hold it transiently whilst the =
transaction<BR>
is authorised, and then you store the transaction reference, and =
destroy<BR>
the PAN/CVV etc.<BR>
<BR>
Martin...<BR>
<BR>
<BR>
-------------------------------------------------------------------------=
---<BR>
Join us on IRC: irc.freenode.net #webappsec<BR>
<BR>
Have a question? Search The Web Security Mailing List Archives:<BR>
<A =
HREF=3D"http://www.webappsec.org/lists/websecurity/";>http://www.webappsec=
.org/lists/websecurity/</A><BR>
<BR>
Subscribe via RSS:<BR>
<A =
HREF=3D"http://www.webappsec.org/rss/websecurity.rss";>http://www.webappse=
c.org/rss/websecurity.rss</A> [RSS Feed]<BR>
<BR>
Join WASC on LinkedIn<BR>
<A =
HREF=3D"http://www.linkedin.com/e/gis/83336/4B20E4374DBA";>http://www.link=
edin.com/e/gis/83336/4B20E4374DBA</A><BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C8D32B.2C753A56--
Brought to you by http://www.webappsec.org
Search this site