php-general Digest 30 May 2010 07:12:20 -0000 Issue 6772
Topics (messages 305639 through 305644):
Re: Convert UTF-8 to PHP defines
305639 by: Nisse Engström
get classname without namespace
305640 by: Tanel Tammik
305641 by: Nilesh Govindarajan
Credit Card encryption
305642 by: Paul M Foster
305643 by: Ashley Sheridan
305644 by: Adam Richardson
Administrivia:
To subscribe to the digest, e-mail:
[email protected]
To unsubscribe from the digest, e-mail:
[email protected]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
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 ?
/Nisse
--- End Message ---
--- Begin Message ---
Hi,
is there a way to get the called classname without the namespace?
<?php
//PHP 5.3.x
namespace some\where;
abstract class ParentClass {
public static function name() {
return strtolower(get_called_class());
}
public static function get_name() {
echo 'name: ' . static::name();
}
}
class ChildClass extends ParentClass {
}
ChildClass::get_name();
?>
the result i need: childclass
the result i get: some\where\childclass
also is it possible to get the name() into the static variable if only
static method is called?
Br
Tanel
--- End Message ---
--- Begin Message ---
On Sun, May 30, 2010 at 1:50 AM, Tanel Tammik <[email protected]> wrote:
> Hi,
>
> is there a way to get the called classname without the namespace?
>
> <?php
> //PHP 5.3.x
> namespace some\where;
>
> abstract class ParentClass {
> public static function name() {
> return strtolower(get_called_class());
> }
>
> public static function get_name() {
> echo 'name: ' . static::name();
> }
> }
>
> class ChildClass extends ParentClass {
> }
>
> ChildClass::get_name();
> ?>
>
> the result i need: childclass
> the result i get: some\where\childclass
>
> also is it possible to get the name() into the static variable if only
> static method is called?
>
> Br
> Tanel
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
You need to extract that using strrpos and substr
$name = substr($fullname_with_namespace,
strrpos($fullname_with_namespace, '/'));
--
Nilesh Govindarajan
Facebook: nilesh.gr
Twitter: nileshgr
Website: www.itech7.com
--- End Message ---
--- Begin Message ---
This question is for people who take and store credit card information
for customers.
Credit card companies, in an attempt to lessen fraud, are tightening the
screws on merchants who take credit cards. One aspect of this is a
requirement to store credit card information from customers encrypted.
So let's say you have a customer whose credit card you keep on file,
because they'll be charging other items with you. The credit card
companies would like you to store this information with strong
encryption, which in their mind is one-way encryption.
Now let's say that the credit card number is part of the customer
record. When looking at the customer record, you see just the last four
digits of the card. But when editing the record or when printing out
reports of things which must be charged, you will see the whole number.
Assume the users of the system have logins and passwords.
Now if you one-way encrypt the credit card numbers in the customer
records, then it seems to me that any time that field has to be accessed
(to edit the record or charge something to the card), you'd have to have
the user enter a specific "password" to unlock the encryption. This
would be quite in addition to their username and password. Moreover for
this to be as secure as the credit card companies would like it,
whatever "password" is used would need to be changed frequently,
particularly at any change of personnel. This means you'd have to
re-encrypt all the credit card numbers using the new "password" every
few months or when you fire someone who had access to the data.
This seems like an excessively cumbersome solution. Is this seriously
the way it's done? Does anyone have a better solution?
Paul
--
Paul M. Foster
--- End Message ---
--- Begin Message ---
On Sun, 2010-05-30 at 01:49 -0400, Paul M Foster wrote:
> This question is for people who take and store credit card information
> for customers.
>
> Credit card companies, in an attempt to lessen fraud, are tightening the
> screws on merchants who take credit cards. One aspect of this is a
> requirement to store credit card information from customers encrypted.
>
> So let's say you have a customer whose credit card you keep on file,
> because they'll be charging other items with you. The credit card
> companies would like you to store this information with strong
> encryption, which in their mind is one-way encryption.
>
> Now let's say that the credit card number is part of the customer
> record. When looking at the customer record, you see just the last four
> digits of the card. But when editing the record or when printing out
> reports of things which must be charged, you will see the whole number.
> Assume the users of the system have logins and passwords.
>
> Now if you one-way encrypt the credit card numbers in the customer
> records, then it seems to me that any time that field has to be accessed
> (to edit the record or charge something to the card), you'd have to have
> the user enter a specific "password" to unlock the encryption. This
> would be quite in addition to their username and password. Moreover for
> this to be as secure as the credit card companies would like it,
> whatever "password" is used would need to be changed frequently,
> particularly at any change of personnel. This means you'd have to
> re-encrypt all the credit card numbers using the new "password" every
> few months or when you fire someone who had access to the data.
>
> This seems like an excessively cumbersome solution. Is this seriously
> the way it's done? Does anyone have a better solution?
>
>
> Paul
>
> --
> Paul M. Foster
>
It's not just a matter of encrypting the credit card details. You also
have to ensure the server meets specific security requirements, every
last little bit of software has to be updated and patched. There are
services that will check your server out for you (last one I used was
McAffee Secure) I am certain that this is a legal requirement in order
to allow you to process credit card details.
You won't have to encrypt the password against the username of whoever
has access to it. Just encrypt it the once, and use the DBMS side of
things to manage access rights. Maybe use a couple of fields in the DB
to store the credit card number in two versions, one that is two-way
encrypted, the second that is one-way. You can set up your web system to
only have access to the one-way version, meaning that the actual number
can't be got by that user. The two-way encrypted version would be
accessible only by a specific second DB user, the access details of
which could change when personnel changes.
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
On Sun, May 30, 2010 at 2:16 AM, Ashley Sheridan
<[email protected]>wrote:
> On Sun, 2010-05-30 at 01:49 -0400, Paul M Foster wrote:
>
> > This question is for people who take and store credit card information
> > for customers.
> >
> > Credit card companies, in an attempt to lessen fraud, are tightening the
> > screws on merchants who take credit cards. One aspect of this is a
> > requirement to store credit card information from customers encrypted.
> >
> > So let's say you have a customer whose credit card you keep on file,
> > because they'll be charging other items with you. The credit card
> > companies would like you to store this information with strong
> > encryption, which in their mind is one-way encryption.
> >
> > Now let's say that the credit card number is part of the customer
> > record. When looking at the customer record, you see just the last four
> > digits of the card. But when editing the record or when printing out
> > reports of things which must be charged, you will see the whole number.
> > Assume the users of the system have logins and passwords.
> >
> > Now if you one-way encrypt the credit card numbers in the customer
> > records, then it seems to me that any time that field has to be accessed
> > (to edit the record or charge something to the card), you'd have to have
> > the user enter a specific "password" to unlock the encryption. This
> > would be quite in addition to their username and password. Moreover for
> > this to be as secure as the credit card companies would like it,
> > whatever "password" is used would need to be changed frequently,
> > particularly at any change of personnel. This means you'd have to
> > re-encrypt all the credit card numbers using the new "password" every
> > few months or when you fire someone who had access to the data.
> >
> > This seems like an excessively cumbersome solution. Is this seriously
> > the way it's done? Does anyone have a better solution?
> >
> >
> > Paul
> >
> > --
> > Paul M. Foster
> >
>
>
> It's not just a matter of encrypting the credit card details. You also
> have to ensure the server meets specific security requirements, every
> last little bit of software has to be updated and patched. There are
> services that will check your server out for you (last one I used was
> McAffee Secure) I am certain that this is a legal requirement in order
> to allow you to process credit card details.
>
> You won't have to encrypt the password against the username of whoever
> has access to it. Just encrypt it the once, and use the DBMS side of
> things to manage access rights. Maybe use a couple of fields in the DB
> to store the credit card number in two versions, one that is two-way
> encrypted, the second that is one-way. You can set up your web system to
> only have access to the one-way version, meaning that the actual number
> can't be got by that user. The two-way encrypted version would be
> accessible only by a specific second DB user, the access details of
> which could change when personnel changes.
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>
Hi Paul,
When you describe one-way or two-way encryption, what are you describing?
Are you describing hashing vs encryption where the plain-text is
recoverable with a key, or are you describing symmetric (one key handles
encrypting and decrypting) vs asymmetric (separate keys handle encrypting
and decrypting) encryption?
Now if you one-way encrypt the credit card numbers in the customer
records, then it seems to me that any time that field has to be accessed
(to edit the record or charge something to the card), you'd have to have
the user enter a specific "password" to unlock the encryption.
You can't decrypt (or "unlock") a hashed password (at least if you used a
secure hash), but I'm not sure you're talking about symmetric vs asymmetric
encryption, either. With more details , I can provide feedback on the
encryption schemes you're considering (remember, you have to make sure that
you are managing encryption keys very carefully, as among other things, PCI
requires that "keys are stored in encrypted format and that key- encrypting
keys are stored separately from data- encrypting keys.")
However, I'd strongly recommend letting a payment gateway do the heavy
lifting. You let the payment gateway store the credit card details, and
when you want to process another transaction for a visitor, you use the id
for the visitor that's stored in your DB (if they already have set up an
account) to process the request.
For example, this type of scheme is documented at Rackspace (PDF):
http://cloudsites.rackspacecloud.com/index.php/Can_I_host_a_PCI_compliant_site_on_Cloud_Sites%3F
Adam
--
Nephtali: PHP web framework that functions beautifully
http://nephtaliproject.com
--- End Message ---
