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 Business-OnlinePayment-StoredTransaction-0.01.tar.gz Description: application/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
Re: APR::Base64 uses
--- mock [EMAIL PROTECTED] 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
MP2: Simple config question...
I've just installed Apache2 and mod_perl2. I'm not quite sure what I need to add to my httpd.conf to enable mod_perl on a directory. I'm not doing anything fancy--I just want to have a directory where scripts are executed with mod_perl rather than traditional CGI. I've read the docs and configuration examples, but somehow I seemed to have missed this. I've already added a line to load mod_perl and my startup.pl file. Thanks! =) --TWH -- 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: MP2: Simple config question...
Tim Howell wrote: I've just installed Apache2 and mod_perl2. I'm not quite sure what I need to add to my httpd.conf to enable mod_perl on a directory. I'm not doing anything fancy--I just want to have a directory where scripts are executed with mod_perl rather than traditional CGI. I've read the docs and configuration examples, but somehow I seemed to have missed this. I've already added a line to load mod_perl and my startup.pl file. Thanks! =) --TWH http://perl.apache.org/docs/2.0/user/intro/start_fast.html#Registry_Scripts Reclaim Your Inbox! http://www.mozilla.org/products/thunderbird -- 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
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
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
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: advantages of mod_perl over java servlets
On Aug 11 harm wrote: On Tue, Aug 10, 2004 at 04:33:07PM -0400, Perrin Harkins wrote: On Tue, 2004-08-10 at 16:24, Xavier Noria wrote: I am confident too, Slashdot runs on Perl for instance Slashdot, although of great interest to techies like us, is tiny. Amazon runs on Perl. Is there some documentation about Amazon and Perl somewhere? Thanks, Harmen Yahoo runs a lot of Perl. Ticketmaster is all mod_perl. Why is there no mention of Ticketmaster on the mod perl success stories page? http://perl.apache.org/outstanding/success_stories/index.html Just wondering, Jim IMDB is Perl. All of these get tons more traffic than Slashdot. - 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: advantages of mod_perl over java servlets
More than likely, a Java-based solution would mainly be done in JSPs with a single controlling servlet, rather than just servlets. JSPs can be written fairly fast because server re-starts are not required. Because they become servlets, they run at servlet speeds. Maybe we need mpsp pages technology Chuck -Original Message- From: Eric Lenio [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 6:56 AM To: [EMAIL PROTECTED] Subject: advantages of mod_perl over java servlets I'm about to start work on a web application which will collect information from the user and return a document based on that information. I'm trying to point out the advantages of mod_perl over a solution based on Java servlet technology to my client. Can anyone provide any quick links/ information to help me 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 -- 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: advantages of mod_perl over java servlets
Goehring, Chuck, RCI - San Diego wrote: Maybe we need mpsp pages technology We already have about a dozen toolkits that are equivalent to JSP. Or did you just mean we need a brand name for them? - 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
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 [EMAIL PROTECTED] To: Geoffrey Young [EMAIL PROTECTED] Cc: Modperl List [EMAIL PROTECTED] 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
That's a pretty interesting way to go about it. I had developed something very similar for storing account information (CC, ACH, etc) securely within a database. The only real difference was my use of Rijndael (AES) over Blow/TwoFish. Crypt::CBC rocks. The problem that was run into is that the key had to be somewhere that either the java/ms/mp sites could access in order to decode for the necessary functions... thus the birth of an application server. Using SOAP setup (wish Apache::SOAP worked on mp2)... to do all of the passing back and forth. All of this to let people donate money to a few things I run. In the end, my little tool added some features like creating fixed length one-way hashes to encrypt data of any length. This resolved issues I had with unixcrypt and its strength for passwords of short length and allowed for passphrases (40 character passwords anyone?) to operate more cleanly.That part of the tool would be an excellent replacement for the current Apache::AuthDBI... as it also has some bits allowing users to reset their passwords, and other parts that allow for account lockout. I've been thinking of adding some basic sessions stuff in as well (maybe link to Apache::Session)... anyone want to help me get it in CPAN? Where I work now (A Bank) I work in Data Security. Of all things, I do Application Security. Though a great deal of time is spent on reviewing things relating to how someone on the outside may cause problems, my biggest challenge will always be keeping it secure from the inside. The vast majority of major break-ins done on things like credit card databases typically involve someone on the inside divulging too much information or actually helping to carry out the nefarious tasks. I suppose for most places it's just a matter of time but doing the absolute best you can to insure security should help at least make the target on your back less desirable to shoot. -Original Message- From: mock [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 11, 2004 1:59 AM To: Geoffrey Young Cc: Modperl List Subject: Re: APR::Base64 uses 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
RE: advantages of mod_perl over java servlets
There's the selling point he needs then. -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 11, 2004 8:27 AM To: Goehring, Chuck, RCI - San Diego Cc: [EMAIL PROTECTED] Subject: Re: advantages of mod_perl over java servlets Goehring, Chuck, RCI - San Diego wrote: Maybe we need mpsp pages technology We already have about a dozen toolkits that are equivalent to JSP. Or did you just mean we need a brand name for them? - 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: Apache::DBI Connection Lost
On Wed, 2004-08-11 at 10:01, David Hofmann wrote:
Any suggestion on why Apache::DBI won't reconnect ?
David Hofmann
--- My Apache Startup Script ---
# make sure we are in a sane environment.
$ENV{MOD_PERL} or die not running under mod_perl!;
use strict;
use Carp ();
use Apache::DBI ();
DBI-install_driver(Pg);
Try taking that install_driver call out. That caused problems for me
with DBD::Oracle.
Also, make sure you are not doing any connections during startup. I
remember DBD::Oracle had trouble reconnecting if I connected before
forking, even though the connections during startup are not persistent.
- 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
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
--- JupiterHost.Net [EMAIL PROTECTED] 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
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: Apache::DBI Connection Lost
Just tried it, still has the same problem.
David
From: Perrin Harkins [EMAIL PROTECTED]
To: David Hofmann [EMAIL PROTECTED]
CC: Modperl List [EMAIL PROTECTED]
Subject: Re: Apache::DBI Connection Lost
Date: Wed, 11 Aug 2004 12:43:59 -0400
On Wed, 2004-08-11 at 10:01, David Hofmann wrote:
Any suggestion on why Apache::DBI won't reconnect ?
David Hofmann
--- My Apache Startup Script ---
# make sure we are in a sane environment.
$ENV{MOD_PERL} or die not running under mod_perl!;
use strict;
use Carp ();
use Apache::DBI ();
DBI-install_driver(Pg);
Try taking that install_driver call out. That caused problems for me
with DBD::Oracle.
Also, make sure you are not doing any connections during startup. I
remember DBD::Oracle had trouble reconnecting if I connected before
forking, even though the connections during startup are not persistent.
- Perrin
_
Dont just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
--
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
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] 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
On Wed, Aug 11, 2004 at 01:01:23AM -0700, Bart Simpson wrote: --- mock [EMAIL PROTECTED] 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
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
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: Apache::DBI Connection Lost
Simple answer... do a $dbh-ping ... if unresponsive, reconnect. It's
not that costly unless we're talking about hundreds of thousands of hits
in a short period :)
-Original Message-
From: David Hofmann [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 11, 2004 12:24 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Apache::DBI Connection Lost
Just tried it, still has the same problem.
David
From: Perrin Harkins [EMAIL PROTECTED]
To: David Hofmann [EMAIL PROTECTED]
CC: Modperl List [EMAIL PROTECTED]
Subject: Re: Apache::DBI Connection Lost
Date: Wed, 11 Aug 2004 12:43:59 -0400
On Wed, 2004-08-11 at 10:01, David Hofmann wrote:
Any suggestion on why Apache::DBI won't reconnect ?
David Hofmann
--- My Apache Startup Script ---
# make sure we are in a sane environment.
$ENV{MOD_PERL} or die not running under mod_perl!;
use strict;
use Carp ();
use Apache::DBI ();
DBI-install_driver(Pg);
Try taking that install_driver call out. That caused problems for me
with DBD::Oracle.
Also, make sure you are not doing any connections during startup. I
remember DBD::Oracle had trouble reconnecting if I connected before
forking, even though the connections during startup are not persistent.
- Perrin
_
Don't just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
--
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: Apache::DBI Connection Lost
On Wed, 2004-08-11 at 14:43, Kreimendahl, Chad J wrote: Simple answer... do a $dbh-ping ... if unresponsive, reconnect. He's already using Apache::DBI, and that's exactly what it does. - 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: Apache::DBI Connection Lost
Not if he's set the vars that disable pinging... Also, I've found that (in the past) sometimes the ping done by Apache::DBI for MySQL doesn't always repsond cause reconnection (though, this was many versions ago). -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 11, 2004 1:52 PM To: Kreimendahl, Chad J Cc: David Hofmann; Modperl List Subject: RE: Apache::DBI Connection Lost On Wed, 2004-08-11 at 14:43, Kreimendahl, Chad J wrote: Simple answer... do a $dbh-ping ... if unresponsive, reconnect. He's already using Apache::DBI, and that's exactly what it does. - 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
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: Apache::DBI Connection Lost
On Wed, 2004-08-11 at 14:58, Kreimendahl, Chad J wrote: Not if he's set the vars that disable pinging... It's on by default. Turning on DBI_TRACE to verify it is getting called would be a good idea though, and $Apache::DBI::DEBUG too. Also, I've found that (in the past) sometimes the ping done by Apache::DBI for MySQL doesn't always repsond cause reconnection (though, this was many versions ago). The docs explain how to replace the ping implementation for a DBD. - 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: Apache::DBI Connection Lost
right, only suggesting that maybe he verify that the ping is being done and the reconnect is as well... :) -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 11, 2004 2:16 PM To: Kreimendahl, Chad J Cc: David Hofmann; Modperl List Subject: RE: Apache::DBI Connection Lost On Wed, 2004-08-11 at 14:58, Kreimendahl, Chad J wrote: Not if he's set the vars that disable pinging... It's on by default. Turning on DBI_TRACE to verify it is getting called would be a good idea though, and $Apache::DBI::DEBUG too. Also, I've found that (in the past) sometimes the ping done by Apache::DBI for MySQL doesn't always repsond cause reconnection (though, this was many versions ago). The docs explain how to replace the ping implementation for a DBD. - 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: advantages of mod_perl over java servlets
Torsten Foertsch wrote: A few years ago I was in a similar situation. I was working for a big company (~500.000 employees) and someone from the upper management had 'decided' that java was the best tool for all purposes. Then some department had startet a new project and of cource tried to implement it in java using jsp. After 6 weeks of more or less resultless effort the lower management decided to try a competing approach. To my luck the manager had had some positive experience with perl. He hired me and a fellow programmer gave us 2 weeks time to create something to show. After that time the java project was canceled and after another 2 weeks we had created a working system where all the basic requirements were implemented. As for scalability I am running mod_perl-enhanced apaches on a web server farm consisting of 5 machines making 500.000 visits, 2.000.000 page impressions or 18.000.000 hits a day. Every request on these machines is touched by mod_perl. And the system would run without noticable performance degradation even with only 3 of the machines running. Torsten, care to reword these bits into a success story, which can be hosted here? http://perl.apache.org/outstanding/success_stories/index.html See the URL above for the desired format... Thanks. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- 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: make test hangs
William Fulmer wrote: I have a non root user that I use for all of my software builds (called build strangely enough). All elements (apache, perl, mod_perl) were built as this user. I just tried building as root as the email suggested. It would not run apache as root, but tried to use nobody(which did not work no matter how wide I ripped the permissions). I forced it to run as the user that my webserver nomrally runs as by setting APACHE_TEST_USER and APACHE_TEST_GROUP. Then the test hangs as before. I never got this message: waiting for server to start: .No -M allowed while running setuid. perl_parse: Address family not supported by protocol !!! right, it was in your trace that you've posted. As in the later post you've mentioned it was coming from a different app. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- 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
Proxying access to restricted information
Hi all Im sure that this has been asked before, but I couldnt seem to find the right terms when searching the archive. We have a website (not written in Perl or mod_perl), where we would now like to protect certain parts of the content. The business is loath to change the architecture, as there are a number of hardware cache boxes that cache the site, and they arent user-aware. My first reaction is to put a mod_perl handler on a set of servers in front of the system. Whenever a request for a page would come in, the handler would check to see whether the page is private or public and would take the appropriate action. Once a page has been requested for the first time, its public or private status would be recorded in a simple perl cache. Now, my problem is as follows. Im assuming that the current website address will point to the new handler server(s). But after authentication/authorisation simply redirecting the user to the internal servers will now no longer work plus we dont want the URL to change if possible. Is there a way that we can accomplish this aim? Dan -- 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: Proxying access to restricted information
Following on from this, it seems that the PerlTransHandler looked like my best bet, but it doesnt seem to be able to alter the hostname (please correct me if there is a way to do this, as I struggled with it so far) I guess mod_rewrite allows the hostname to be altered, but I need to intercept the request and perform access checks, and I dont know if I can do this before mod_rewrite kicks in during the request lifecycle. Quoting Dan Horne [EMAIL PROTECTED]: Hi all Im sure that this has been asked before, but I couldnt seem to find the right terms when searching the archive. We have a website (not written in Perl or mod_perl), where we would now like to protect certain parts of the content. The business is loath to change the architecture, as there are a number of hardware cache boxes that cache the site, and they arent user-aware. My first reaction is to put a mod_perl handler on a set of servers in front of the system. Whenever a request for a page would come in, the handler would check to see whether the page is private or public and would take the appropriate action. Once a page has been requested for the first time, its public or private status would be recorded in a simple perl cache. Now, my problem is as follows. Im assuming that the current website address will point to the new handler server(s). But after authentication/authorisation simply redirecting the user to the internal servers will now no longer work plus we dont want the URL to change if possible. Is there a way that we can accomplish this aim? Dan -- 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: Proxying access to restricted information
Dan Horne wrote: Following on from this, it seems that the PerlTransHandler looked like my best bet, but it doesnt seem to be able to alter the hostname (please correct me if there is a way to do this, as I struggled with it so far) I guess mod_rewrite allows the hostname to be altered, but I need to intercept the request and perform access checks, and I dont know if I can do this before mod_rewrite kicks in during the request lifecycle. With mod_perl 2, you can use http://search.cpan.org/dist/Apache-Filter-HTTPHeadersFixup/ which is perfect for proxying as it does the work long before mod_rewrite kicks in. This module is a connection level filter. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- 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: cvs commit: modperl-2.0/todo api_status
[EMAIL PROTECTED] wrote: gozer 2004/08/10 11:18:08 Modified:todo api_status Log: Took care of Apache::Module API doc Revision ChangesPath 1.24 +1 -1 modperl-2.0/todo/api_status Index: api_status === RCS file: /home/cvs/modperl-2.0/todo/api_status,v retrieving revision 1.23 retrieving revision 1.24 diff -u -r1.23 -r1.24 --- api_status 10 Aug 2004 03:39:15 - 1.23 +++ api_status 10 Aug 2004 18:18:08 - 1.24 @@ -29,7 +29,7 @@ -- src/docs/2.0/api/Apache/HookRun.pod +- src/docs/2.0/api/Apache/Log.pod log_pid -g- src/docs/2.0/api/Apache/Module.pod +V- src/docs/2.0/api/Apache/Module.pod It should be VV if there are no unsupported methods left :) the second column indicates if there is still some potential work to do after 2.0 release, and those unsupported methods should be listed here (see other classes with odd entries). Thanks. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
cvs commit: modperl-2.0/t/hooks/TestHooks authen_digest.pm
geoff 2004/08/11 05:27:47
Modified:t/hooks authen_digest.t
t/hooks/TestHooks authen_digest.pm
Log:
strip away everything that isn't directly testing
$r-note_digest_auth_failure. sorry to wipe away all your hard work, stas :)
Revision ChangesPath
1.2 +43 -18modperl-2.0/t/hooks/authen_digest.t
Index: authen_digest.t
===
RCS file: /home/cvs/modperl-2.0/t/hooks/authen_digest.t,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- authen_digest.t 8 Aug 2004 17:56:53 - 1.1
+++ authen_digest.t 11 Aug 2004 12:27:47 - 1.2
@@ -3,25 +3,50 @@
use Apache::Test;
use Apache::TestRequest;
+use Apache::TestUtil;
-plan tests = 4, need need_lwp, need_auth, need_module('Digest::MD5');
+plan tests = 7, need need_lwp, need_auth;
-my $location = /TestHooks__authen_digest;
+my $location = '/TestHooks__authen_digest';
-sok {
-! GET_OK $location;
-};
-
-sok {
-my $rc = GET_RC $location;
-$rc == 401;
-};
-
-sok {
-GET_OK $location, username = 'Joe', password = 'Smith';
-};
-
-sok {
-! GET_OK $location, username = 'Joe', password = 'SMITH';
-};
+{
+my $response = GET $location;
+ok t_cmp($response-code,
+ 200,
+ 'handler returned HTTP_OK');
+
+my $wwwauth = $response-header('WWW-Authenticate');
+
+t_debug('response had no WWW-Authenticate header');
+ok (!$wwwauth);
+}
+
+{
+my $response = GET $location?fail;
+
+ok t_cmp($response-code,
+ 401,
+ 'handler returned HTTP_UNAUTHORIZED');
+
+my $wwwauth = $response-header('WWW-Authenticate');
+
+
+t_debug('response had a WWW-Authenticate header');
+ok ($wwwauth);
+
+ok t_cmp($wwwauth,
+ qr/^Digest/,
+ 'response is using Digest authentication scheme');
+
+ok t_cmp($wwwauth,
+ qr/realm=Simple Digest/,
+ 'WWW-Authenticate header contains the proper realm');
+
+ok t_cmp($wwwauth,
+ qr/nonce=\w+/,
+ 'WWW-Authenticate header contains a nonce');
+
+# other fields, such as qop, are added only if add additional
+# configuration directives, such as AuthDigestQop
+}
1.3 +7 -66 modperl-2.0/t/hooks/TestHooks/authen_digest.pm
Index: authen_digest.pm
===
RCS file: /home/cvs/modperl-2.0/t/hooks/TestHooks/authen_digest.pm,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- authen_digest.pm 9 Aug 2004 00:23:25 - 1.2
+++ authen_digest.pm 11 Aug 2004 12:27:47 - 1.3
@@ -5,25 +5,18 @@
use Apache::Access ();
use Apache::RequestRec ();
-use APR::Table ();
-
-use Digest::MD5 ();
use Apache::Const -compile = qw(OK HTTP_UNAUTHORIZED);
-# a simple database
-my %passwd = (Joe = Smith);
-
sub handler {
-my $r = shift;
-
-my($rc, $res) = get_digest_auth_data($r);
-return $rc if $rc != Apache::OK;
-my $passwd = $passwd{ $res-{username} } || '';
-my $digest = calc_digest($res, $passwd, $r-method);
+my $r = shift;
-unless ($digest eq $res-{response}) {
+# we don't need to do the entire Digest auth round
+# trip just to see if note_digest_auth_failure is
+# functioning properly - see authen_digest.t for the
+# header checks
+if ($r-args) {
$r-note_digest_auth_failure;
return Apache::HTTP_UNAUTHORIZED;
}
@@ -31,64 +24,12 @@
return Apache::OK;
}
-sub get_digest_auth_data {
-my($r) = @_;
-
-# adopted from the modperl cookbook example
-
-my $auth_header = $r-headers_in-get('Authorization') || '';
-unless ($auth_header =~ m/^Digest/) {
-$r-note_digest_auth_failure;
-return Apache::HTTP_UNAUTHORIZED;
-}
-
-# Parse the response header into a hash.
-$auth_header =~ s/^Digest\s+//;
-$auth_header =~ s///g;
-
-my %res = map { split /=/, $_ } split /,\s*/, $auth_header;
-
-# Make sure that the response contained all the right info.
-for my $key (qw(username realm nonce uri response)) {
-next if $res{$key};
-$r-note_digest_auth_failure;
-return Apache::HTTP_UNAUTHORIZED;
-}
-
-return (Apache::OK, \%res);
-}
-
-sub calc_digest {
-my($res, $passwd, $method) = @_;
-
-# adopted from LWP/Authen/Digest.pm
-
-my $md5 = Digest::MD5-new;
-
-my(@digest);
-$md5-add(join :, $res-{username}, $res-{realm}, $passwd);
-push @digest, $md5-hexdigest;
-$md5-reset;
-
-push @digest, $res-{nonce};
-
-$md5-add(join
cvs commit: modperl-2.0/xs/maps apache_functions.map
gozer 2004/08/11 11:05:38 Modified:.Changes xs/maps apache_functions.map Log: Also removed find_module_name from Apache::Module, since there is already a -name method that does exactly the same. Revision ChangesPath 1.438 +2 -1 modperl-2.0/Changes Index: Changes === RCS file: /home/cvs/modperl-2.0/Changes,v retrieving revision 1.437 retrieving revision 1.438 diff -u -r1.437 -r1.438 --- Changes 11 Aug 2004 18:03:00 - 1.437 +++ Changes 11 Aug 2004 18:05:38 - 1.438 @@ -12,7 +12,8 @@ =item 1.99_15-dev -Removed Apache::Module-dynamic_load_handle [Gozer] +Removed Apache::Module methods (dynamic_load_handle and +find_module_name) [Gozer] All Apache::Command methods are now read-only [Gozer] 1.92 +1 -1 modperl-2.0/xs/maps/apache_functions.map Index: apache_functions.map === RCS file: /home/cvs/modperl-2.0/xs/maps/apache_functions.map,v retrieving revision 1.91 retrieving revision 1.92 diff -u -r1.91 -r1.92 --- apache_functions.map 10 Aug 2004 22:55:33 - 1.91 +++ apache_functions.map 11 Aug 2004 18:05:38 - 1.92 @@ -203,7 +203,7 @@ -ap_add_module -ap_add_named_module ap_find_linked_module - ap_find_module_name +-ap_find_module_name ap_remove_loaded_module ap_remove_module ap_single_module_configure
cvs commit: modperl-2.0/todo api_status
gozer 2004/08/11 11:08:19 Modified:todo api_status Log: Apache::Directive done Apache::Module done Revision ChangesPath 1.26 +2 -2 modperl-2.0/todo/api_status Index: api_status === RCS file: /home/cvs/modperl-2.0/todo/api_status,v retrieving revision 1.25 retrieving revision 1.26 diff -u -r1.25 -r1.26 --- api_status10 Aug 2004 23:03:04 - 1.25 +++ api_status11 Aug 2004 18:08:19 - 1.26 @@ -22,14 +22,14 @@ g- src/docs/2.0/api/Apache/Command.pod -- src/docs/2.0/api/Apache/Connection.pod +- src/docs/2.0/api/Apache/Const.pod -V- src/docs/2.0/api/Apache/Directive.pod +VV src/docs/2.0/api/Apache/Directive.pod VP src/docs/2.0/api/Apache/Filter.pod The whole TIE interface VV src/docs/2.0/api/Apache/FilterRec.pod -- src/docs/2.0/api/Apache/HookRun.pod +- src/docs/2.0/api/Apache/Log.pod log_pid -V- src/docs/2.0/api/Apache/Module.pod +VV src/docs/2.0/api/Apache/Module.pod VV src/docs/2.0/api/Apache/PerlSections.pod VV src/docs/2.0/api/Apache/Process.pod VV src/docs/2.0/api/Apache/Reload.pod
