RE: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-way encryption
From: Dwight Altman [EMAIL PROTECTED] To: 'Peter Beckman' [EMAIL PROTECTED], 'Neil Smith [MVP, Digital media]' [EMAIL PROTECTED] Cc: php-db@lists.php.net Date: Mon, 9 Jan 2006 09:24:05 -0600 Message-ID: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: RE: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-wayencryption Did you actually SNIP the document[ation] how it can be done safely for all the world to see and learn! ??? Or are you saying go buy this book? No, I retyped the passage in its entirety from the book. Learn to SNIP your posts ! Cheers - Neil -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DB] Storing Credit Cards, Passwords, Securely,two-way encryption
Did you actually SNIP the document[ation] how it can be done safely for all the world to see and learn! ??? Or are you saying go buy this book? No, I retyped the passage in its entirety from the book. Learn to SNIP your posts ! Cheers - Neil -- Neil, Perhaps you replied directly to the thread starter. I left the entire reply of the thread starter NOT SNIPPED to show that it was not there. My reply was for the thread starter. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DB] Storing Credit Cards, Passwords, Securely,two-way encryption
Neil, Perhaps you replied directly to the thread starter. My bad. It was in Friday's batch or emails. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-way encryption
At 03:48 06/01/2006, you wrote: Date: Thu, 5 Jan 2006 22:48:24 -0500 (EST) From: Peter Beckman [EMAIL PROTECTED] To: John Meyer [EMAIL PROTECTED] cc: php-db@lists.php.net Message-ID: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-way encryption On Thu, 5 Jan 2006, John Meyer wrote: Peter Beckman wrote: So I'm thinking about how to save credit card numbers in the DB, for re-charging cards for subscriptions, new orders, etc. Yes yes, lawsuits, scary, etc. I'm glad you're so blase about this and the threat of your business going under due to exposure to extortion. When you've got the site running, let me know the address, so I can advise my friends and colleagues to avoid it at any cost. I was looking for technical solutions, i.e. maybe someone knows how USPS.com or Amazon.com or GoDaddy.com (do they?) does it. Or if it is all security via obscurity. Security by obscurity is a myth. There is no such security, nor will there ever be (think of MS DRM cracks for example on a supposedly secure system). Any system that interacts with the outside world *can* and eventually *will be cracked. Best solution yet: Nope, no solution at all. *DO NOT* store any credit card numbers on any publically accessible system. Ever. Period. Public key encryption, with additional either secret word padding or using the users account password to pad/encrypt the card number (preventing a brute force attack, even if access to the DB is given). Prevents nothing. If somebody compromises your application server, then own your secret word padding and can reverse the process to extract some or all of the credit cards. Do not underestimate the resourcefulness of bored people. OK now to the candy : I've had this book a while, and it's one of the most insightful and well researched (from experience) books on security I've ever read. In fact - so good I'm going to go to the trouble to retype an excerpt of a section called One-Way Credit Card Data Path for Top Security ISBN 0-13-0281870-5 [Prentice-Hall publishers] Bob Toxen : Real World Linux Security [Now in 2nd edition] For many sites the most confidential information a customer can tell the site is the customers credit card number and expiry date. Several e-com sites (including some large ones) have had thousands of their customers cc data stolen by crackers and have then had to respond to extortion threats. Most e-com sites keep the database of customer information on the same system as the web server and CGI programs. This is begging for trouble. Simply putting the database on a separate system is not enough, because if CGI programs can attach to the database across the e-com sites LAN, security has not been improved. (Bob Toxen) have come up with the concept of a one-way credit card data path. By this I mean that the credit card data flows only one way, and that way is into the credit card server but data never flows out of the credit card server (my emphasis) except over a hardware path to the bank or service that is processing charge requests. The cc system would be a (linux) system dedicated to this one application. It would have NO other applications on it, because each application would be a potential security hole. It would be hardened for the highest security. It would have a separate private LAN to the web server, and the web server would have a separate dedicated NIC to this private LAN to prevent sniffing (snipped section about spot welded steel pipes encasing LAN cable !) There would be no request implemented that would allow another system to query for a complete CC number under any circumstance. Thus neither a cracker hacking your web server, nor a disgruntled employee could get the CC data from it. So long as there are no buffer overflow vulns, this should be very secure, since there are no services to crack, no passwords to crack, and spoofing would not work because the system doesn't trust any other system at all. When a customer establishes an account and specifies a CC, the CGI sends the following message to the CC server : ADD user name account number cc type, number, expiry date, CCV# When the customer wants to make a purchase, this is sent to the CC server CHARGE user name account number amount The CC server then contacts the processing bank through the private network to charge the amt, store the authorisastion number if successful and returns either Success or an appropriate error message Note that the comms link to the bank would be on a separate hardware to the rest of the network, so if a cracker broke into the web or order DB server, he could not sniff the network for these requests, because they wouldn't be on that network. If the user has
Re: [PHP-DB] Storing Credit Cards, Passwords, Securely,two-way encryption
Damn, Bob copied me...or me him...i forget, but that was the essence of what I was attempting to let the OP know...when dealing with security you can never be paranoid enough Bastien From: Neil Smith [MVP, Digital media] [EMAIL PROTECTED] To: php-db@lists.php.net CC: [EMAIL PROTECTED] Subject: Re: [PHP-DB] Storing Credit Cards, Passwords, Securely,two-way encryption Date: Fri, 06 Jan 2006 23:52:25 + At 03:48 06/01/2006, you wrote: Date: Thu, 5 Jan 2006 22:48:24 -0500 (EST) From: Peter Beckman [EMAIL PROTECTED] To: John Meyer [EMAIL PROTECTED] cc: php-db@lists.php.net Message-ID: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-way encryption On Thu, 5 Jan 2006, John Meyer wrote: Peter Beckman wrote: So I'm thinking about how to save credit card numbers in the DB, for re-charging cards for subscriptions, new orders, etc. Yes yes, lawsuits, scary, etc. I'm glad you're so blase about this and the threat of your business going under due to exposure to extortion. When you've got the site running, let me know the address, so I can advise my friends and colleagues to avoid it at any cost. I was looking for technical solutions, i.e. maybe someone knows how USPS.com or Amazon.com or GoDaddy.com (do they?) does it. Or if it is all security via obscurity. Security by obscurity is a myth. There is no such security, nor will there ever be (think of MS DRM cracks for example on a supposedly secure system). Any system that interacts with the outside world *can* and eventually *will be cracked. Best solution yet: Nope, no solution at all. *DO NOT* store any credit card numbers on any publically accessible system. Ever. Period. Public key encryption, with additional either secret word padding or using the users account password to pad/encrypt the card number (preventing a brute force attack, even if access to the DB is given). Prevents nothing. If somebody compromises your application server, then own your secret word padding and can reverse the process to extract some or all of the credit cards. Do not underestimate the resourcefulness of bored people. OK now to the candy : I've had this book a while, and it's one of the most insightful and well researched (from experience) books on security I've ever read. In fact - so good I'm going to go to the trouble to retype an excerpt of a section called One-Way Credit Card Data Path for Top Security ISBN 0-13-0281870-5 [Prentice-Hall publishers] Bob Toxen : Real World Linux Security [Now in 2nd edition] For many sites the most confidential information a customer can tell the site is the customers credit card number and expiry date. Several e-com sites (including some large ones) have had thousands of their customers cc data stolen by crackers and have then had to respond to extortion threats. Most e-com sites keep the database of customer information on the same system as the web server and CGI programs. This is begging for trouble. Simply putting the database on a separate system is not enough, because if CGI programs can attach to the database across the e-com sites LAN, security has not been improved. (Bob Toxen) have come up with the concept of a one-way credit card data path. By this I mean that the credit card data flows only one way, and that way is into the credit card server but data never flows out of the credit card server (my emphasis) except over a hardware path to the bank or service that is processing charge requests. The cc system would be a (linux) system dedicated to this one application. It would have NO other applications on it, because each application would be a potential security hole. It would be hardened for the highest security. It would have a separate private LAN to the web server, and the web server would have a separate dedicated NIC to this private LAN to prevent sniffing (snipped section about spot welded steel pipes encasing LAN cable !) There would be no request implemented that would allow another system to query for a complete CC number under any circumstance. Thus neither a cracker hacking your web server, nor a disgruntled employee could get the CC data from it. So long as there are no buffer overflow vulns, this should be very secure, since there are no services to crack, no passwords to crack, and spoofing would not work because the system doesn't trust any other system at all. When a customer establishes an account and specifies a CC, the CGI sends the following message to the CC server : ADD user name account number cc type, number, expiry date, CCV# When the customer wants to make a purchase, this is sent to the CC server CHARGE user name account number amount The CC server then contacts the processing bank through
Re: [PHP-DB] Storing Credit Cards, Passwords, Securely,two-way encryption
Yes yes, lawsuits, scary, etc. I'm glad you're so blase about this and the threat of your business going under due to exposure to extortion. When you've got the site running, let me know the address, so I can advise my friends and colleagues to avoid it at any cost. Public key encryption, with additional either secret word padding or using the users account password to pad/encrypt the card number (preventing a brute force attack, even if access to the DB is given). Prevents nothing. If somebody compromises your application server, then own your secret word padding and can reverse the process to extract some or all of the credit cards. Do not underestimate the resourcefulness of bored people. Do not underestimate the resourcefulness of bored people. These people aren't necessarily bored. Just more intelligent than yourself and on a higher income :-) Have you ever done any cryptanalysis? Have you ever succeeded if so? Do you know some people are employed to actually experiment and test on known modern cyptographic methods in order to ascertain their effectiveness? Rather than to live in your little world where everything is cherry and pretty, most people of our profession are aware to the reality that we can't all hide under 2048bit/2KB key length encryption utilities.. I am somewhat disappointed at the approach you are taking towards people who are in the business and field of security and discovering and in turn rectifying or improving existing security systems. I guess its true then, ignorance IS bliss... Pretend the system IS safe, and it must be! Don't ever let any of those bored people test the limits of the system. Hell why benchmark cars, computers, military weapons, athletes or anything for that matter!! As long as they think they're the best, they MUST be! Wake up mate! OK now to the candy : I've had this book a while, and it's one of the most insightful and well researched (from experience) books on security I've ever read. In fact - so good I'm going to go to the trouble to retype an excerpt of a section called One-Way Credit Card Data Path for Top Security ISBN 0-13-0281870-5 [Prentice-Hall publishers] Bob Toxen : Real World Linux Security [Now in 2nd edition] For many sites the most confidential information a customer can tell the site is the customers credit card number and expiry date. Several e-com sites (including some large ones) have had thousands of their customers cc data stolen by crackers and have then had to respond to extortion threats. Most e-com sites keep the database of customer information on the same system as the web server and CGI programs. This is begging for trouble. Simply putting the database on a separate system is not enough, because if CGI programs can attach to the database across the e-com sites LAN, security has not been improved. (Bob Toxen) have come up with the concept of a one-way credit card data path. By this I mean that the credit card data flows only one way, and that way is into the credit card server but data never flows out of the credit card server (my emphasis) except over a hardware path to the bank or service that is processing charge requests. The cc system would be a (linux) system dedicated to this one application. It would have NO other applications on it, because each application would be a potential security hole. It would be hardened for the highest security. It would have a separate private LAN to the web server, and the web server would have a separate dedicated NIC to this private LAN to prevent sniffing (snipped section about spot welded steel pipes encasing LAN cable !) There would be no request implemented that would allow another system to query for a complete CC number under any circumstance. Thus neither a cracker hacking your web server, nor a disgruntled employee could get the CC data from it. So long as there are no buffer overflow vulns, this should be very secure, since there are no services to crack, no passwords to crack, and spoofing would not work because the system doesn't trust any other system at all. When a customer establishes an account and specifies a CC, the CGI sends the following message to the CC server : ADD user name account number cc type, number, expiry date, CCV# When the customer wants to make a purchase, this is sent to the CC server CHARGE user name account number amount The CC server then contacts the processing bank through the private network to charge the amt, store the authorisastion number if successful and returns either Success or an appropriate error message Note that the comms link to the bank would be on a separate hardware to the rest of the network, so if a cracker broke into the web or order DB server, he could not sniff the network for these requests, because they wouldn't be on that
Re: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-way encryption
Peter wrote: So I'm thinking about how to save credit card numbers in the DB, for re-charging cards for subscriptions, new orders, etc. I'm also thinking about how to save passwords in the DB, not plaintext, but not one-way encrypted either. Any suggestions? How would I secure the database? I'm thinking some abstract process in code, or something -- security through obscurity. if you need to perform the bank operations, then you can use GPG to send you by e-mail the last 4 or 5 digits of a credit card when the user makes the registration process or his first purchase. In this way, you can have in your DB only a portion of the card number and you can offer to the user a way to know his own card. Although somebody can be able to enter in your system he cannot find any complete information. Anyway, if your system is compromised, any person can change your own php scripts,etc... so be careful. If you can use Paypal or Bank it is the best option because you are free of responsibility. Note that although you can use Zend encoder or similar, anyone can encode new scripts to supplant your owns. Also, he can obtain memory dumps, reverse your secret-keys scripts, etc.. Unfortunately, until I know, the popular encoders don't provide means to implement security to authentify our own scripts, neither a way to protect passwords residents in memory. Eventually, this utility http://www.ossec.net/owl/ can monitor your webpages performing periodical MD5 checksum but it is not a final solution if somebody is inside your server. Having a good security can be a very hard task while putting a Paypal button is a trivial thing. br, Vicent, -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-way encryption
On Fri, 6 Jan 2006, Neil Smith [MVP, Digital media] wrote: Peter Beckman wrote: So I'm thinking about how to save credit card numbers in the DB, for re-charging cards for subscriptions, new orders, etc. Yes yes, lawsuits, scary, etc. I'm glad you're so blase about this and the threat of your business going Not blase -- just sick of hearing don't do it you'll get sued impossible what's wrong with you I want to secure this information, responsibly. How? (You answer this below) Security by obscurity is a myth. I believe you -- and if obscurity is a myth, let's document how it can be done safely for all the world to see and learn! *DO NOT* store any credit card numbers on any publically accessible system. Ever. Period. Sometimes when questions are asked a background of the knowledge of the poster is not given. I would never do that. A server that is connected to the internet directly storing credit cards is asking for a lawsuit. It's got a sign with please hack me on it. OK now to the candy : I've had this book a while, and it's one of the most insightful and well researched (from experience) books on security I've ever read. In fact - so good I'm going to go to the trouble to retype an excerpt of a section called One-Way Credit Card Data Path for Top Security (Bob Toxen) have come up with the concept of a one-way credit card data path. Now THAT is exactly what I was looking for -- THANKS! I'll go get the book. (snipped section about spot welded steel pipes encasing LAN cable !) *laugh* That might be a bit of overkill... but I get the idea. The CC server then contacts the processing bank through the private network to charge the amt, store the authorisastion number if successful and returns either Success or an appropriate error message Obviously most CC auths are via the 'net + SSL, private networks don't apply (and they are kind of cost prohibitive). If you have a router/firewall/ipfw between your CC and the 'net, blocking incoming but allowing outgoing to your cc auth host ip(s), is that good enough? What else can be done? As Bob's book is so bloody good, here's the ASIN for it in case you want to read all 650 pages of good advice ;-) http://www.amazon.com/gp/product/0130464562/qid=1136589506/sr=8-1/ref=pd_bbs_1/104-3174210-9795945?n=507846 Thank you Neil -- sold! Beckman --- Peter Beckman Internet Guy [EMAIL PROTECTED] http://www.purplecow.com/ --- -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-way encryption
CC saving is a bad idea on a web facing server...much better to let the user re-input the data each time. If your network allows it, store the data encrypted (using php's mcrypt/decrypt extension) on an separate extremely limited access, non-webfacing (ie internal) db/server that only allows inserts from the webfacing server. Hacking and the liability of being hacked is something to take very seriously. Also look into PCI regulatory compliance with regard to storing CC data on a server to be aware of any laws that can govern how you do this. Passwords: again use mcrypt Bastien From: Peter Beckman [EMAIL PROTECTED] To: PHP-DB Mailing List php-db@lists.php.net Subject: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-way encryption Date: Thu, 5 Jan 2006 20:27:57 -0500 (EST) So I'm thinking about how to save credit card numbers in the DB, for re-charging cards for subscriptions, new orders, etc. I'm also thinking about how to save passwords in the DB, not plaintext, but not one-way encrypted either. Any suggestions? How would I secure the database? I'm thinking some abstract process in code, or something -- security through obscurity. Beckman --- Peter Beckman Internet Guy [EMAIL PROTECTED] http://www.purplecow.com/ --- -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-way encryption
Peter Beckman wrote: So I'm thinking about how to save credit card numbers in the DB, for re-charging cards for subscriptions, new orders, etc. Why, is the first question I would ask you. First off, on a new order, why wouldn't you just save the authorization code, instead of the credit card number? That would be a lot easier. Secondly, you're opening yourself up to a _ton_ of lawsuits should anything go awry. Unless I had a _real_ good reason for storing their cc number, I wouldn't, despite the extra step. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-way encryption
On Thu, 5 Jan 2006, John Meyer wrote: Peter Beckman wrote: So I'm thinking about how to save credit card numbers in the DB, for re-charging cards for subscriptions, new orders, etc. Why, is the first question I would ask you. So I'm thinking about how to save credit card numbers in the DB, for re-charging cards for subscriptions, new orders, etc. Think one-click. Why did Amazon patent one-click? Impulse buys -- the I want that, now factor. If you make 13 steps and 12 input boxes, the Impulse will probably pass, and you've lost your sale. Besides, the user can choose if they want you to save their card info. First off, on a new order, why wouldn't you just save the authorization code, instead of the credit card number? That would be a lot easier. Sure. But see my above point. I want to be able to re-charge it later when the user wants to. Secondly, you're opening yourself up to a _ton_ of lawsuits should anything go awry. Unless I had a _real_ good reason for storing their cc number, I wouldn't, despite the extra step. Yes yes, lawsuits, scary, etc. I was looking for technical solutions, i.e. maybe someone knows how USPS.com or Amazon.com or GoDaddy.com (do they?) does it. Or if it is all security via obscurity. Best solution yet: Public key encryption, with additional either secret word padding or using the users account password to pad/encrypt the card number (preventing a brute force attack, even if access to the DB is given). Beckman --- Peter Beckman Internet Guy [EMAIL PROTECTED] http://www.purplecow.com/ --- -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-way encryption
On Fri, 6 Jan 2006, Julien Bonastre wrote: Any reason why you need to have reversible encryption on the password value?? No... I just prefer to assume that if someone gets my DB, they might try using user/pass pairs on banking sites, or paypal, or other ways, and if I can reversible encrypt the password, I can send them an email with their password, rather than changing it to something obscure and force them to change it again... Though at this point, I just decided to md5 the password and call it good enough. I'll just force them to change it if need be. Generally I simply create some hash from the password, using something akin to a MD5 or SHA1 hash of the password string. Or in my paranoid case I use the password string, plus all sorts of replicatable combinations of values such as length of password, username, registration date/time etc plus weird other fixed values I find around the place and environment variables etc, then I hash them.. A good idea; are you just careful then that you don't accidentally update the data without re-hasing your passwords? I am completely psychotic so don't mind me, when I was 15 I wrote my Perl driven website http://operation-scifi.com [still Perl driven member system and file-system based forum] and I had a real mangler function whereby I would extract each character of the password and hash it, then hash the hash with the other characters, plus the hash of them with said fixed values from server/user account details [age, location etc..] ... It was something in the vicinity of a O(6^n+1)th generation hash by the time I had finished where n is the length of the original password.. *laugh* Awesome! Maybe a bit overkill for password, but still very cool. Unfortunately that leaves things unreversable, and if someone got a hold of your data AND your code, they could reverse-engineer... It seems security is only as good as your weakest link -- obscure code, private key, etc... Beckman --- Peter Beckman Internet Guy [EMAIL PROTECTED] http://www.purplecow.com/ --- -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-way encryption
On Fri, 6 Jan 2006, Julien Bonastre wrote: Any reason why you need to have reversible encryption on the password value?? No... I just prefer to assume that if someone gets my DB, they might try using user/pass pairs on banking sites, or paypal, or other ways, and if I can reversible encrypt the password, I can send them an email with their password, rather than changing it to something obscure and force them to change it again... Though at this point, I just decided to md5 the password and call it good enough. I'll just force them to change it if need be. Generally I simply create some hash from the password, using something akin to a MD5 or SHA1 hash of the password string. Or in my paranoid case I use the password string, plus all sorts of replicatable combinations of values such as length of password, username, registration date/time etc plus weird other fixed values I find around the place and environment variables etc, then I hash them.. A good idea; are you just careful then that you don't accidentally update the data without re-hasing your passwords? I am completely psychotic so don't mind me, when I was 15 I wrote my Perl driven website http://operation-scifi.com [still Perl driven member system and file-system based forum] and I had a real mangler function whereby I would extract each character of the password and hash it, then hash the hash with the other characters, plus the hash of them with said fixed values from server/user account details [age, location etc..] ... It was something in the vicinity of a O(6^n+1)th generation hash by the time I had finished where n is the length of the original password.. *laugh* Awesome! Maybe a bit overkill for password, but still very cool. Unfortunately that leaves things unreversable, and if someone got a hold of your data AND your code, they could reverse-engineer... It seems security is only as good as your weakest link -- obscure code, private key, etc... Well, I still consider it irreversable due to the fact that it is an MD5 hash therefore generating the plainttext from a given ciphertext is fairly slim unless as I mentioned certain dictionary plainttext words are kept catalogued somewhere they can match too. But with the sheer randomness of the plainttext this would never have been hashed before. So even if someone knows my algorithm and has somehow obtained not only the end result but also has the plainttext password and all the data I use intermediate to creating my final hash value AND they can recompute using all this the same final value. This still does not help them figure out HOW to reverse just a stored hash value which they do not know any of the values that were used in its encryption, ie the password or user details. Put simply: how do you reverse a hash? Its designed to be a one way function: I give you: fc3ff98e8c6a0d3087d515c0473f8677 86fb269d190d2c85f6e0468ceca42a20 First MD5 hash is the plainttext of hello world! the second is Hello world! One character difference, and if you do have an understanding of the inner workings of the MD5 function you will already know the implications a checksum works on and thereby it only requires a single one bit of difference [no pun intended] to create a vastly different checksum hash.. I am happy to place the security of my users within this field of near impossibility and believe I have done everything in my power to ensure even with the most simplest dictionary word password to start with, they end up with a far more complex end hash therefore avoiding the largest and by far easiest hash cracking method which is brute force dictionary matching. Meh, whats it all at the end of the day anyway.. Good questions about the credit card stuff though. I've encountered similiar issues but decided to simply delegate paypal.com.au's services to handling subscriptions, credit card payments etc... Their global, safe, established and it works. Its not perfect, but it'll do. For example a big problem is you can't really have variable monthly payments, say your site provides a service where you are sort of billed every month for what features you've accessed, premium services you've used, how long you used them for etc, much like your electricity bill or phone bill, well the only feature paypal provides is its fixed rate subscription system. Even with the API you can only really retrieve details and transaction records, you can really edit the rate behind the scenes. The only method is rather primitive and involves generating a link or form your user will be displayed on your site which they follow, linking to a subscription modification page on paypal with the new required values all entered in. Sure thats great but now thats the new rate per month. Not good if its a very variable or fluctuating sort of service you provide with extras or whatever.. The advantage? Paypal keeps all
