You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by MJH <mj...@liminalflux.net> on 2004/08/10 00:31:20 UTC
Date parsing (was Re: [mp2 milestones] installment 1)
On Friday 28 May 2004 01:36 pm, Stas Bekman wrote:
> >>http://perl.apache.org/docs/2.0/api/APR/Date.html
> > Are these parsers any faster than the perl module ones? (Ie. any reason
> > for using these over Date::Time or similar?)
>
> They are written in C, so if Date::Time is not, APR::Date is probably
> faster. But don't take my word for granted as I didn't benchmark -- run
> Benchmark.pm and post your findings to the list for the rest to know.
> Thanks!
I finally got chance to do this, here's the results from parsing
'Sun, 06 Nov 1994 08:49:37 GMT', with 10000 iterations using
Benchmark::timethis. There's actually quite a number of different date
parsing modules on cpan, each of which does something slightly different.
Date::Parse::str2time
3 wallclock secs ( 3.58 usr + 0.01 sys = 3.59 CPU) @ 2785.52/s
Time::ParseDate::parsedate
4 wallclock secs ( 3.35 usr + 0.01 sys = 3.36 CPU) @ 2976.19/s
Date::Manip::ParseDate
63 wallclock secs (63.12 usr 0.02 sys + 0.01 cusr 0.01 csys = 63.16 CPU) @
158.38/s
APR::Date::parse_rfc:
0 wallclock secs ( 0.04 usr + 0.00 sys = 0.04 CPU) @ 250000.00/s
APR::Date::parse_http:
0 wallclock secs ( 0.03 usr + 0.00 sys = 0.03 CPU) @ 333333.33/s
So, assuming the date you have is either HTTP-compliant or RFC822-compliant,
then the APR::Date functions are orders of magnitude faster.
Hopefully this is of use to someone.
--
There's only one corner of the universe you can be certain of improving,
and that's your own self.
- Aldous Huxley
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Date parsing speeds
Posted by MJH <mj...@liminalflux.net>.
On Monday 9 August 2004 07:01 pm, Stuart Johnston wrote:
> Would you be willing to add other modules to your benchmark? I would be
> interested to see how HTTP::Date and DateTime::Format::HTTP (which uses
> HTTP::Date) compare.
Again for a 10,000 iteration test:
Date::Parse::str2time
4 wallclock secs ( 3.80 usr + 0.02 sys = 3.82 CPU)
Time::ParseDate::parsedate
3 wallclock secs ( 3.47 usr + 0.02 sys = 3.49 CPU)
APR::Date::parse_rfc:
0 wallclock secs ( 0.04 usr + 0.00 sys = 0.04 CPU)
APR::Date::parse_http:
0 wallclock secs ( 0.03 usr + 0.00 sys = 0.03 CPU)
DateTime::Format::HTTP:
11 wallclock secs (11.03 usr + 0.00 sys = 11.03 CPU)
HTTP::Date:
1 wallclock secs ( 0.59 usr + 0.00 sys = 0.59 CPU)
(for DateTime::Format::HTTP the call tested was actually
"$class->parse_datetime('Sun, 06 Nov 1994 08:49:37 GMT')->epoch;" as what I
was benchmarking is conversion to epoch time).
--
"Reality is that which, when you stop believing in it, doesn't go away."
- Philip K. Dick
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Date parsing speeds
Posted by "Malcolm J. Harwood" <mj...@liminalflux.net>.
On Monday 9 August 2004 07:01 pm, Stuart Johnston wrote:
> Would you be willing to add other modules to your benchmark? I would be
> interested to see how HTTP::Date and DateTime::Format::HTTP (which uses
> HTTP::Date) compare.
Again for a 10,000 iteration test:
Date::Parse::str2time
4 wallclock secs ( 3.80 usr + 0.02 sys = 3.82 CPU)
Time::ParseDate::parsedate
3 wallclock secs ( 3.47 usr + 0.02 sys = 3.49 CPU)
APR::Date::parse_rfc:
0 wallclock secs ( 0.04 usr + 0.00 sys = 0.04 CPU)
APR::Date::parse_http:
0 wallclock secs ( 0.03 usr + 0.00 sys = 0.03 CPU)
DateTime::Format::HTTP:
11 wallclock secs (11.03 usr + 0.00 sys = 11.03 CPU)
HTTP::Date:
1 wallclock secs ( 0.59 usr + 0.00 sys = 0.59 CPU)
(for DateTime::Format::HTTP the call tested was actually
"$class->parse_datetime('Sun, 06 Nov 1994 08:49:37 GMT')->epoch;" as what I
was benchmarking is conversion to epoch time).
--
"Reality is that which, when you stop believing in it, doesn't go away."
- Philip K. Dick
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Date parsing speeds
Posted by "Malcolm J. Harwood" <mj...@liminalflux.net>.
On Monday 9 August 2004 07:01 pm, Stuart Johnston wrote:
> Would you be willing to add other modules to your benchmark? I would be
> interested to see how HTTP::Date and DateTime::Format::HTTP (which uses
> HTTP::Date) compare.
Again for a 10,000 iteration test:
Date::Parse::str2time
4 wallclock secs ( 3.80 usr + 0.02 sys = 3.82 CPU)
Time::ParseDate::parsedate
3 wallclock secs ( 3.47 usr + 0.02 sys = 3.49 CPU)
APR::Date::parse_rfc:
0 wallclock secs ( 0.04 usr + 0.00 sys = 0.04 CPU)
APR::Date::parse_http:
0 wallclock secs ( 0.03 usr + 0.00 sys = 0.03 CPU)
DateTime::Format::HTTP:
11 wallclock secs (11.03 usr + 0.00 sys = 11.03 CPU)
HTTP::Date:
1 wallclock secs ( 0.59 usr + 0.00 sys = 0.59 CPU)
(for DateTime::Format::HTTP the call tested was actually
"$class->parse_datetime('Sun, 06 Nov 1994 08:49:37 GMT')->epoch;" as what I
was benchmarking is conversion to epoch time).
--
"Reality is that which, when you stop believing in it, doesn't go away."
- Philip K. Dick
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Date parsing (was Re: [mp2 milestones] installment 1)
Posted by Stuart Johnston <sj...@vaultranet.com>.
MJH wrote:
> On Friday 28 May 2004 01:36 pm, Stas Bekman wrote:
>
>
>>>>http://perl.apache.org/docs/2.0/api/APR/Date.html
>
>
>>>Are these parsers any faster than the perl module ones? (Ie. any reason
>>>for using these over Date::Time or similar?)
>>
>>They are written in C, so if Date::Time is not, APR::Date is probably
>>faster. But don't take my word for granted as I didn't benchmark -- run
>>Benchmark.pm and post your findings to the list for the rest to know.
>>Thanks!
>
>
> I finally got chance to do this, here's the results from parsing
> 'Sun, 06 Nov 1994 08:49:37 GMT', with 10000 iterations using
> Benchmark::timethis. There's actually quite a number of different date
> parsing modules on cpan, each of which does something slightly different.
Would you be willing to add other modules to your benchmark? I would be
interested to see how HTTP::Date and DateTime::Format::HTTP (which uses
HTTP::Date) compare.
Thanks,
Stuart Johnston
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: APR::Base64 uses
Posted by Trond Michelsen <mi...@crusaders.no>.
On Tue, Aug 10, 2004 at 04:00:58PM -0700, Bart Simpson wrote:
>> APR::Base64 and APR::URI look pretty
>> useful too.
> What are some practical uses of APR::Base64? Encoding
> credit card nums before storing in DB? Passwords?
Well, Basic Authentication uses Base64 to encode the username/password
string, so this is probably why it's part of the Apache api.
> describes it as encoder/decoder of strings but leave
> actual uses to the imagination of the programmer. I'm
> particular in need of encrypting/encoding credit card
> nums before storing them and am curios what this
> module is and is not appropriate for.
First of all, base64 encoding is useless for encrypting data. It is
easy to recognise, and it's easy to decode. It's probably safer to
store the cc-numbers in plain text, but backwards.
Then again, encryption won't do you much good either, if it's
automatically decrypted by a program. If an intruder manages to get
access to your data, he'll probably gain access to your program as
well, which in turn will give him full access to all your encrypted
data.
The best thing is if you can avoid storing the CC-numbers at
all. Where I work, we only store an encrypted key. When the customer
first enters the CC-details, we encrypt the data using our merchant
certificate, and send it to our acquirer, and we get back a key. We
never store the CC number anywhere. The key itself can not be used to
get back the CC number. But we use this key when we want to charge the
customer. The key is also locked to our account, so they will be
completely useless to an intruder.
--
Trond Michelsen
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: APR::Base64 uses
Posted by mock <mo...@obscurity.org>.
On Wed, Aug 11, 2004 at 01:01:23AM -0700, Bart Simpson wrote:
>
> --- mock <mo...@obscurity.org> wrote:
>
> > This is about to go out to CPAN, but since it seems
> > there is some question
> > as to how to do this, I'll send it out a little
> > early. Attached is a module
> > for safely encrypting and storing credit cards using
> > the Business::OnlinePayment
> > interface. It uses a public RSA key and
> > Crypt::OpenSSL::RSA to encrypt a
> > randomly generated Blowfish symetric key, which is
> > used with Crypt::CBC to
> > encrypt the creditcard details. Also included is a
> > module for reversing the
> > transaction given the RSA private key. This allows
> > one to store creditcards
> > safely on the server, by not putting the private RSA
> > key on the same machine.
> > To retrieve the cards, simply pull the data to an
> > offline machine, and
> > decrypt using the RSA private key. Assuming you
> > aren't an idiot and leave
> > the private key somewhere internet accessible, this
> > should be as proof against
> > hackers as any other credit card processing.
> >
> > enjoy
> >
> > mock
> >
>
> This sounds really awesome. Thanks. just what we need.
>
> Can one key decrypt the whole batch of cards?
>
Yes, you only need one RSA public/private key pair to decrypt everything.
There's a script included in the tarball to make the key pair.
mock
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: APR::Base64 uses
Posted by Perrin Harkins <pe...@elem.com>.
On Wed, 2004-08-11 at 13:36, Chris Ochs wrote:
> It's basically just an ssl connection to our gateway
> passing the correct parameters. We do not use a separate client like
> Verisign does for their api product.
That's actually what Verisign does now too, at least with their PayFlow
Pro product. They just provide a client that makes the HTTPS connection
for you.
> Two factor is commonly considered something you have, and something you
> know. The most common method is to use a hardware token such as a smart
> card which generates one time passwords that can be used to login.
That's enough to convince me that I never want to store credit cards
myself...
- Perrin
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: APR::Base64 uses
Posted by Chris Ochs <ch...@paymentonline.net>.
> On Wed, 2004-08-11 at 11:53, Chris Ochs wrote:
> > I thought I would chime in here. Many are probably not aware of the new
> > security regulations by Visa and Mastercard that are now in effect.
>
> Thanks for the info, Chris. Is Payment Online a Verisign competitor?
> Does it have a mod_perl-friendly API?
>
Yes I would say we are a competitor, and we do have a perl api that works
fine under mod perl. It's basically just an ssl connection to our gateway
passing the correct parameters. We do not use a separate client like
Verisign does for their api product.
> > Among the requirements, all card data must be encrypted and stored on a
> > server that is not directly connected to the internet
>
> I assume a database server would qualify as long it's on a separate
> machine from your web app.
Yes, as long as it's not directly reachable from the public internet, such
as behind a nat that is itself behind a screened subnet.
>
> > you have to use two factor authentication for all
> > remote access
>
> What counts as two factor authentication here? Something like IP
> address and password? Or do you have to plug some physical key into the
> web server so it can access the database?
Two factor is commonly considered something you have, and something you
know. The most common method is to use a hardware token such as a smart
card which generates one time passwords that can be used to login. I highly
recommend Cryptocard myself. RSA has their SecureID, but at 10X the price
and less flexibility.
Chris
>
> - Perrin
>
>
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: APR::Base64 uses
Posted by Perrin Harkins <pe...@elem.com>.
On Wed, 2004-08-11 at 11:53, Chris Ochs wrote:
> I thought I would chime in here. Many are probably not aware of the new
> security regulations by Visa and Mastercard that are now in effect.
Thanks for the info, Chris. Is Payment Online a Verisign competitor?
Does it have a mod_perl-friendly API?
> Among the requirements, all card data must be encrypted and stored on a
> server that is not directly connected to the internet
I assume a database server would qualify as long it's on a separate
machine from your web app.
> you have to use two factor authentication for all
> remote access
What counts as two factor authentication here? Something like IP
address and password? Or do you have to plug some physical key into the
web server so it can access the database?
- Perrin
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: APR::Base64 uses
Posted by Chris Ochs <ch...@paymentonline.net>.
I thought I would chime in here. Many are probably not aware of the new
security regulations by Visa and Mastercard that are now in effect.
Basically, anyone who stores or handles credit card data has to comply. If
you use an online processing company such as Verisign they take care of most
of it for you (you still have to have a third party do a security scan once
a year on your servers), but if you handle or store the cards yourself, be
prepared for some hefty fines if you get hacked or found out and have not
gone through the certificate procedures.
Among the requirements, all card data must be encrypted and stored on a
server that is not directly connected to the internet (NAT/PAT is acceptable
but there cannot be any direct routes from the internet to the storage
server), you have to employ a good firewall such as a screened subnet in
conjunction with NAT/PAT, you have to use two factor authentication for all
remote access, you have to have documented security policies, code reviews,
etc etc.. And on top of all that you have to pay an approved third party to
audit all of the above which isn't cheap.
Visa/Mastercard are leaving it up to the discretion of the merchant banks as
to forcing compliance. Most smaller merchant's won't be forced to go
through all of this, but the stickler is that if you are hacked, all the
requirements and fines still apply.
Chris
----- Original Message -----
From: "mock" <mo...@obscurity.org>
To: "Geoffrey Young" <ge...@modperlcookbook.org>
Cc: "Modperl List" <mo...@perl.apache.org>
Sent: Tuesday, August 10, 2004 11:58 PM
Subject: Re: APR::Base64 uses
> On Tue, Aug 10, 2004 at 08:57:14PM -0400, Geoffrey Young wrote:
> >
> > >>but hiding the decryption key from technical people is generally
> > >>impossible
> > >
> > >
> > > Only if they crack your application server. Cracking the database or
> > > sniffing packets would not be good enough, assuming traffic to your
> > > credit card company is over SSL.
> >
> > oh, sure.
> >
> > I guess I had a different mindset with all of that - internal employees.
> > for most big companies I would assume that accessing the underlying
Oracle
> > financials database (or some other "enterprise" solution) with _all_ the
> > credit card numbers would be sufficiently difficult for outside hackers.
> > I'd be much more worried about the disgruntled employee causing trouble.
> >
> > but you're right - crackers are a legitimate concern for this kind of
thing,
> > and I wasn't aware of the role that verisign is now playing (which I
guess
> > is the cost of having worked someplace where we built everything from
> > scratch). so, thanks for the knowledge :)
> >
> > --Geoff
> >
> > --
> > Report problems: http://perl.apache.org/bugs/
> > Mail list info: http://perl.apache.org/maillist/modperl.html
> > List etiquette: http://perl.apache.org/maillist/email-etiquette.html
> >
>
> This is about to go out to CPAN, but since it seems there is some question
> as to how to do this, I'll send it out a little early. Attached is a
module
> for safely encrypting and storing credit cards using the
Business::OnlinePayment
> interface. It uses a public RSA key and Crypt::OpenSSL::RSA to encrypt a
> randomly generated Blowfish symetric key, which is used with Crypt::CBC to
> encrypt the creditcard details. Also included is a module for reversing
the
> transaction given the RSA private key. This allows one to store
creditcards
> safely on the server, by not putting the private RSA key on the same
machine.
> To retrieve the cards, simply pull the data to an offline machine, and
> decrypt using the RSA private key. Assuming you aren't an idiot and leave
> the private key somewhere internet accessible, this should be as proof
against
> hackers as any other credit card processing.
>
> enjoy
>
> mock
>
----------------------------------------------------------------------------
----
> --
> Report problems: http://perl.apache.org/bugs/
> Mail list info: http://perl.apache.org/maillist/modperl.html
> List etiquette: http://perl.apache.org/maillist/email-etiquette.html
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: APR::Base64 uses
Posted by mock <mo...@obscurity.org>.
On Wed, Aug 11, 2004 at 09:36:42AM -0400, Perrin Harkins wrote:
> mock wrote:
> >This is about to go out to CPAN, but since it seems there is some question
> >as to how to do this, I'll send it out a little early. Attached is a
> >module
> >for safely encrypting and storing credit cards using the
> >Business::OnlinePayment
> >interface.
>
> Public key encryption is the best that can be done here, but even so, if
> a cracker compromises your machine, he can just add a "warn $cc_number"
> in your code before you encrypt it. Your old cards will be safe though.
>
> - Perrin
It's (almost) exactly equivalent to any other credit card processing. The
blackhat in question could add a warn statement to any credit card processing
(unless it's a third party payment system like PayPal). The only other
risk with this system is that if you lose your private key then the security
is compromised. This really isn't an additional risk, as the credit card
processors you are relying on have the exact same problem. There is the
additional problem with external processors, in that they are often
vulnerable to man in the middle attacks, which if I was a h/cracker (which I
suppose I am at times -- come to our security conference in Tokyo in November
http://www.pacsec.jp -- shameless plug) would be the first place I'd attack.
As you said though, your old cards will be safe.
mock
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: APR::Base64 uses
Posted by Perrin Harkins <pe...@elem.com>.
mock wrote:
> This is about to go out to CPAN, but since it seems there is some question
> as to how to do this, I'll send it out a little early. Attached is a module
> for safely encrypting and storing credit cards using the Business::OnlinePayment
> interface.
Public key encryption is the best that can be done here, but even so, if
a cracker compromises your machine, he can just add a "warn $cc_number"
in your code before you encrypt it. Your old cards will be safe though.
- Perrin
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: APR::Base64 uses
Posted by mock <mo...@obscurity.org>.
On Wed, Aug 11, 2004 at 08:23:42AM -0500, JupiterHost.Net wrote:
>
> >
> >This sounds really awesome. Thanks. just what we need.
> >
> >Can one key decrypt the whole batch of cards?
>
> I didn't look to close but I'm thinking "no" since it was randomly
> generated, and a single key for them all would again make it pointless
> to do anything with it because all they need now is one piece of data to
> see all the CC info. Instead of one per record.
>
> Just my .02 ;p
>
> Lee.M - JupiterHost.Net
>
The blowfish keys are randomly generated for each transaction, but the RSA keys
remain the same. Business::OnlinePayment::StoredTransaction::Unstore
uses the RSA private key to decrypt each blowfish key, then uses that blowfish
key to decrypt the transaction. Thus, as far as the module user is concerned
the keys remain the same.
If you want something that uses a separate key for each transaction, I have
another module which effectively accomplishes this, but it's not ready for
production yet. I'm not sure why you'd want this though, as it becomes a
key management nightmare.
BTW, I will be talking about a bunch of new tricks for credit card processing
at YAPC::Europe this year, as well as, (just to bring the topic back to
mod_perl) the experience I had building an MTA using Apache and mod_perl.
mock
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: APR::Base64 uses
Posted by "JupiterHost.Net" <ml...@jupiterhost.net>.
>
> This sounds really awesome. Thanks. just what we need.
>
> Can one key decrypt the whole batch of cards?
I didn't look to close but I'm thinking "no" since it was randomly
generated, and a single key for them all would again make it pointless
to do anything with it because all they need now is one piece of data to
see all the CC info. Instead of one per record.
Just my .02 ;p
Lee.M - JupiterHost.Net
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: APR::Base64 uses
Posted by Bart Simpson <ba...@yahoo.com>.
--- mock <mo...@obscurity.org> wrote:
> On Tue, Aug 10, 2004 at 08:57:14PM -0400, Geoffrey
> Young wrote:
> >
> > >>but hiding the decryption key from technical
> people is generally
> > >>impossible
> > >
> > >
> > > Only if they crack your application server.
> Cracking the database or
> > > sniffing packets would not be good enough,
> assuming traffic to your
> > > credit card company is over SSL.
> >
> > oh, sure.
> >
> > I guess I had a different mindset with all of that
> - internal employees.
> > for most big companies I would assume that
> accessing the underlying Oracle
> > financials database (or some other "enterprise"
> solution) with _all_ the
> > credit card numbers would be sufficiently
> difficult for outside hackers.
> > I'd be much more worried about the disgruntled
> employee causing trouble.
> >
> > but you're right - crackers are a legitimate
> concern for this kind of thing,
> > and I wasn't aware of the role that verisign is
> now playing (which I guess
> > is the cost of having worked someplace where we
> built everything from
> > scratch). so, thanks for the knowledge :)
> >
> > --Geoff
> >
> > --
> > Report problems: http://perl.apache.org/bugs/
> > Mail list info:
> http://perl.apache.org/maillist/modperl.html
> > List etiquette:
> http://perl.apache.org/maillist/email-etiquette.html
> >
>
> This is about to go out to CPAN, but since it seems
> there is some question
> as to how to do this, I'll send it out a little
> early. Attached is a module
> for safely encrypting and storing credit cards using
> the Business::OnlinePayment
> interface. It uses a public RSA key and
> Crypt::OpenSSL::RSA to encrypt a
> randomly generated Blowfish symetric key, which is
> used with Crypt::CBC to
> encrypt the creditcard details. Also included is a
> module for reversing the
> transaction given the RSA private key. This allows
> one to store creditcards
> safely on the server, by not putting the private RSA
> key on the same machine.
> To retrieve the cards, simply pull the data to an
> offline machine, and
> decrypt using the RSA private key. Assuming you
> aren't an idiot and leave
> the private key somewhere internet accessible, this
> should be as proof against
> hackers as any other credit card processing.
>
> enjoy
>
> mock
>
This sounds really awesome. Thanks. just what we need.
Can one key decrypt the whole batch of cards?
> ATTACHMENT part 2 application/x-tar-gz
> --
> Report problems: http://perl.apache.org/bugs/
> Mail list info:
> http://perl.apache.org/maillist/modperl.html
> List etiquette:
http://perl.apache.org/maillist/email-etiquette.html
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: APR::Base64 uses
Posted by mock <mo...@obscurity.org>.
On Tue, Aug 10, 2004 at 08:57:14PM -0400, Geoffrey Young wrote:
>
> >>but hiding the decryption key from technical people is generally
> >>impossible
> >
> >
> > Only if they crack your application server. Cracking the database or
> > sniffing packets would not be good enough, assuming traffic to your
> > credit card company is over SSL.
>
> oh, sure.
>
> I guess I had a different mindset with all of that - internal employees.
> for most big companies I would assume that accessing the underlying Oracle
> financials database (or some other "enterprise" solution) with _all_ the
> credit card numbers would be sufficiently difficult for outside hackers.
> I'd be much more worried about the disgruntled employee causing trouble.
>
> but you're right - crackers are a legitimate concern for this kind of thing,
> and I wasn't aware of the role that verisign is now playing (which I guess
> is the cost of having worked someplace where we built everything from
> scratch). so, thanks for the knowledge :)
>
> --Geoff
>
> --
> Report problems: http://perl.apache.org/bugs/
> Mail list info: http://perl.apache.org/maillist/modperl.html
> List etiquette: http://perl.apache.org/maillist/email-etiquette.html
>
This is about to go out to CPAN, but since it seems there is some question
as to how to do this, I'll send it out a little early. Attached is a module
for safely encrypting and storing credit cards using the Business::OnlinePayment
interface. It uses a public RSA key and Crypt::OpenSSL::RSA to encrypt a
randomly generated Blowfish symetric key, which is used with Crypt::CBC to
encrypt the creditcard details. Also included is a module for reversing the
transaction given the RSA private key. This allows one to store creditcards
safely on the server, by not putting the private RSA key on the same machine.
To retrieve the cards, simply pull the data to an offline machine, and
decrypt using the RSA private key. Assuming you aren't an idiot and leave
the private key somewhere internet accessible, this should be as proof against
hackers as any other credit card processing.
enjoy
mock
Re: APR::Base64 uses
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>>but hiding the decryption key from technical people is generally
>>impossible
>
>
> Only if they crack your application server. Cracking the database or
> sniffing packets would not be good enough, assuming traffic to your
> credit card company is over SSL.
oh, sure.
I guess I had a different mindset with all of that - internal employees.
for most big companies I would assume that accessing the underlying Oracle
financials database (or some other "enterprise" solution) with _all_ the
credit card numbers would be sufficiently difficult for outside hackers.
I'd be much more worried about the disgruntled employee causing trouble.
but you're right - crackers are a legitimate concern for this kind of thing,
and I wasn't aware of the role that verisign is now playing (which I guess
is the cost of having worked someplace where we built everything from
scratch). so, thanks for the knowledge :)
--Geoff
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: APR::Base64 uses
Posted by Perrin Harkins <pe...@elem.com>.
On Tue, 2004-08-10 at 20:01, Geoffrey Young wrote:
> that really depends on your business - if you are, say, an ISP that invoices
> clients monthly asking them to give your a CC number each month is not
> exactly customer friendly :)
Verisign, and undoubtedly others, will store it for you and give you an
ID that you can use to charge against it later. This means that someone
who compromises your server can't do anything but make more charges that
would be transferred to your company's bank account. They also offer an
API for setting up recurring monthly charges without keeping the
numbers.
> at $company we did not encrypt credit card data, which surprised many
> people.
The big problem is that if someone gets in, and takes the credit card
numbers, then a big newspaper story gets published saying that your
company didn't encrypt card numbers and you look irresponsible.
> but hiding the decryption key from technical people is generally
> impossible
Only if they crack your application server. Cracking the database or
sniffing packets would not be good enough, assuming traffic to your
credit card company is over SSL.
> sure encrypting it keeps it out of the hands of your sales
> people and CSRs. well, unless you let those people add or change credit
> card information, in which case they could be writing them down all day...
They could be writing down new ones that they are asked to add, but not
old ones.
- Perrin
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: APR::Base64 uses
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>>I'm
>>particular in need of encrypting/encoding credit card
>>nums before storing them
>
>
> Two-way encryption? Blowfish, with Crypt::CBC. Storing credit cards is
> a bad idea though.
that really depends on your business - if you are, say, an ISP that invoices
clients monthly asking them to give your a CC number each month is not
exactly customer friendly :)
at $company we did not encrypt credit card data, which surprised many
people. but hiding the decryption key from technical people is generally
impossible, and it turned out to be very convenient on many occasions to
have all the client information when resolving various types of elevated
client problems. sure encrypting it keeps it out of the hands of your sales
people and CSRs. well, unless you let those people add or change credit
card information, in which case they could be writing them down all day...
the point is that storing them at all is in many cases necessary, but by
encrypting the data you're not eliminating risk at all, just reducing it
(and very slightly at that). arguing whether simply reducing risk is a good
thing (more barriers) or is a bad thing (false sense of security - ask me in
person some time) is something that people/managers/businesses need to
decide for themselves.
for those interested, "The Art of the Steal" is a facinating read on this
kind of thing :)
--Geoff
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: APR::Base64 uses
Posted by "JupiterHost.Net" <ml...@jupiterhost.net>.
>>You don't use google then do you?
>>;p probably msn or yahoo, or gulp AOL :)
>
> CMON, would Bart Simpson use anything but the Google?
> Never used yahoo but MSN,AOL ??? That's insulting. EAt
> my shorts man . LOL =)
HAHA good one :) !
>
>>google had ads but they are way more discreet and
>>talk about relevant
>>results, wow its awesome!
>>
>
>
> Google is awesome. The ads i was refering to were ads
> on webpages at google's results. IN the comparison i
> was making Google results is book or TOC, Web page
> correlates to Book page -- get it?? . most web pages
> have ads, Except modperls and other open source
> projects which is a good reason to be thankful for
> developing with open source. Speaking of developing,
> i'd better get back to work. ONe more thing below.
>
I see ;p
>>Anyway I can see the Dead Tree approach of course,
>>the smell is nice :)
>>
>>Lee.M - JupiterHost.Net
>>
>
> Books have undeniable charms. I'm still waiting for
> the rubber laptop . I'm tired of waking up with sharp
> jabbing in my gut.
>
> Later, lots of fun talking with you.
>
>
> BTW: You say "Dead tree" instead of "Dead Hemp Plant"
> only because the US Gov. effectively outlawed the most
> industrious plant on the planet in 1937 in one of the
> biggest conspiracies by Gov. and Corporations in
> modern history. see "Emperor Wears No Clothes" by
> Jack Herer or email me off list if anyone has time to
> discuss that topic.
[homer] mmmm hemp underwear [/homer]
Couldn' t have everyone rolling up their dictionaries and attending book
burnings every week now could we :)
Ok, now back to Perl so its not 100% OT :
use Hemp;
while very usefull would definately be abused by the masses of hippy
programmers hence why its not on cpan either :(
Ok, all finished with the fun! Thanks for the laugh bart
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: APR::Base64 uses
Posted by Bart Simpson <ba...@yahoo.com>.
--- "JupiterHost.Net" <ml...@jupiterhost.net> wrote:
> >>
> >>You used paper? Did someone break Google? :)
> >>http://www.google.com/search?q=define%3Aencode
> >>http://www.google.com/search?q=define%3Aencrypt
> >
>
> [snip]
>
> > stuff on the way to what i'm looking for. Doing a
> web
> > search , i see a little on what i was looking for
> only
> > and a great deal of ads.
>
> You don't use google then do you?
> ;p probably msn or yahoo, or gulp AOL :)
CMON, would Bart Simpson use anything but the Google?
Never used yahoo but MSN,AOL ??? That's insulting. EAt
my shorts man . LOL =)
> google had ads but they are way more discreet and
> talk about relevant
> results, wow its awesome!
>
Google is awesome. The ads i was refering to were ads
on webpages at google's results. IN the comparison i
was making Google results is book or TOC, Web page
correlates to Book page -- get it?? . most web pages
have ads, Except modperls and other open source
projects which is a good reason to be thankful for
developing with open source. Speaking of developing,
i'd better get back to work. ONe more thing below.
> Anyway I can see the Dead Tree approach of course,
> the smell is nice :)
>
> Lee.M - JupiterHost.Net
>
Books have undeniable charms. I'm still waiting for
the rubber laptop . I'm tired of waking up with sharp
jabbing in my gut.
Later, lots of fun talking with you.
BTW: You say "Dead tree" instead of "Dead Hemp Plant"
only because the US Gov. effectively outlawed the most
industrious plant on the planet in 1937 in one of the
biggest conspiracies by Gov. and Corporations in
modern history. see "Emperor Wears No Clothes" by
Jack Herer or email me off list if anyone has time to
discuss that topic.
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: APR::Base64 uses
Posted by "JupiterHost.Net" <ml...@jupiterhost.net>.
>>
>>You used paper? Did someone break Google? :)
>>http://www.google.com/search?q=define%3Aencode
>>http://www.google.com/search?q=define%3Aencrypt
>
[snip]
> stuff on the way to what i'm looking for. Doing a web
> search , i see a little on what i was looking for only
> and a great deal of ads.
You don't use google then do you?
;p probably msn or yahoo, or gulp AOL :)
google had ads but they are way more discreet and talk about relevant
results, wow its awesome!
Anyway I can see the Dead Tree approach of course, the smell is nice :)
Lee.M - JupiterHost.Net
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: APR::Base64 uses
Posted by Bart Simpson <ba...@yahoo.com>.
--- Perrin Harkins <pe...@elem.com> wrote:
> Bart Simpson wrote:
> > OK. its good for Encoding as in changing forms
> but
> > not hiding from other readers. I think i get the
> > difference. Encode does not imply any secrecy or
> > privacy where as encrypt does.
>
> Right.
>
> > Aside [
> > I looked encode and cryptography (encrypt wasn't
> in my
> > webster collegiate paperback)
>
> You used paper? Did someone break Google? :)
> http://www.google.com/search?q=define%3Aencode
> http://www.google.com/search?q=define%3Aencrypt
HEE hee. i knew someone would say this. it is pretty
silly to look up those two word in print book and
expect to get a good response. I was kind of after the
pure definitions and also I like print books, this
especially applies to dictionaries, because i see new
stuff on the way to what i'm looking for. Doing a web
search , i see a little on what i was looking for only
and a great deal of ads.
> For a detailed discussion of encryption and Perl,
> pick up O'Reilly's
> Mastering Algorithms with Perl. It's a good book,
> with a whole chapter
> discussing encryption.
>
> - Perrin
>
thanks , i'll check it out.
> --
> Report problems: http://perl.apache.org/bugs/
> Mail list info:
> http://perl.apache.org/maillist/modperl.html
> List etiquette:
> http://perl.apache.org/maillist/email-etiquette.html
>
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: APR::Base64 uses
Posted by Perrin Harkins <pe...@elem.com>.
Bart Simpson wrote:
> OK. its good for Encoding as in changing forms but
> not hiding from other readers. I think i get the
> difference. Encode does not imply any secrecy or
> privacy where as encrypt does.
Right.
> Aside [
> I looked encode and cryptography (encrypt wasn't in my
> webster collegiate paperback)
You used paper? Did someone break Google? :)
http://www.google.com/search?q=define%3Aencode
http://www.google.com/search?q=define%3Aencrypt
For a detailed discussion of encryption and Perl, pick up O'Reilly's
Mastering Algorithms with Perl. It's a good book, with a whole chapter
discussing encryption.
- Perrin
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: APR::Base64 uses
Posted by Bart Simpson <ba...@yahoo.com>.
--- Perrin Harkins <pe...@elem.com> wrote:
> On Tue, 2004-08-10 at 19:00, Bart Simpson wrote:
> > What are some practical uses of APR::Base64?
>
> Sending binary data in ASCII.
>
> > Encoding
> > credit card nums before storing in DB? Passwords?
>
>
> No. It's not encryption.
>
OK. its good for Encoding as in changing forms but
not hiding from other readers. I think i get the
difference. Encode does not imply any secrecy or
privacy where as encrypt does.
Aside [
I looked encode and cryptography (encrypt wasn't in my
webster collegiate paperback) up before i posted to
try to understand the difference and it said this
leaving me not very much more enlightened.
"encode" = "to convert (a message) into code"
"cryptography" = "the encoding and decoding of secret
messages"
the two seemed pretty synonomous to me but now i see i
didn't place enough importance on the lack of the word
"secret" in the encode definition. :)
]
> > I'm
> > particular in need of encrypting/encoding credit
> card
> > nums before storing them
>
> Two-way encryption? Blowfish, with Crypt::CBC.
> Storing credit cards is
> a bad idea though.
everyone says this. I'll look into letting someone
else carry the liability. Thanks.
> - Perrin
>
>
> --
> Report problems: http://perl.apache.org/bugs/
> Mail list info:
> http://perl.apache.org/maillist/modperl.html
> List etiquette:
> http://perl.apache.org/maillist/email-etiquette.html
>
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: APR::Base64 uses
Posted by Perrin Harkins <pe...@elem.com>.
On Tue, 2004-08-10 at 19:00, Bart Simpson wrote:
> What are some practical uses of APR::Base64?
Sending binary data in ASCII.
> Encoding
> credit card nums before storing in DB? Passwords?
No. It's not encryption.
> I'm
> particular in need of encrypting/encoding credit card
> nums before storing them
Two-way encryption? Blowfish, with Crypt::CBC. Storing credit cards is
a bad idea though.
- Perrin
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
APR::Base64 uses
Posted by Bart Simpson <ba...@yahoo.com>.
Perrin Harkins <pe...@elem.com> wrote in another
post:
> APR::Base64 and APR::URI look pretty
> useful too.
>
What are some practical uses of APR::Base64? Encoding
credit card nums before storing in DB? Passwords?
The doc at
http://perl.apache.org/docs/2.0/api/APR/Base64.html#Synopsis
describes it as encoder/decoder of strings but leave
actual uses to the imagination of the programmer. I'm
particular in need of encrypting/encoding credit card
nums before storing them and am curios what this
module is and is not appropriate for.
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Date parsing (was Re: [mp2 milestones] installment 1)
Posted by Perrin Harkins <pe...@elem.com>.
On Mon, 2004-08-09 at 18:31, MJH wrote:
> So, assuming the date you have is either HTTP-compliant or RFC822-compliant,
> then the APR::Date functions are orders of magnitude faster.
>
> Hopefully this is of use to someone.
It is, thanks. APR::Base64 and APR::URI look pretty useful too.
- Perrin
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html