Re: [PHP-DB] Re: Storing Credit Cards, Passwords, Securely, two-wayencryption
I'm new to this list, so I'm not sure what has been kicked around in this thread. I just like to bring up that you need to mention on your page that you can store their credit card for future convenience and if the user agrees with that. You also should consider what to do when a credit card has expired. I had one company add 3 years to my expired card and process a renewal payment. That is not legal because it is not the information I have provided... American Express had fun with those turkeys. FWIW, Gerry
RE: [PHP-DB] Re: Storing Credit Cards, Passwords, Securely, two-wayencryption
> -Original Message- > From: Peter Beckman [mailto:[EMAIL PROTECTED] > Sent: Saturday, 7 January 2006 4:05 PM > To: Dan Baker > Cc: php-db@lists.php.net > Subject: Re: [PHP-DB] Re: Storing Credit Cards, Passwords, Securely, > two-wayencryption > > On Fri, 6 Jan 2006, Dan Baker wrote: > > > "Peter Beckman" <[EMAIL PROTECTED]> wrote in message > > news:[EMAIL PROTECTED] > >> 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. > > > > [Summary: Call Verisign, pay THEM to store credit cards for you] > > What, exactly, does VeriSign do, that makes you so sure that they have > secured the credit card information any better than I could, using a > well-thought-out system? Do you even know? You just hear "VeriSign" and > believe they have smart people that have more resources available to them > to do a better job securing the data? They don't. What they do have is more financial muscle to deal with a stuff up of the nature that CardSystems perpetrated. Similarly because of the scale they can afford to invest more $ (same proportion as you but much more in absolute amounts) in R+D to protect against the downside. > Maybe this makes sense if you are doing a few hundred or a few thousand > dollars of business a month, but if you are planning on doing $5,000 to > $10,000 a day, it is a lot of added expense to have someone else do it, > when I could have it done internally. It is the how. Sure, why give away margin if you can solve the issue locally. > Please, no more replies saying don't do it. Just do it with your eyes wide open. BTW you should get your legal eagles to review the fine print of your gateway agreements to assess whether you are "allowed" to store the information. Even if they explicitly prohibit the storage of course you can go ahead and cache the numbers. But be warned that should it all go pear shaped they will cut you loose to the hordes of lawyers that will surely descend to feed on the carcass of your company. On the subject of how to do it? The host of the CC numbers should at least (i.e. not an exhaustive list) ... a) Not be internet or internally facing. i.e.. in a physical DMZ with an mains power connected to the keyboard :-) to stop casual users snooping around, b) perform no other tasks at all! No web surfing, no email, no nothing, only backup in encrypted form. c) seriously encrypt everything - no mickey mouse xor stuff, d) must be firewalled from the web server with a keyhole open for communication, e) must perform all communications with the bank/gateway provider and only return success/fail to the webserver - never ever return CC numbers! To bad if you want to replay the number to the user. f) log everything ideally on a one way basis to another server with worm media and scan the logs frequently for weird stuff. Make sure it screams like crazy if the log stream appears to be interfered with. Hopefully with these sorts of controls the damage will be less than your balance sheet can withstand. BTW you prolly won't get any insurance of this risk unless you are prepared to pay a big premium - which defeats the purpose! Others no doubt will be able to add more control layers - these are just what first comes to mind in a few minutes. Bon voyage! Frank. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] Re: Bit(1) datatype from mySQL
Larry Bradley wrote: Greetings: I'm new to PHP, although I've been a programmer all my life. I had been doing a bit of web database work with VB Script and ASP and mySQL, and then decided to try PHP. I've run into a couple of things that bother me. I have boolean fields (i.e. bit(1)) in the mySQL database. When I retrieve data from the mySQL server into an array or an object, it seems as if all the data fields are returned as characters. For most data types this does not matter, since PHP will handle them properly. This an integer 46 being retrieved as a character '46' is OK. However, the boolean is a curse, as it comes back as a character containing hex 00 or hex 01, and I have to use a test such as: if (ord(IsAMember) == 0) ... I can't just treat it as a boolean. I have got around the problem by using a construct such as: select if(IsAMember,1,0) as IsAMember in the SQL select, but this is a bit of a pain. Any thoughts? Thanks Larry Bradley Orleans (Ottawa), Ontario, CANADA Try using a set() field with values true and false -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] Re: retaining and displaying line returns in a text field
Frank Flynn wrote: This is an HTML issue (not PHP or MySQL) that is HTML ignores carriage returns (and most other white spaces). There are two simple solutions: use tags: echo " $rmks"; Or replace the \n with "" $newRmks = str_replace ( "\n", "", $rmks ); echo $newRmks; You can do this going into or coming out of the database but remember to be consistent. And you can do more with paragraphs and changing tabs and other special characters - there are probably some libraries that will all this and much more (including some WISIWYG editors that you can put on your web page) depending on how deep you want to get. Good Luck, Frank On Jan 6, 2006, at 2:45 PM, [EMAIL PROTECTED] wrote: From: "swoll2" <[EMAIL PROTECTED]> Date: January 6, 2006 3:34:52 AM PST To: php-db@lists.php.net Subject: retaining and displaying line returns in a text field Good morning - I'm trying to get a text field with line returns in it to be stored, retrieved, and displayed the way it gets entered. Specifically, my users use a form field (html textarea) to enter some remarksas they enter their remarks, they can hit Enter to insert a hard return, which is reflected in the textarea on their screen. Example entry: this is line1. this is line2. this is line3. Those remarks get uploaded into a mysql db, into a field defined as a text field named rmks. If I use PhpMyAdmin to browse the table, it shows the entry with the lines separated, but there are no /n's or other control characters visible. Later, the field is retrieved from the db using a php script and assigned to a variable $rmkswhen I echo $rmks, it displays on a single line without the line returns, like this: this is line1.this is line2.this is line3. I have tried to work with addslashes and stripslashes, but neither has worked. I think I'm just missing something basic Appreciate any help or points to previous discussions..thanks...Steve When echoing, use this: echo nl2br($rmks); -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
