SitePoint Sponsor

User Tag List

Page 1 of 3 123 LastLast
Results 1 to 25 of 71
  1. #1
    SitePoint Enthusiast
    Join Date
    Feb 2004
    Location
    Montreal
    Posts
    77
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Two-way encryption scheme

    Disclaimer: I am fully aware of the inherent security risks associated with this, but the client insists.

    Ok, now that that is out of the way, I need to store some credit card information in a database. I cannot guarantee that the mcrypt extension is installed on the target server(s) so that is not an option. What I need is an alternative key based two-way encryption algorithm. I've googled this but couldn't get keywords that gave me something I trusted. I'm sure that some of you have had this problem before, so I ask what algorithms you have used and if you happen to still have the source ;-).

    Thanks in advance,

    b1ind

  2. #2
    SitePoint Wizard REMIYA's Avatar
    Join Date
    May 2005
    Posts
    1,351
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Last edited by REMIYA; Aug 31, 2005 at 12:38.

  3. #3
    SitePoint Enthusiast
    Join Date
    Feb 2004
    Location
    Montreal
    Posts
    77
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks REMIYA, I will ask the client to ensure that they chose a good password that hopefully approaches 16 chars.

  4. #4
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by b1ind
    I cannot guarantee that the mcrypt extension is installed on the target server(s)
    Will this be installed on a shared host?

  5. #5
    SitePoint Wizard REMIYA's Avatar
    Join Date
    May 2005
    Posts
    1,351
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Just one point out.

    Because the XOR encryption may output string that is not URL and PHP one line string acceptable like new line, and tab characters, wrap the output in base64_encode function, to save possible regrets.

    Hope that helps

  6. #6
    SitePoint Enthusiast
    Join Date
    Feb 2004
    Location
    Montreal
    Posts
    77
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    McGruff, I am not sure. I'm not in direct contact with the client. Why do you ask?

  7. #7
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You mentioned that you don't have control over server configuration which made me wonder. What I wanted to say was that security on shared hosts is not adequate for an ecommerce site.

    As an example, I maintain a site for a client on one such where, if I wanted to, I could use php to read any file on any other site on the host. A quick peek in an .htpasswd file and I'd have full access to the user's db. Just for starters.

  8. #8
    SitePoint Enthusiast
    Join Date
    Feb 2004
    Location
    Montreal
    Posts
    77
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yeah that's the concern that prompted me to put up the disclaimer. Nothing I can really do but inform the client of the risks involved.

  9. #9
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It's a difficult one. Personally I'd refuse to do the job unless the client followed all my security recommendations to the letter. If something were to go wrong, as the programmer it's likely you'll be blamed and bang goes your professional reputation.

  10. #10
    SitePoint Zealot
    Join Date
    Jul 2004
    Location
    Oklahoma
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    It's a difficult one. Personally I'd refuse to do the job unless the client followed all my security recommendations to the letter. If something were to go wrong, as the programmer it's likely you'll be blamed and bang goes your professional reputation.
    Unless of course you get it in writing, and have them sign off on it. And to top it off, you must be SWAMPED with work, if you have the ability to turn down any client who refuses to do things exactly your way.

  11. #11
    SitePoint Enthusiast
    Join Date
    Feb 2004
    Location
    Montreal
    Posts
    77
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm certainly not swamped with work, and I'm new to the professional webdev scene. Anyway, life is life and tuition is expensive. Thanks for the help guys.

  12. #12
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Sgarissta
    Unless of course you get it in writing, and have them sign off on it.
    I don't think that's adequate, morally. Quite possibly it's not adequate legally.

    If you're dealing with other people's credit card numbers, your first responsibility must be to protect them to the best of your ability. If I was a doctor, and was asked to attempt an experimental brain transplant, I couldn't just say "well, I did warn them it might not work" and then wash my hands of it.

    We're developers. We want to make the internet a safe place to do business because that creates more work for us. Every time there is a security scare that weakens people's confidence and shrinks our market. Just say no to the cowboys out there.

  13. #13
    SitePoint Zealot sanka69's Avatar
    Join Date
    Apr 2003
    Posts
    115
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It's not very often McGruff says something I totally agree with, but this time I'm on his side. There are legal implications of not providing "adequate" (there goes the legal grey matter!) protection for card details in your database. Typically this goes to the holder of the merchant account, and not you as the developer - but you may be sued. Who knows, I'm no legal expert.

    Anyway, to give some more productive advice:

    First point of call is to really establish if you need to store credit card details. Is it for repeat payment? Can your merchant support "subscription payments"? Is it to provide a user interface "nicety" ie (1-Click ordering like Amazon do)? If the answer is no, then try and return to your client. If they insist, explain the responsibilities that they incur, (investigate the contract by the merchant, and maybe legal implications in Canada, and possibly implications of the host being in another country.) In the UK, data cannot be exported to certain countries, and only then if certain criteria is met. I don't know if this applies to using a foreign host to maintain a website, but it might do. Not needed to cross that bridge myself

    If you can't guarantee mcrypt is installed, maybe you could try PGP (or GNUPG for the *nix breed). I've used this before quite successfully, and there's many php scripts which wrap up the calls to it. Create your keys and away you go.

    The only problem with two way encryption like this is you're storing the decryption keys on the server so essentially your doing glorified security through obscurity. That is, the "keys" are obscurely stored at an unknown location on the server. Furthermore, a shared host forces you to trust the hosting provider, and the users on it and if you are on a shared host and have to store credit card details than I would SERIOUSLY advocate the "reverse" part of the encryption is done in an offline environment.

    If you don't store a CV2 number, your pretty safe. This isn't a gospel rule and shouldn't be taken as the only precaution you have to make.

    I designed a setup by which I wrote a PHP webservice using nuSOAP. When the user entered a credit card, the details where sent to a server in the office over an SSL secured connection. This would store in the database the user id and the card details -excluding the CV2 number. This webservice would then provide the customers the ability to store credit cards, and the website the ability to retrieve enough card details to display to the customer (ie: partial numbers). At the point of order, the customer would still have to enter a CV2 number. The webservice had the usual firewall and password protection, and also meant that card details can be stored and customers could avoid reentering it. But, with the cost of having to secure and run another server, not to mention the cost involved and testing the development of this, the client saw that getting a dedicated host was the cheaper option. In fact, if I recall correctly he worked in an building with multiple offices and ended up co-owning a shared contract with another office.

    Anyway, I hope something in that lot will help you.

    Regards,
    Richard

  14. #14
    SitePoint Enthusiast DamienGiles's Avatar
    Join Date
    Mar 2005
    Posts
    85
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sanka69
    But, with the cost of having to secure and run another server, not to mention the cost involved and testing the development of this, the client saw that getting a dedicated host was the cheaper option. In fact, if I recall correctly he worked in an building with multiple offices and ended up co-owning a shared contract with another office.

    Regards,
    Richard
    This seems like an interesting project to develop - however, do you mean that instead of implementing this he simply thought it easier to go dedi?

    Thanks,

    Damien

  15. #15
    SitePoint Zealot sanka69's Avatar
    Join Date
    Apr 2003
    Posts
    115
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It was quite interesting I put together some prototype code to test the concept and on the surface it certainly seemed like a good concept. But yes, the client wanted his site live yesturday and rather than paying for another weeks work he went dedicated.

  16. #16
    SitePoint Addict
    Join Date
    Jan 2005
    Location
    Ireland
    Posts
    349
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    XOR-encryption is not a very secure option for credit cards (or just about anything serious), do not use that. I agree with McGruff and sanka69 here, shared hosting isn't adequate - unless off-course semi-shared with trusted companies. Any decent PHP-written encryption I would say would be quite cumbersome.

    Legally, I don't think you would responsible at all. After all, you are only developing the script/website, you do not have control of where he/she hosts the application or any further security he/she or his hosting provider implements. But I am no lawyer.

    Good Luck

  17. #17
    Floridiot joebert's Avatar
    Join Date
    Mar 2004
    Location
    Kenneth City, FL
    Posts
    823
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Life may be life, & tuition may be expensive, but intuition is priceless. Go with your gut, the whole scenario stinks to high hell if you ask me.

  18. #18
    SitePoint Zealot patrikG's Avatar
    Join Date
    Aug 2003
    Location
    Sussex, UK
    Posts
    129
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm fully with McGruff and sanka69 on this one. If you have made your client aware of the very serious security concerns but they still want you to do it, mention the legal consequences they could be facing when (not if) the site gets cracked and the data compromised. If they still insist on going ahead, they are fishy and I would decline the job.

    If they simply want to store credit card information to have a "remember me" functionality so that their customers don't have to re-enter their credit card information:
    a) they're not amazon.com or any other major eCommerce site
    b) some payment gateways (e.g. secpay) offer a limited "remember me" functionality

    I would find it highly irresponsible of your client to want to still implement this as you've described after you've informed them about the probable consequences. If the client have no problem in abusing trust (which is in essence what they're doing when they offer a CC-service but not the security), I would very strongly reconsider my relationship with them.

  19. #19
    SitePoint Enthusiast
    Join Date
    Jun 2005
    Posts
    66
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I use a PHP implement of 'blowfish' to send clients details over the net (not credit card info tho...):

    http://dev.splitbrain.org/reference/...wfish.php.html

    As far as im aware this algorithm is rock solid. The class was easy to implement too.
    Rascal, am I? Take that!

    -Errol Flynn

  20. #20
    SitePoint Zealot patrikG's Avatar
    Join Date
    Aug 2003
    Location
    Sussex, UK
    Posts
    129
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by chrisdb
    I use a PHP implement of 'blowfish' to send clients details over the net (not credit card info tho...):

    http://dev.splitbrain.org/reference/...wfish.php.html

    As far as im aware this algorithm is rock solid. The class was easy to implement too.
    And where would you store the private key on a shared server? Or maybe an external server? And how would you protect access to that private key?

  21. #21
    SitePoint Wizard stereofrog's Avatar
    Join Date
    Apr 2004
    Location
    germany
    Posts
    4,324
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by b1ind
    Disclaimer: I am fully aware of the inherent security risks associated with this, but the client insists.

    Ok, now that that is out of the way, I need to store some credit card information in a database. I cannot guarantee that the mcrypt extension is installed on the target server(s) so that is not an option. What I need is an alternative key based two-way encryption algorithm. I've googled this but couldn't get keywords that gave me something I trusted. I'm sure that some of you have had this problem before, so I ask what algorithms you have used and if you happen to still have the source ;-).

    Thanks in advance,

    b1ind
    The solution to your problem would be to use asymmetric crypt, so that your application can only encode CC numbers with public code (stored on the server), but it's no way to decode them without knowing the private one (stored on the administrator's local machine). The are several implementations of asymmetric crypts in PHP, for example http://pear.php.net/package/Crypt_RSA (I didn't test it, so no warranty ).

    If CC numbers should be available for users as well, you need to encode twice: once for each user (using symmetric crypt like blowfish and user's password) and once for admin (using asymmetric crypt).

  22. #22
    SitePoint Addict
    Join Date
    Jan 2005
    Location
    Ireland
    Posts
    349
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by stereofrog
    The solution to your problem would be to use asymmetric crypt, so that your application can only encode CC numbers with public code (stored on the server), but it's no way to decode them without knowing the private one (stored on the administrator's local machine).
    How then could he implement functionality like, say, Amazon 1-click order? He needs to be able to get the credit cards back, real-time, I assume.

  23. #23
    SitePoint Wizard stereofrog's Avatar
    Join Date
    Apr 2004
    Location
    germany
    Posts
    4,324
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Eh... what if you read the second paragraph too?

  24. #24
    SitePoint Member
    Join Date
    Jun 2005
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    XOR isn't strong!?!

    Quote Originally Posted by Ryan Wray
    XOR-encryption is not a very secure option for credit cards (or just about anything serious), do not use that.
    Actually, XOR encryption is the strongest possible type. Using say, a 1024-bit key, it's 100% unbreakable. You could get a trillion fast computers and set them cracking it for trillions of trillions of trillions of times longer than the universe has existed, and you still wouldn't break it. Don't knock XOR

  25. #25
    SitePoint Wizard REMIYA's Avatar
    Join Date
    May 2005
    Posts
    1,351
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by narnar
    Actually, XOR encryption is the strongest possible type. Using say, a 1024-bit key, it's 100% unbreakable. You could get a trillion fast computers and set them cracking it for trillions of trillions of trillions of times longer than the universe has existed, and you still wouldn't break it. Don't knock XOR
    This is the absolute truth. And anyone insisting on another is just not aware.

    XOR encription is unbreakable as long as it uses a random password.

    Random means that there is no repetition throughout the encryption. And also it has to be non-computer generated "random " password.

    Not to mention, that its the fastest possible algorythm.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •