Re: [PEPr] Comment on Payment::Ewire_Payment
| From: | Philippe Jausions | Date: | Wed, 30 Mar 2005 16:02:56 +0000 |
| Subject: | Re: [PEPr] Comment on Payment::Ewire_Payment | ||
| References: | 1 2 3 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-36989@lists.php.net to get a copy of this message | ||
Asbjørn Sloth Tønnesen wrote:
On Wed, 2005-03-30 at 00:00 +0000, Philippe Jausions wrote:Still, e-mail notification is not secure, regardless of how many headers you parse. E-mail headers can be forged as well. Of course when you manually check the balance of the account, then you'll see it was a fraudulent payment notification, but the whole point is to automate a back-end, right? Yes, a signed e-mail would be much better. But this means all the users of eWire would need to have a public key, which will most likely not be the case. Although, this can be enforced by the package itself. That could be a good way to up the security. -PhilippePhilippe Jausions (http://pear.php.net/user/jausions) has commented on the proposal for Payment::Ewire_Payment. Comment: Hi, Given that there is no English version of their web site, I can't help much there, but isn't there a better secure method than parsing an e-mail to receive the notification of payment? Seems very flimsy as far as security is concerned. Anybody can forge an e-mail. Please check in their developers' site to find a better solution than that. Callback URL for instance is much more secure. As is, I wouldn't want this package in PEAR because of the false sense of security for anybody that would use it. If the package is reworked around a more secure solution, and then cleaned up for PEAR Coding Standard, that could be a good addition to PEAR to whoever lives "up North" ;-)You right, isn't the best solution, therefore I have asked them to include a PGP signed xml file as an inline attachment, but in the meanwhile I think it is secure enogh to rely on the received headers. A quick google gave me this page about the currently used method. http://www.ualberta.ca/CNS/Security/headers-tutorial.html Proposed standard for message header mungingA. http://www.faqs.org/rfcs/rfc886.html