Storing Credit Cards, Passwords, Securely, two-way encryption

So I'm thinking about how to save credit card numbers in the DB, for
re-charging cards for subscriptions, new orders, etc.

I'm also thinking about how to save passwords in the DB, not plaintext, but
not one-way encrypted either.

Any suggestions? How would I secure the database? I'm thinking some
abstract process in code, or something -- security through obscurity.

Beckman
------------------------------------------------------------ ---------------
Peter Beckman Internet Guy
beckman@purplecow.com http://www.purplecow.com/
------------------------------------------------------------ ---------------

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Storing Credit Cards, Passwords, Securely, two-way encryption

Peter Beckman wrote:
> So I'm thinking about how to save credit card numbers in the DB, for
> re-charging cards for subscriptions, new orders, etc.

Why, is the first question I would ask you. First off, on a new order,
why wouldn't you just save the authorization code, instead of the credit
card number? That would be a lot easier. Secondly, you're opening
yourself up to a _ton_ of lawsuits should anything go awry. Unless I
had a _real_ good reason for storing their cc number, I wouldn't,
despite the extra step.

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: Storing Credit Cards, Passwords, Securely, two-way encryption

CC saving is a bad idea on a web facing server...much better to let the user
re-input the data each time. If your network allows it, store the data
encrypted (using php's mcrypt/decrypt extension) on an separate extremely
limited access, non-webfacing (ie internal) db/server that only allows
inserts from the webfacing server. Hacking and the liability of being hacked
is something to take very seriously. Also look into PCI & regulatory
compliance with regard to storing CC data on a server to be aware of any
laws that can govern how you do this.

Passwords: again use mcrypt

Bastien


>From: Peter Beckman
>To: PHP-DB Mailing List
>Subject: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-way
>encryption
>Date: Thu, 5 Jan 2006 20:27:57 -0500 (EST)
>
>So I'm thinking about how to save credit card numbers in the DB, for
>re-charging cards for subscriptions, new orders, etc.
>
>I'm also thinking about how to save passwords in the DB, not plaintext, but
>not one-way encrypted either.
>
>Any suggestions? How would I secure the database? I'm thinking some
>abstract process in code, or something -- security through obscurity.
>
>Beckman
>----------------------------------------------------------- ----------------
>Peter Beckman Internet Guy
>beckman@purplecow.com http://www.purplecow.com/
>----------------------------------------------------------- ----------------
>
>--
>PHP Database Mailing List (http://www.php.net/)
>To unsubscribe, visit: http://www.php.net/unsub.php
>

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Storing Credit Cards, Passwords, Securely, two-way encryption

Any reason why you need to have reversible encryption on the password
value??


Generally I simply create some hash from the password, using something
akin to a MD5 or SHA1 hash of the password string. Or in my paranoid
case I use the password string, plus all sorts of replicatable
combinations of values such as length of password, username,
registration date/time etc plus weird other fixed values I find around
the place and environment variables etc, then I hash them..


This is just to help prevent any possible dictionary matching of
documented common word hashes that can be found on the net due to my
mangling of the original word with many other values to create a very
abstract piece of art.


I am completely psychotic so don't mind me, when I was 15 I wrote my
Perl driven website http://operation-scifi.com [still Perl driven member
system and file-system based forum] and I had a real mangler function
whereby I would extract each character of the password and hash it, then
hash the hash with the other characters, plus the hash of them with said
fixed values from server/user account details [age, location etc..] ...
It was something in the vicinity of a O(6^n+1)th generation hash by the
time I had finished where n is the length of the original password..

As I said.. I'm mangled up in my head and I'm extremely passionate about
the evolution of security. Thank you GCHQ of England, thank you
Williamson, Clifford Cocks, James Ellison and thank you Whitfield
Diffie, Merkle and Hellman.. Thank you Ronald Rivest, Adi Shamir and
Leonard Adleman.... Thank you Phil Zimmermann..

tata!

---oOo--- Allowing users to execute CGI scripts in any directory should
only be considered if: ... a.. You have no users, and nobody ever visits
your server. ... Extracted Quote: Security Tips - Apache HTTP
Server ---oOo--- ------oOo---------------oOo------ Julien Bonastre
[The_RadiX] The-Spectrum Network CEO ABN: 64 235 749 494
julien@the-spectrum.org
www.the-spectrum.org ------oOo---------------oOo------
----- Original Message -----
From: "Bastien Koert"
To: ;
Sent: Friday, January 06, 2006 12:36 PM
Subject: RE: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-way
encryption


> CC saving is a bad idea on a web facing server...much better to let
> the user re-input the data each time. If your network allows it,
> store the data encrypted (using php's mcrypt/decrypt extension) on an
> separate extremely limited access, non-webfacing (ie internal)
> db/server that only allows inserts from the webfacing server. Hacking
> and the liability of being hacked is something to take very seriously.
> Also look into PCI & regulatory compliance with regard to storing CC
> data on a server to be aware of any laws that can govern how you do
> this.
>
> Passwords: again use mcrypt
>
> Bastien
>
>
>>From: Peter Beckman
>>To: PHP-DB Mailing List
>>Subject: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-way
>>encryption
>>Date: Thu, 5 Jan 2006 20:27:57 -0500 (EST)
>>
>>So I'm thinking about how to save credit card numbers in the DB, for
>>re-charging cards for subscriptions, new orders, etc.
>>
>>I'm also thinking about how to save passwords in the DB, not
>>plaintext, but
>>not one-way encrypted either.
>>
>>Any suggestions? How would I secure the database? I'm thinking some
>>abstract process in code, or something -- security through obscurity.
>>
>>Beckman
>>---------------------------------------------------------- -----------------
>>Peter Beckman
>>Internet Guy
>>beckman@purplecow.com
>>http://www.purplecow.com/
>>---------------------------------------------------------- -----------------
>>
>>--
>>PHP Database Mailing List (http://www.php.net/)
>>To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Storing Credit Cards, Passwords, Securely, two-way

On Thu, 5 Jan 2006, John Meyer wrote:

> Peter Beckman wrote:
>> So I'm thinking about how to save credit card numbers in the DB, for
>> re-charging cards for subscriptions, new orders, etc.
>
> Why, is the first question I would ask you.

>> So I'm thinking about how to save credit card numbers in the DB, for
>> re-charging cards for subscriptions, new orders, etc.

Think one-click. Why did Amazon patent one-click? Impulse buys -- the "I
want that, now" factor. If you make 13 steps and 12 input boxes, the
Impulse will probably pass, and you've lost your sale.

Besides, the user can choose if they want you to save their card info.

> First off, on a new order, why wouldn't you just save the authorization
> code, instead of the credit card number? That would be a lot easier.

Sure. But see my above point. I want to be able to re-charge it later
when the user wants to.

> Secondly, you're opening yourself up to
> a _ton_ of lawsuits should anything go awry. Unless I had a _real_ good
> reason for storing their cc number, I wouldn't, despite the extra step.

Yes yes, lawsuits, scary, etc. I was looking for technical solutions,
i.e. maybe someone knows how USPS.com or Amazon.com or GoDaddy.com (do
they?) does it. Or if it is all security via obscurity.

Best solution yet:

Public key encryption, with additional either secret word padding or
using the users account password to pad/encrypt the card number
(preventing a brute force attack, even if access to the DB is given).

Beckman
------------------------------------------------------------ ---------------
Peter Beckman Internet Guy
beckman@purplecow.com http://www.purplecow.com/
------------------------------------------------------------ ---------------

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Storing Credit Cards, Passwords, Securely, two-way

On Fri, 6 Jan 2006, Julien Bonastre wrote:

> Any reason why you need to have reversible encryption on the password value??

No... I just prefer to assume that if someone gets my DB, they might try
using user/pass pairs on banking sites, or paypal, or other ways, and if I
can reversible encrypt the password, I can send them an email with their
password, rather than changing it to something obscure and force them to
change it again...

Though at this point, I just decided to md5 the password and call it good
enough. I'll just force them to change it if need be.

> Generally I simply create some hash from the password, using something akin
> to a MD5 or SHA1 hash of the password string. Or in my paranoid case I use
> the password string, plus all sorts of replicatable combinations of values
> such as length of password, username, registration date/time etc plus weird
> other fixed values I find around the place and environment variables etc,
> then I hash them..

A good idea; are you just careful then that you don't accidentally update
the data without re-hasing your passwords?

> I am completely psychotic so don't mind me, when I was 15 I wrote my Perl
> driven website http://operation-scifi.com [still Perl driven member system
> and file-system based forum] and I had a real mangler function whereby I
> would extract each character of the password and hash it, then hash the hash
> with the other characters, plus the hash of them with said fixed values from
> server/user account details [age, location etc..] ... It was something in the
> vicinity of a O(6^n+1)th generation hash by the time I had finished where n
> is the length of the original password..

*laugh* Awesome! Maybe a bit overkill for password, but still very cool.

Unfortunately that leaves things unreversable, and if someone got a hold
of your data AND your code, they could reverse-engineer... It seems
security is only as good as your weakest link -- obscure code, private
key, etc...

Beckman
------------------------------------------------------------ ---------------
Peter Beckman Internet Guy
beckman@purplecow.com http://www.purplecow.com/
------------------------------------------------------------ ---------------

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Storing Credit Cards, Passwords, Securely, two-wayencryption

>From: Peter Beckman
>To: Julien Bonastre
>CC: php-db@lists.php.net
>Subject: Re: [PHP-DB] Storing Credit Cards, Passwords, Securely,
>two-wayencryption
>Date: Thu, 5 Jan 2006 22:53:30 -0500 (EST)
>
>On Fri, 6 Jan 2006, Julien Bonastre wrote:
>
>>Any reason why you need to have reversible encryption on the password
>>value??
>
> No... I just prefer to assume that if someone gets my DB, they might try
> using user/pass pairs on banking sites, or paypal, or other ways, and if
>I
> can reversible encrypt the password, I can send them an email with their
> password, rather than changing it to something obscure and force them to
> change it again...
>
> Though at this point, I just decided to md5 the password and call it good
> enough. I'll just force them to change it if need be.

Really is the best way to handle it...change and force them to rechange when
logging in again..
May I recommend that you SALT the hash value by pre/appending a random
string to the value to prevent a straight dictionary attack.



Bastien

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Storing Credit Cards, Passwords, Securely, two-way encryption

> On Fri, 6 Jan 2006, Julien Bonastre wrote:
>
>> Any reason why you need to have reversible encryption on the password
>> value??
>
> No... I just prefer to assume that if someone gets my DB, they might
> try
> using user/pass pairs on banking sites, or paypal, or other ways, and
> if I
> can reversible encrypt the password, I can send them an email with
> their
> password, rather than changing it to something obscure and force them
> to
> change it again...
>
> Though at this point, I just decided to md5 the password and call it
> good
> enough. I'll just force them to change it if need be.
>
>> Generally I simply create some hash from the password, using
>> something akin to a MD5 or SHA1 hash of the password string. Or in my
>> paranoid case I use the password string, plus all sorts of
>> replicatable combinations of values such as length of password,
>> username, registration date/time etc plus weird other fixed values I
>> find around the place and environment variables etc, then I hash
>> them..
>
> A good idea; are you just careful then that you don't accidentally
> update
> the data without re-hasing your passwords?
>
>> I am completely psychotic so don't mind me, when I was 15 I wrote my
>> Perl driven website http://operation-scifi.com [still Perl driven
>> member system and file-system based forum] and I had a real mangler
>> function whereby I would extract each character of the password and
>> hash it, then hash the hash with the other characters, plus the hash
>> of them with said fixed values from server/user account details [age,
>> location etc..] ... It was something in the vicinity of a O(6^n+1)th
>> generation hash by the time I had finished where n is the length of
>> the original password..
>
> *laugh* Awesome! Maybe a bit overkill for password, but still very
> cool.
>
> Unfortunately that leaves things unreversable, and if someone got a
> hold
> of your data AND your code, they could reverse-engineer... It seems
> security is only as good as your weakest link -- obscure code,
> private
> key, etc...
>

Well, I still consider it irreversable due to the fact that it is an MD5
hash therefore generating the plainttext from a given ciphertext is
fairly slim unless as I mentioned certain dictionary plainttext words
are kept catalogued somewhere they can match too. But with the sheer
randomness of the plainttext this would never have been hashed before.

So even if someone knows my algorithm and has somehow obtained not only
the end result but also has the plainttext password and all the data I
use intermediate to creating my final hash value AND they can recompute
using all this the same final value.

This still does not help them figure out HOW to reverse just a stored
hash value which they do not know any of the values that were used in
its encryption, ie the password or user details.


Put simply: how do you reverse a hash? Its designed to be a one way
function: I give you:
fc3ff98e8c6a0d3087d515c0473f8677
86fb269d190d2c85f6e0468ceca42a20

First MD5 hash is the plainttext of "hello world!" the second is "Hello
world!"

One character difference, and if you do have an understanding of the
inner workings of the MD5 function you will already know the
implications a checksum works on and thereby it only requires a single
one bit of difference [no pun intended] to create a vastly different
checksum hash..


I am happy to place the security of my users within this field of near
impossibility and believe I have done everything in my power to ensure
even with the most simplest dictionary word password to start with, they
end up with a far more complex end hash therefore avoiding the largest
and by far easiest hash cracking method which is brute force dictionary
matching.


Meh, whats it all at the end of the day anyway..


Good questions about the credit card stuff though. I've encountered
similiar issues but decided to simply delegate paypal.com.au's services
to handling subscriptions, credit card payments etc... Their global,
safe, established and it works.

Its not perfect, but it'll do. For example a big problem is you can't
really have variable monthly payments, say your site provides a service
where you are sort of "billed" every month for what features you've
accessed, premium services you've used, how long you used them for etc,
much like your electricity bill or phone bill, well the only feature
paypal provides is its fixed rate subscription system.

Even with the API you can only really retrieve details and transaction
records, you can really edit the rate behind the scenes. The only method
is rather primitive and involves generating a link or form your user
will be displayed on your site which they follow, linking to a
subscription modification page on paypal with the new required values
all entered in.

Sure thats great but now thats the new rate per month. Not good if its a
very variable or fluctuating sort of service you provide with extras or
whatever..

The advantage? Paypal keeps all payment/accounting details on their
systems so its processed automatically. They can provide all the
necessary CC verification and so forth too and handle transactions via
bank/cheque etc..

Whereas the alternative payment system I am using goes through our bank
where we have a client account in which we use XML over HTTPS to submit
requests etc and basically we handle all the transactions, the bank
system simply does the bank work, verifies CC, does scheduled payments
etc, we get all the responses and then perform whatever actions we want
when we want and how much we want behind the scenes..


Anyway... back to work for me :)





> Beckman
> ------------------------------------------------------------ ---------------
> Peter Beckman
> Internet Guy
> beckman@purplecow.com
> http://www.purplecow.com/
> ------------------------------------------------------------ ---------------
>

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Storing Credit Cards, Passwords, Securely,

At 03:48 06/01/2006, you wrote:
>Date: Thu, 5 Jan 2006 22:48:24 -0500 (EST)
>From: Peter Beckman
>To: John Meyer
>cc: php-db@lists.php.net
>Message-ID: <20060105223828.G8551@thermonuclear.org>
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>Subject: Re: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-way
> encryption
>
>On Thu, 5 Jan 2006, John Meyer wrote:
>
>Peter Beckman wrote:
>So I'm thinking about how to save credit card numbers in the DB, for
>re-charging cards for subscriptions, new orders, etc.
>
> Yes yes, lawsuits, scary, etc.

I'm glad you're so blase about this and the threat of your business
going under due to exposure to extortion. When you've got the site
running, let me know the address, so I can advise my friends and
colleagues to avoid it at any cost.


>I was looking for technical solutions,
> i.e. maybe someone knows how USPS.com or Amazon.com or GoDaddy.com (do
> they?) does it. Or if it is all security via obscurity.


Security by obscurity is a myth. There is no such security, nor will
there ever be (think of MS DRM cracks for example on a supposedly
secure system). Any system that interacts with the outside world
*can* and eventually *will be cracked.

> Best solution yet:

Nope, no solution at all. *DO NOT* store any credit card numbers on
any publically accessible system. Ever. Period.

> Public key encryption, with additional either secret word padding or
> using the users account password to pad/encrypt the card number
> (preventing a brute force attack, even if access to the DB is given).

Prevents nothing. If somebody compromises your application server,
then own your "secret word padding" and can reverse the process to
extract some or all of the credit cards. Do not underestimate the
resourcefulness of bored people.

OK now to the candy : I've had this book a while, and it's one of the
most insightful and well researched (from experience) books on
security I've ever read. In fact - so good I'm going to go to the
trouble to retype an excerpt of a section called "One-Way Credit Card
Data Path for Top Security"


ISBN 0-13-0281870-5 [Prentice-Hall publishers]
Bob Toxen : Real World Linux Security [Now in 2nd edition]


====================
For many sites the most confidential information a customer can tell
the site is the customers credit card number and expiry date. Several
e-com sites (including some large ones) have had thousands of their
customers cc data stolen by crackers and have then had to respond to
extortion threats.

Most e-com sites keep the database of customer information on the
same system as the web server and CGI programs. This is begging for
trouble. Simply putting the database on a separate system is not
enough, because if CGI programs can attach to the database across the
e-com sites LAN, security has not been improved.

(Bob Toxen) have come up with the concept of a one-way credit card
data path. By this I mean that the credit card data flows only one
way, and that way is into the credit card server but >data never
flows out of the credit card server< (my emphasis) except over a
hardware path to the bank or service that is processing charge requests.

The cc system would be a (linux) system dedicated to this one
application. It would have NO other applications on it, because each
application would be a potential security hole. It would be hardened
for the highest security.

It would have a separate private LAN to the web server, and the web
server would have a separate dedicated NIC to this private LAN to
prevent sniffing (snipped section about spot welded steel pipes
encasing LAN cable !)

There would be >no< request implemented that would allow another
system to query for a complete CC number under any circumstance. Thus
neither a cracker hacking your web server, nor a disgruntled employee
could get the CC data from it. So long as there are no buffer
overflow vulns, this should be very secure, since there are no
services to crack, no passwords to crack, and spoofing would not work
because the system doesn't trust >any< other system at all.

When a customer establishes an account and specifies a CC, the CGI
sends the following message to the CC server :

ADD
user name
account number
cc type, number, expiry date, CCV#

When the customer wants to make a purchase, this is sent to the CC server

CHARGE
user name
account number
amount

The CC server then contacts the processing bank through the private
network to charge the amt, store the authorisastion number if
successful and returns either "Success" or an appropriate error message

Note that the comms link to the bank would be on a separate hardware
to the rest of the network, so if a cracker broke into the web or
order DB server, he could not >sniff< the network for these requests,
because they wouldn't be on that network.

If the user has multiple CCs on file, the following request might be used

LIST CARDS
user name
account number

The CC server would *only* reply with the last 3 digits, the rest
replaced with XXXX XXXX XXXX X319 for example

Obviously your web server should not retain any copies of the CC
numbers it handles. Use of encryption to and from the CC server is
recommended, as is IPTables locking down all ports except the CC and
SSH request ports on the CC server. The CC server code should be
audited for buffer overflow vulnerabilities, and run through Libsafe
to detect buffer overflow problems.

(followed by other stuff about social engineering and related admin issues)

====================

As Bob's book is so bloody good, here's the ASIN for it in case you
want to read all 650 pages of good advice ;-)
http://www.amazon.com/gp/product/0130464562/qid=1136589506/s r=8-1/ref=pd_bbs_1/104-3174210-9795945?n=507846

HTH
Cheers - Neil

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Storing Credit Cards, Passwords, Securely, two-way encryption

"Peter Beckman" wrote in message
news:20060105202254.X8551@thermonuclear.org...
> So I'm thinking about how to save credit card numbers in the DB, for
> re-charging cards for subscriptions, new orders, etc.
>
> I'm also thinking about how to save passwords in the DB, not plaintext,
> but
> not one-way encrypted either.
>
> Any suggestions? How would I secure the database? I'm thinking some
> abstract process in code, or something -- security through obscurity.

Suggestions? Oh, I've got some of them:

(1) Call VeriSign (just bought by PayPal)
(2) Do NOT store credit card numbers/dates/ccid's anywhere. (yes, that ends
in a PERIOD)
(2B) Obviously you will need to store the credit card data for a brief
while, so you can at least run the credit card. BUT, it shouldn't be stored
for any longer than a few hours (See #3 below)
(3) Using a service like VeriSign, when you get the credit card information,
run a charge of that card immediately (maybe a $1 handling charge). This
will give you a magic reference# assigned to that credit card data at the
service. VeriSign calls this a PNRef (I think). You can then use this
reference for all future charges to that same credit card.
(4) Make sure to get the billing zip code and street address for the credit
card. This reduces your cost per transaction.
(5) Did I mention to NOT store credit card numbers?

DanB

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Storing Credit Cards, Passwords, Securely,two-way encryption

Damn, Bob copied me...or me him...i forget, but that was the essence of what
I was attempting to let the OP know...when dealing with security you can
never be paranoid enough

Bastien



>From: "Neil Smith [MVP, Digital media]"
>To: php-db@lists.php.net
>CC: beckman@purplecow.com
>Subject: Re: [PHP-DB] Storing Credit Cards, Passwords, Securely,two-way
>encryption
>Date: Fri, 06 Jan 2006 23:52:25 +0000
>
>At 03:48 06/01/2006, you wrote:
>>Date: Thu, 5 Jan 2006 22:48:24 -0500 (EST)
>>From: Peter Beckman
>>To: John Meyer
>>cc: php-db@lists.php.net
>>Message-ID: <20060105223828.G8551@thermonuclear.org>
>>MIME-Version: 1.0
>>Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>>Subject: Re: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-way
>> encryption
>>
>>On Thu, 5 Jan 2006, John Meyer wrote:
>>
>>Peter Beckman wrote:
>>So I'm thinking about how to save credit card numbers in the DB, for
>>re-charging cards for subscriptions, new orders, etc.
>>
>> Yes yes, lawsuits, scary, etc.
>
>I'm glad you're so blase about this and the threat of your business going
>under due to exposure to extortion. When you've got the site running, let
>me know the address, so I can advise my friends and colleagues to avoid it
>at any cost.
>
>
>>I was looking for technical solutions,
>> i.e. maybe someone knows how USPS.com or Amazon.com or GoDaddy.com (do
>> they?) does it. Or if it is all security via obscurity.
>
>
>Security by obscurity is a myth. There is no such security, nor will there
>ever be (think of MS DRM cracks for example on a supposedly secure system).
>Any system that interacts with the outside world *can* and eventually *will
>be cracked.
>
> > Best solution yet:
>
>Nope, no solution at all. *DO NOT* store any credit card numbers on any
>publically accessible system. Ever. Period.
>
>> Public key encryption, with additional either secret word padding or
>> using the users account password to pad/encrypt the card number
>> (preventing a brute force attack, even if access to the DB is given).
>
>Prevents nothing. If somebody compromises your application server, then own
>your "secret word padding" and can reverse the process to extract some or
>all of the credit cards. Do not underestimate the resourcefulness of bored
>people.
>
>OK now to the candy : I've had this book a while, and it's one of the most
>insightful and well researched (from experience) books on security I've
>ever read. In fact - so good I'm going to go to the trouble to retype an
>excerpt of a section called "One-Way Credit Card Data Path for Top
>Security"
>
>
>ISBN 0-13-0281870-5 [Prentice-Hall publishers]
>Bob Toxen : Real World Linux Security [Now in 2nd edition]
>
>
>====================
>For many sites the most confidential information a customer can tell the
>site is the customers credit card number and expiry date. Several e-com
>sites (including some large ones) have had thousands of their customers cc
>data stolen by crackers and have then had to respond to extortion threats.
>
>Most e-com sites keep the database of customer information on the same
>system as the web server and CGI programs. This is begging for trouble.
>Simply putting the database on a separate system is not enough, because if
>CGI programs can attach to the database across the e-com sites LAN,
>security has not been improved.
>
>(Bob Toxen) have come up with the concept of a one-way credit card data
>path. By this I mean that the credit card data flows only one way, and that
>way is into the credit card server but >data never flows out of the credit
>card server< (my emphasis) except over a hardware path to the bank or
>service that is processing charge requests.
>
>The cc system would be a (linux) system dedicated to this one application.
>It would have NO other applications on it, because each application would
>be a potential security hole. It would be hardened for the highest
>security.
>
>It would have a separate private LAN to the web server, and the web server
>would have a separate dedicated NIC to this private LAN to prevent sniffing
>(snipped section about spot welded steel pipes encasing LAN cable !)
>
>There would be >no< request implemented that would allow another system to
>query for a complete CC number under any circumstance. Thus neither a
>cracker hacking your web server, nor a disgruntled employee could get the
>CC data from it. So long as there are no buffer overflow vulns, this should
>be very secure, since there are no services to crack, no passwords to
>crack, and spoofing would not work because the system doesn't trust >any<
>other system at all.
>
>When a customer establishes an account and specifies a CC, the CGI sends
>the following message to the CC server :
>
> ADD
> user name
> account number
> cc type, number, expiry date, CCV#
>
>When the customer wants to make a purchase, this is sent to the CC server
>
> CHARGE
> user name
> account number
> amount
>
>The CC server then contacts the processing bank through the private network
>to charge the amt, store the authorisastion number if successful and
>returns either "Success" or an appropriate error message
>
>Note that the comms link to the bank would be on a separate hardware to the
>rest of the network, so if a cracker broke into the web or order DB server,
>he could not >sniff< the network for these requests, because they wouldn't
>be on that network.
>
>If the user has multiple CCs on file, the following request might be used
>
> LIST CARDS
> user name
> account number
>
>The CC server would *only* reply with the last 3 digits, the rest replaced
>with XXXX XXXX XXXX X319 for example
>
>Obviously your web server should not retain any copies of the CC numbers it
>handles. Use of encryption to and from the CC server is recommended, as is
>IPTables locking down all ports except the CC and SSH request ports on the
>CC server. The CC server code should be audited for buffer overflow
>vulnerabilities, and run through Libsafe to detect buffer overflow
>problems.
>
>(followed by other stuff about social engineering and related admin issues)
>
>====================
>
>As Bob's book is so bloody good, here's the ASIN for it in case you want to
>read all 650 pages of good advice ;-)
>http://www.amazon.com/gp/product/0130464562/qid=1136589506/ sr=8-1/ref=pd_bbs_1/104-3174210-9795945?n=507846
>
>HTH
>Cheers - Neil
>
>--
>PHP Database Mailing List (http://www.php.net/)
>To unsubscribe, visit: http://www.php.net/unsub.php
>

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Storing Credit Cards, Passwords, Securely,two-way encryption

>> Yes yes, lawsuits, scary, etc.
>
> I'm glad you're so blase about this and the threat of your business
> going under due to exposure to extortion. When you've got the site
> running, let me know the address, so I can advise my friends and
> colleagues to avoid it at any cost.

>
>> Public key encryption, with additional either secret word padding
>> or
>> using the users account password to pad/encrypt the card number
>> (preventing a brute force attack, even if access to the DB is
>> given).
>
> Prevents nothing. If somebody compromises your application server,
> then own your "secret word padding" and can reverse the process to
> extract some or all of the credit cards. Do not underestimate the
> resourcefulness of bored people.
>

"Do not underestimate the resourcefulness of bored people."

These people aren't necessarily bored. Just more intelligent than
yourself and on a higher income :-)


Have you ever done any cryptanalysis? Have you ever succeeded if so?

Do you know some people are employed to actually experiment and test on
known modern cyptographic methods in order to ascertain their
effectiveness?

Rather than to live in your little world where everything is cherry and
pretty, most people of our profession are aware to the reality that we
can't all hide under 2048bit/2KB key length encryption utilities..

I am somewhat disappointed at the approach you are taking towards people
who are in the business and field of security and discovering and in
turn rectifying or improving existing security systems.


I guess its true then, ignorance IS bliss... Pretend the system IS safe,
and it must be! Don't ever let any of those "bored" people test the
limits of the system. Hell why benchmark cars, computers, military
weapons, athletes or anything for that matter!! As long as they "think"
they're the best, they MUST be!


Wake up mate!



> OK now to the candy : I've had this book a while, and it's one of the
> most insightful and well researched (from experience) books on
> security I've ever read. In fact - so good I'm going to go to the
> trouble to retype an excerpt of a section called "One-Way Credit Card
> Data Path for Top Security"
>
>
> ISBN 0-13-0281870-5 [Prentice-Hall publishers]
> Bob Toxen : Real World Linux Security [Now in 2nd edition]
>
>
> ====================
> For many sites the most confidential information a customer can tell
> the site is the customers credit card number and expiry date. Several
> e-com sites (including some large ones) have had thousands of their
> customers cc data stolen by crackers and have then had to respond to
> extortion threats.
>
> Most e-com sites keep the database of customer information on the same
> system as the web server and CGI programs. This is begging for
> trouble. Simply putting the database on a separate system is not
> enough, because if CGI programs can attach to the database across the
> e-com sites LAN, security has not been improved.
>
> (Bob Toxen) have come up with the concept of a one-way credit card
> data path. By this I mean that the credit card data flows only one
> way, and that way is into the credit card server but >data never flows
> out of the credit card server< (my emphasis) except over a hardware
> path to the bank or service that is processing charge requests.
>
> The cc system would be a (linux) system dedicated to this one
> application. It would have NO other applications on it, because each
> application would be a potential security hole. It would be hardened
> for the highest security.
>
> It would have a separate private LAN to the web server, and the web
> server would have a separate dedicated NIC to this private LAN to
> prevent sniffing (snipped section about spot welded steel pipes
> encasing LAN cable !)
>
> There would be >no< request implemented that would allow another
> system to query for a complete CC number under any circumstance. Thus
> neither a cracker hacking your web server, nor a disgruntled employee
> could get the CC data from it. So long as there are no buffer overflow
> vulns, this should be very secure, since there are no services to
> crack, no passwords to crack, and spoofing would not work because the
> system doesn't trust >any< other system at all.
>
> When a customer establishes an account and specifies a CC, the CGI
> sends the following message to the CC server :
>
> ADD
> user name
> account number
> cc type, number, expiry date, CCV#
>
> When the customer wants to make a purchase, this is sent to the CC
> server
>
> CHARGE
> user name
> account number
> amount
>
> The CC server then contacts the processing bank through the private
> network to charge the amt, store the authorisastion number if
> successful and returns either "Success" or an appropriate error
> message
>
> Note that the comms link to the bank would be on a separate hardware
> to the rest of the network, so if a cracker broke into the web or
> order DB server, he could not >sniff< the network for these requests,
> because they wouldn't be on that network.
>
> If the user has multiple CCs on file, the following request might be
> used
>
> LIST CARDS
> user name
> account number
>
> The CC server would *only* reply with the last 3 digits, the rest
> replaced with XXXX XXXX XXXX X319 for example
>
> Obviously your web server should not retain any copies of the CC
> numbers it handles. Use of encryption to and from the CC server is
> recommended, as is IPTables locking down all ports except the CC and
> SSH request ports on the CC server. The CC server code should be
> audited for buffer overflow vulnerabilities, and run through Libsafe
> to detect buffer overflow problems.
>
> (followed by other stuff about social engineering and related admin
> issues)
>
> ====================
>
> As Bob's book is so bloody good, here's the ASIN for it in case you
> want to read all 650 pages of good advice ;-)
> http://www.amazon.com/gp/product/0130464562/qid=1136589506/s r=8-1/ref=pd_bbs_1/104-3174210-9795945?n=507846
>
> HTH
> Cheers - Neil
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Storing Credit Cards, Passwords, Securely, two-way encryption

Peter wrote:

> So I'm thinking about how to save credit card numbers in the DB, for
> re-charging cards for subscriptions, new orders, etc.
> I'm also thinking about how to save passwords in the DB, not plaintext, but
> not one-way encrypted either.
> Any suggestions? How would I secure the database? I'm thinking some
> abstract process in code, or something -- security through obscurity.

if you need to perform the bank operations, then you can use GPG to
send you by e-mail the last 4 or 5 digits of a credit card when the
user makes the registration process or his first purchase.
In this way, you can have in your DB only a portion of the card number
and you can offer to the user a way to know his own card.
Although somebody can be able to enter in your system he cannot find
any complete information.

Anyway, if your system is compromised, any person can change your own
php scripts,etc... so be careful. If you can use Paypal or Bank it
is the best option because you are free of responsibility.

Note that although you can use Zend encoder or similar, anyone can
encode new scripts to supplant your owns. Also, he can obtain memory
dumps, reverse your secret-keys scripts, etc.. Unfortunately, until I
know, the popular encoders don't provide means to implement security
to authentify our own scripts, neither a way to protect passwords
residents in memory. Eventually, this utility
http://www.ossec.net/owl/ can monitor your webpages performing
periodical MD5 checksum but it is not a final solution if somebody is
inside your server.

Having a good security can be a very hard task while putting a Paypal
button is a trivial thing.


br,

Vicent,



--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Storing Credit Cards, Passwords, Securely, two-way

On Fri, 6 Jan 2006, Neil Smith [MVP, Digital media] wrote:

>> Peter Beckman wrote:
>> So I'm thinking about how to save credit card numbers in the DB, for
>> re-charging cards for subscriptions, new orders, etc.
>>
>> Yes yes, lawsuits, scary, etc.
>
> I'm glad you're so blase about this and the threat of your business going

Not blase -- just sick of hearing "don't do it" "you'll get sued"
"impossible" "what's wrong with you"

I want to secure this information, responsibly. How? (You answer this
below)

> Security by obscurity is a myth.

I believe you -- and if obscurity is a myth, let's document how it can be
done safely for all the world to see and learn!

> *DO NOT* store any credit card numbers on any publically accessible
> system. Ever. Period.

Sometimes when questions are asked a background of the knowledge of the
poster is not given. I would never do that. A server that is connected
to the internet directly storing credit cards is asking for a lawsuit.
It's got a sign with "please hack me" on it.

> OK now to the candy : I've had this book a while, and it's one of the most
> insightful and well researched (from experience) books on security I've ever
> read. In fact - so good I'm going to go to the trouble to retype an excerpt
> of a section called "One-Way Credit Card Data Path for Top Security"
>
> (Bob Toxen) have come up with the concept of a one-way credit card data path.

Now THAT is exactly what I was looking for -- THANKS! I'll go get the
book.

> (snipped section about spot welded steel pipes encasing LAN cable !)

*laugh* That might be a bit of overkill... but I get the idea.

> The CC server then contacts the processing bank through the private network
> to charge the amt, store the authorisastion number if successful and returns
> either "Success" or an appropriate error message

Obviously most CC auths are via the 'net + SSL, private networks don't
apply (and they are kind of cost prohibitive). If you have a
router/firewall/ipfw between your CC and the 'net, blocking incoming but
allowing outgoing to your cc auth host ip(s), is that good enough? What
else can be done?

> As Bob's book is so bloody good, here's the ASIN for it in case you want
> to read all 650 pages of good advice ;-)
> http://www.amazon.com/gp/product/0130464562/qid=1136589506/s r=8-1/ref=pd_bbs_1/104-3174210-9795945?n=507846

Thank you Neil -- sold!

Beckman
------------------------------------------------------------ ---------------
Peter Beckman Internet Guy
beckman@purplecow.com http://www.purplecow.com/
------------------------------------------------------------ ---------------

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Storing Credit Cards, Passwords, Securely, two-way

On Fri, 6 Jan 2006, Dan Baker wrote:

> "Peter Beckman" wrote in message
> news:20060105202254.X8551@thermonuclear.org...
>> So I'm thinking about how to save credit card numbers in the DB, for
>> re-charging cards for subscriptions, new orders, etc.
>>
>> I'm also thinking about how to save passwords in the DB, not plaintext,
>> but
>> not one-way encrypted either.
>>
>> Any suggestions? How would I secure the database? I'm thinking some
>> abstract process in code, or something -- security through obscurity.
>
> [Summary: Call Verisign, pay THEM to store credit cards for you]

What, exactly, does VeriSign do, that makes you so sure that they have
secured the credit card information any better than I could, using a
well-thought-out system? Do you even know? You just hear "VeriSign" and
believe they have smart people that have more resources available to them
to do a better job securing the data?

Maybe this makes sense if you are doing a few hundred or a few thousand
dollars of business a month, but if you are planning on doing $5,000 to
$10,000 a day, it is a lot of added expense to have someone else do it,
when I could have it done internally. It is the how.

Please, no more replies saying don't do it.

Beckman
------------------------------------------------------------ ---------------
Peter Beckman Internet Guy
beckman@purplecow.com http://www.purplecow.com/
------------------------------------------------------------ ---------------

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: Re: Storing Credit Cards, Passwords, Securely, two-wayencryption

> -----Original Message-----
> From: Peter Beckman [mailto:beckman@purplecow.com]
> Sent: Saturday, 7 January 2006 4:05 PM
> To: Dan Baker
> Cc: php-db@lists.php.net
> Subject: Re: [PHP-DB] Re: Storing Credit Cards, Passwords, Securely,
> two-wayencryption
>
> On Fri, 6 Jan 2006, Dan Baker wrote:
>
> > "Peter Beckman" wrote in message
> > news:20060105202254.X8551@thermonuclear.org...
> >> So I'm thinking about how to save credit card numbers in the DB, for
> >> re-charging cards for subscriptions, new orders, etc.
> >>
> >> I'm also thinking about how to save passwords in the DB, not plaintext,
> >> but not one-way encrypted either.
> >>
> >> Any suggestions? How would I secure the database? I'm thinking some
> >> abstract process in code, or something -- security through obscurity.
> >
> > [Summary: Call Verisign, pay THEM to store credit cards for you]
>
> What, exactly, does VeriSign do, that makes you so sure that they have
> secured the credit card information any better than I could, using a
> well-thought-out system? Do you even know? You just hear "VeriSign"
and
> believe they have smart people that have more resources available to
them
> to do a better job securing the data?

They don't. What they do have is more financial muscle to deal with a stuff
up of the nature that CardSystems perpetrated. Similarly because of the
scale they can afford to invest more $ (same proportion as you but much more
in absolute amounts) in R+D to protect against the downside.

> Maybe this makes sense if you are doing a few hundred or a few thousand
> dollars of business a month, but if you are planning on doing $5,000 to
> $10,000 a day, it is a lot of added expense to have someone else do it,
> when I could have it done internally. It is the how.

Sure, why give away margin if you can solve the issue locally.

> Please, no more replies saying don't do it.

Just do it with your eyes wide open. BTW you should get your legal eagles
to review the fine print of your gateway agreements to assess whether you
are "allowed" to store the information. Even if they explicitly prohibit
the storage of course you can go ahead and cache the numbers. But be warned
that should it all go pear shaped they will cut you loose to the hordes of
lawyers that will surely descend to feed on the carcass of your company.

On the subject of how to do it? The host of the CC numbers should at least
(i.e. not an exhaustive list) ...

a) Not be internet or internally facing. i.e.. in a physical DMZ with an
mains power connected to the keyboard :-) to stop casual users snooping
around,
b) perform no other tasks at all! No web surfing, no email, no nothing, only
backup in encrypted form.
c) seriously encrypt everything - no mickey mouse xor stuff,
d) must be firewalled from the web server with a keyhole open for
communication,
e) must perform all communications with the bank/gateway provider and only
return success/fail to the webserver - never ever return CC numbers! To bad
if you want to replay the number to the user.
f) log everything ideally on a one way basis to another server with worm
media and scan the logs frequently for weird stuff. Make sure it screams
like crazy if the log stream appears to be interfered with.

Hopefully with these sorts of controls the damage will be less than your
balance sheet can withstand. BTW you prolly won't get any insurance of this
risk unless you are prepared to pay a big premium - which defeats the
purpose!

Others no doubt will be able to add more control layers - these are just
what first comes to mind in a few minutes.

Bon voyage!
Frank.

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Storing Credit Cards, Passwords, Securely, two-wayencryption

------=_Part_91293_31161553.1136774130865
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I'm new to this list, so I'm not sure what has been kicked around in this
thread.

I just like to bring up that you need to mention on your page that you can
store their credit card for future convenience and if the user agrees with
that. You also should consider what to do when a credit card has expired. I
had one company add 3 years to my expired card and process a renewal
payment. That is not legal because it is not the information I have
provided... American Express had fun with those turkeys.

FWIW,

Gerry

------=_Part_91293_31161553.1136774130865--

RE: Storing Credit Cards, Passwords, Securely, two-wayencryption

Did you actually SNIP the "document[ation] how it can be done safely for all
the world to see and learn!" ??? Or are you saying go buy this book?

-----Original Message-----
From: Peter Beckman [mailto:beckman@purplecow.com]
Sent: Friday, January 06, 2006 10:54 PM
To: Neil Smith [MVP, Digital media]
Cc: php-db@lists.php.net
Subject: Re: [PHP-DB] Storing Credit Cards, Passwords, Securely,
two-wayencryption

On Fri, 6 Jan 2006, Neil Smith [MVP, Digital media] wrote:

>> Peter Beckman wrote:
>> So I'm thinking about how to save credit card numbers in the DB, for
>> re-charging cards for subscriptions, new orders, etc.
>>
>> Yes yes, lawsuits, scary, etc.
>
> I'm glad you're so blase about this and the threat of your business going

Not blase -- just sick of hearing "don't do it" "you'll get sued"
"impossible" "what's wrong with you"

I want to secure this information, responsibly. How? (You answer this
below)

> Security by obscurity is a myth.

I believe you -- and if obscurity is a myth, let's document how it can be
done safely for all the world to see and learn!

> *DO NOT* store any credit card numbers on any publically accessible
> system. Ever. Period.

Sometimes when questions are asked a background of the knowledge of the
poster is not given. I would never do that. A server that is connected
to the internet directly storing credit cards is asking for a lawsuit.
It's got a sign with "please hack me" on it.

> OK now to the candy : I've had this book a while, and it's one of the most

> insightful and well researched (from experience) books on security I've
ever
> read. In fact - so good I'm going to go to the trouble to retype an
excerpt
> of a section called "One-Way Credit Card Data Path for Top Security"
>
> (Bob Toxen) have come up with the concept of a one-way credit card data
path.

Now THAT is exactly what I was looking for -- THANKS! I'll go get the
book.

> (snipped section about spot welded steel pipes encasing LAN cable !)

*laugh* That might be a bit of overkill... but I get the idea.

> The CC server then contacts the processing bank through the private
network
> to charge the amt, store the authorisastion number if successful and
returns
> either "Success" or an appropriate error message

Obviously most CC auths are via the 'net + SSL, private networks don't
apply (and they are kind of cost prohibitive). If you have a
router/firewall/ipfw between your CC and the 'net, blocking incoming but
allowing outgoing to your cc auth host ip(s), is that good enough? What
else can be done?

> As Bob's book is so bloody good, here's the ASIN for it in case you want
> to read all 650 pages of good advice ;-)
>
http://www.amazon.com/gp/product/0130464562/qid=1136589506/s r=8-1/ref=pd_bbs
_1/104-3174210-9795945?n=507846

Thank you Neil -- sold!

Beckman
------------------------------------------------------------ ---------------
Peter Beckman Internet Guy
beckman@purplecow.com http://www.purplecow.com/
------------------------------------------------------------ ---------------

--

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Storing Credit Cards, Passwords, Securely, two-wayencryption

"Peter Beckman" wrote in message
news:20060106235409.B8551@thermonuclear.org...
> On Fri, 6 Jan 2006, Dan Baker wrote:
>
>> "Peter Beckman" wrote in message
>> news:20060105202254.X8551@thermonuclear.org...
>>> So I'm thinking about how to save credit card numbers in the DB, for
>>> re-charging cards for subscriptions, new orders, etc.
>>>
>>> I'm also thinking about how to save passwords in the DB, not plaintext,
>>> but
>>> not one-way encrypted either.
>>>
>>> Any suggestions? How would I secure the database? I'm thinking some
>>> abstract process in code, or something -- security through obscurity.
>>
>> [Summary: Call Verisign, pay THEM to store credit cards for you]
>
> What, exactly, does VeriSign do, that makes you so sure that they have
> secured the credit card information any better than I could, using a
> well-thought-out system? Do you even know? You just hear "VeriSign" and
> believe they have smart people that have more resources available to them
> to do a better job securing the data?
>
> Maybe this makes sense if you are doing a few hundred or a few thousand
> dollars of business a month, but if you are planning on doing $5,000 to
> $10,000 a day, it is a lot of added expense to have someone else do it,
> when I could have it done internally. It is the how.
>
> Please, no more replies saying don't do it.

VeriSign (and other similar organizations) have pro's and con's. Obviously,
the con's are usually tied to the big $.
VeriSign costs $70/month (for the first 1000 transactions per month). My
company is in the 1000 transaction per month range, but I think each
transaction after that is $0.10. BTW, VeriSign was just bought by PayPal.

You have to pay every credit card company you do business with, no mater
what solution to select. Usually a % of the total charges. If you do
enough business per card, your % drops. Also, if you don't include enough
information with each transaction, your % will be increased. The most
important information you need to include is: billing address and billing
zip code -- most credit card company's won't increase your % if you provide
these two pieces of information per transaction. CSC's (CVV2) are usually
not tied to your % payment, and it is illegal to store them.

You ask: "What exactly does VeriSign do?" I don't know. I pay them $70
each month, and they process my credit cards. I know they have been in the
business a long time, and experience means a lot (to me). Some how, I can
re-run a charge on an already-run credit card, and they magically know all
the information for that credit card (including the CSC). We sell a service
that people pay monthly for, and we make up the $70 to VeriSign in reduced
%.

You mentioned that it "makes sense if you are doing a few hundred dollars a
month". This seems backward to me. It is too expensive if you only doing a
few hundred dollars a month. The $70 a month disappears as you do *more*
business. If you are doing $10,000 a day, you need to call each credit card
company you do business with (Amex, Discover) and ask for a "Rate Review".
They will surely drop their % if you are doing that kind of volume. We just
had a rate review with Amex, and our rate dropped significantly.

Oh --- You also need to check on your merchant account. They usually hit
you per transaction. This is were the $ can start to add up! Your merchant
account may also be handing your Visa/MC transactions, and taking a % of
those -- so ask for a rate review from them also.

And last of all, I know of a pretty large company that uses a service
similar to VeriSign. This other service (can't remember the name) didn't
provide the "PNRef" scenario, so the company stores credit card numbers in
their database (encrypted of course), and they just run the numbers every
month for their service. Seems to be working ok for them. I don't know who
wrote their software, what encryption they are using, where the data is
stored, how it is backed up -- I guess I don't know anything except they are
storing credit card numbers and are currently doing a good business. Funny,
they are still paying for a similar service to VeriSign.

DanB

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: Storing Credit Cards, Passwords, Securely,

>From: "Dwight Altman"
>To: "'Peter Beckman'" ,
> "'Neil Smith [MVP, Digital media]'"
>Cc:
>Date: Mon, 9 Jan 2006 09:24:05 -0600
>Message-ID: <000c01c61530$c3744bb0$0e00a8c0@MARKETING2>
>MIME-Version: 1.0
>Content-Type: text/plain;
> charset="us-ascii"
>Content-Transfer-Encoding: 7bit
>Subject: RE: [PHP-DB] Storing Credit Cards, Passwords, Securely,
>two-wayencryption
>
>Did you actually SNIP the "document[ation] how it can be done safely for all
>the world to see and learn!" ??? Or are you saying go buy this book?

No, I retyped the passage in its entirety from the book. Learn to
SNIP your posts !

Cheers - Neil

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Storing Credit Cards, Passwords, Securely, two-wayencryption

> On 1/9/06, Dan Baker wrote: And last of all, I
> know of a pretty large company that uses a service
> similar to VeriSign. This other service (can't remember the name) didn't
> provide the "PNRef" scenario, so the company stores credit card numbers in
> their database (encrypted of course), and they just run the numbers every
> month for their service. Seems to be working ok for them. I don't know
> who
> wrote their software, what encryption they are using, where the data is
> stored, how it is backed up -- I guess I don't know anything except they
> are
> storing credit card numbers and are currently doing a good business. DanB



> This confuses me, I thought storing the CSC was illegal?
> Don't you need that to run the card?
>
> Charles Morris
> cmorris@cs.odu.edu



The CSC (Card Security Code) or CVV (Card Verification Value) is NOT needed
to run any credit cards. It is simply a method to increase the likelihood
that the human at the other end of the transaction actually has the phyiscal
card. Storing CSC/CVV's is illegal. I believe that even places like
VeriSign do not store the CSC. Really, the only information you need to run
a credit card is the number and expiration date (although you will pay a
higher %).

DanB

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Storing Credit Cards, Passwords, Securely, two-way encryption

Neil made a great post about storing credit card data at your own site
securely. I thought I'd add a note: If you do implement his suggestion,
I'd suggest adding a Reference type situation:
(1) When you add credit card data to the system, have it return a valid
Reference to that credit card. This Reference is only valid within your
office.
(2) Store the credit card Reference with the end-user record (for monthly
billing)
(3) To run a monthly billing, simply send the credit card Reference, with
the $amt to your secure credit card server for processing. It keeps the
log, and returns a simple SUCCESS or ERROR return

Note: Make sure to store the billing data with that credit card #, so you
keep your rates down.

DanB

Neil Smith [MVP, Digital media] wrote:
[SNIP]
As Bob's book is so bloody good, here's the ASIN for it in case you
want to read all 650 pages of good advice ;-)
http://www.amazon.com/gp/product/0130464562/qid=1136589506/s r=8-1/ref=pd_bbs_1/104-3174210-9795945?n=507846

HTH
Cheers - Neil

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php