php-general Digest 1 Jun 2010 13:57:38 -0000 Issue 6776
Topics (messages 305677 through 305682):
Re: Credit Card encryption
305677 by: Waynn Lue
305679 by: Paul M Foster
305680 by: Paul M Foster
305681 by: Peter Lind
305682 by: Paul M Foster
Re: Convert UTF-8 to PHP defines
305678 by: Angus Mann
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
Billing Address (at least the street number) is used in conjunction
with the zip code for AVS checks.
On 5/31/10, tedd <tedd.sperl...@gmail.com> wrote:
> At 1:38 AM -0400 5/31/10, Paul M Foster wrote:
>>On Sun, May 30, 2010 at 10:50:05AM -0400, tedd wrote:
>>
>> > Besides, most credit card processing agencies even require that you
>>> use the customer's data (cc number, expiry date and CCS) to make the
>>> sale and then immediately dispose of it afterwards, usually within 24
>>> hours under a signed agreement. Holding that information for more
>>> than 24 hours can be a criminal offense regardless of what type of
>>> hashing you use.
>>
>>Not true. It depends on the type of merchant and the situation.
>
> *blink*
>
> "Not true" and "It depends" are conflicts in logic.
>
> Either what I said is "true" or it isn't -- and if what I said is
> "true" for some (as it is and I can prove it) then what I said is
> indeed "true".
>
> I'm curious, why say it's not "true" and then follow with "it
> depends"? It appears to me that you have your mind made-up and don't
> care to listen to our experiences and recommendations.
>
> That's Okay, but I'm simply telling you what I KNOW to be true. You
> may either accept what I have to say, or reject it, but to reply that
> what I say is "Not true" is somewhat offensive and confrontational. I
> hope you didn't mean it that way. :-)
>
>
>>The PCI
>>validation process allows for storage of all data except the 3-4 digit
>>validation number. What I'm asked for at transaction time is the CC
>>number, expiration date, digits for the billing address, and the billing
>>zip code. And I can get the address and zip digits completely wrong and
>>still have the transaction go through.
>
> Party true.
>
> What data are used in credit card transactions are the: name of the
> card holder, credit card number, expiration date, CCV number, and zip
> code. I have not dealt with any credit card processors that require
> the billing address -- they just use the zip code. Additionally, it
> is up to the client to determine the level of security they want.
> They *can* require that *all* information be correct before accepting
> a sale.
>
> The downside of not requiring *all* the data to be correct is that
> the rate the credit processor charges for the transaction rises.
> Simply and logically put, if you don't get all the information
> correct, then there is risk and that risk is passed on to the client
> via an elevated charge for processing -- look it up.
>
> The up-side of getting only the minimal data is getting a sale under
> a higher risk/rate -- that's the clients choice and they usually
> choose it.
>
>>We've been doing it this way for 14 years and using the type of service
>>you suggest would be expensive and impractical. Only in the last two
>>years has PCI become more stringent in their requirements. And
>>consequently, I'm having to re-evaluate how we store this particular
>>information. Otherwise, our physical and other security is more than
>>adequate. Yes, of course, if you have a machine gun or you're Kevin
>>Mitnick, or you have a network of 20,000 bots pounding on my router,
>>you're coming in anyway. Again, this is about *reasonable* security.
>
> You asked for opinions -- do what you want. :-)
>
> Cheers,
>
> tedd
>
> --
> -------
> http://sperling.com http://ancientstones.com http://earthstones.com
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Sent from my mobile device
--- End Message ---
--- Begin Message ---
On Mon, May 31, 2010 at 12:36:55PM -0400, tedd wrote:
> At 1:38 AM -0400 5/31/10, Paul M Foster wrote:
>> On Sun, May 30, 2010 at 10:50:05AM -0400, tedd wrote:
>>
>> > Besides, most credit card processing agencies even require that you
>>> use the customer's data (cc number, expiry date and CCS) to make the
>>> sale and then immediately dispose of it afterwards, usually within 24
>>> hours under a signed agreement. Holding that information for more
>>> than 24 hours can be a criminal offense regardless of what type of
>>> hashing you use.
>>
>> Not true. It depends on the type of merchant and the situation.
>
> *blink*
>
> "Not true" and "It depends" are conflicts in logic.
>
> Either what I said is "true" or it isn't -- and if what I said is
> "true" for some (as it is and I can prove it) then what I said is
> indeed "true".
>
> I'm curious, why say it's not "true" and then follow with "it
> depends"? It appears to me that you have your mind made-up and don't
> care to listen to our experiences and recommendations.
>
> That's Okay, but I'm simply telling you what I KNOW to be true. You
> may either accept what I have to say, or reject it, but to reply that
> what I say is "Not true" is somewhat offensive and confrontational. I
> hope you didn't mean it that way. :-)
Okay, let me be precise, then. I have no idea whether "most credit
processing agencies... require...." I haven't dealt with "most credit
processing agencies", so I have no way of knowing. And in fact, I don't also
know
whether "holding that information for more than 24 hours can be a
criminal offense...." This may be a criminal offense where you live, and
it may be a criminal offense in Zambatootie as well. Since I'm not
familiar with every jurisdiction, I can't vouch for where or when it is
a criminal offense.
I do know, however, that according to the PCI DSS FAQ, storing a credit
card number is discouraged, but not disallowed. Given the proper
cryptographic treatment, it is definitely allowed. This also jibes with
the self-evaluation questionnaire which Level 4 merchants (like myself)
must complete yearly.
>
>
>> The PCI
>> validation process allows for storage of all data except the 3-4 digit
>> validation number. What I'm asked for at transaction time is the CC
>> number, expiration date, digits for the billing address, and the billing
>> zip code. And I can get the address and zip digits completely wrong and
>> still have the transaction go through.
>
> Party true.
>
> What data are used in credit card transactions are the: name of the
> card holder, credit card number, expiration date, CCV number, and zip
> code. I have not dealt with any credit card processors that require
> the billing address -- they just use the zip code. Additionally, it
> is up to the client to determine the level of security they want.
> They *can* require that *all* information be correct before accepting
> a sale.
When you say "client" in this context, what do you mean? The ultimate
customer, the company issuing the credit card, the bank, the merchant
service company?
>
> The downside of not requiring *all* the data to be correct is that
> the rate the credit processor charges for the transaction rises.
> Simply and logically put, if you don't get all the information
> correct, then there is risk and that risk is passed on to the client
> via an elevated charge for processing -- look it up.
I have been told repeatedly by my merchant service company that my rates
do not and will not rise, should my "verification information" be
incorrect. I have been told repeatedly that the collection of this
information is for *my* benefit, to lessen the chances of *me* being
defrauded.
>
> The up-side of getting only the minimal data is getting a sale under
> a higher risk/rate -- that's the clients choice and they usually
> choose it.
Again, I'm not sure the definition of client as you are using it.
However, I am aware that MOTO merchants (those who take credit cards
over the phone, etc. and never have a physical card), like myself, pay
higher rates than those who swipe them. Part of the game.
Paul
--
Paul M. Foster
--- End Message ---
--- Begin Message ---
On Mon, May 31, 2010 at 05:06:23PM -0400, tedd wrote:
> At 12:36 PM -0400 5/31/10, I wrote:
>> That's Okay, but I'm simply telling you what I KNOW to be true. You
>> may either accept what I have to say, or reject it, but to reply
>> that what I say is "Not true" is somewhat offensive and
>> confrontational. I hope you didn't mean it that way. :-)
>
> My apologies for taking what you said as I did and my reply -- it was
> wrong of me. I am sure you didn't mean anything offensive.
You are correct. I meant no offense. In turn, when I read your post, it
appeared that you were making a blanket statement applicable under all
conditions, to which I objected. However, reading back over it, you did
insert qualifiers.
Paul
--
Paul M. Foster
--- End Message ---
--- Begin Message ---
Just wondering: seems there's a bit of a misunderstanding going on
here. Are you talking about storing credit card information in a way
such that customers can do online transactions without entering that
information? Or are you talking about storing this information so your
own company can fill in the details on a monthly basis?
If 1) then the above points apply and you should not store the data,
period. If 2) then I would assume the situation is somewhat different
- though, not knowing the laws from the US I wouldn't really know.
Regards
Peter
--
<hype>
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
BeWelcome/Couchsurfing: Fake51
Twitter: http://twitter.com/kafe15
</hype>
--- End Message ---
--- Begin Message ---
On Tue, Jun 01, 2010 at 09:52:54AM +0200, Peter Lind wrote:
> Just wondering: seems there's a bit of a misunderstanding going on
> here. Are you talking about storing credit card information in a way
> such that customers can do online transactions without entering that
> information? Or are you talking about storing this information so your
> own company can fill in the details on a monthly basis?
> If 1) then the above points apply and you should not store the data,
> period. If 2) then I would assume the situation is somewhat different
> - though, not knowing the laws from the US I wouldn't really know.
No to #1, yes to #2.
As for #1, companies like Godaddy do store this information, so I know
it can be safely done.
But no, we do #2. If we were doing #1, I would turn this over to some
gateway and not save the info.
I'm not sure any of this has to do with laws. It has more to do with the
PSS and the rules of individual credit card companies (Visa, American
Express, etc.).
Paul
--
Paul M. Foster
--- End Message ---
--- Begin Message ---
Dear Sir/Madam
Please unsubscribe Angus Mann angusm...@pobox.com from your database. My
husband passed away 6 May 2010.
Thank you
Sonya Mann
----- Original Message -----
From: "tedd" <tedd.sperl...@gmail.com>
To: <php-gene...@lists.php.net>
Sent: Monday, May 31, 2010 12:20 AM
Subject: Re: [PHP] Convert UTF-8 to PHP defines
At 10:20 PM +0200 5/29/10, Nisse =?utf-8?Q?Engstr=C3=B6m?= wrote:
On Sat, 29 May 2010 10:16:39 -0400, tedd wrote:
At 7:15 AM +0200 5/29/10, Nisse =?utf-8?Q?Engstr=C3=B6m?= wrote:
No. There are no glyphs in Unicode. This is spelled out for
you in chapter 2, figure 2-2. "Characters versus Glyphs".
Code points are simply unique numbers assigned to specific characters
in an approved char set. To better understand which character is
represented a representative Glyph is used -- what else would we use,
Right. I should have phrased that differently.
a chicken?
U+9e21 ? U+540D ?
LOL
I forgot that the word chicken appears in several other languages as a
single character. Interesting to note that in the Chinese Dictionary, the
character "U+9e21" Chicken (ji) is interchangeable with prostitution.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
