[PHP-DB] 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 -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] retaining and displaying line returns in a text field
The function you need is called nl2br: http://us2.php.net/nl2br -Jordan On Jan 6, 2006, at 5:34 AM, swoll2 wrote: 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 -- 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
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
[PHP-DB] Re: retaining and displaying line returns in a text field
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 pre tags: echo pre $rmks/pre; Or replace the \n with br $newRmks = str_replace ( \n, br, $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
[PHP-DB] Re: Storing Credit Cards, Passwords, Securely, two-way encryption
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. Suggestions? Oh, I've got some of them: (1) Call VeriSign (just bought by PayPal) (2) Do NOT store credit card numbers/dates/ccid's anywhere. (yes, that ends in a PERIOD) (2B) Obviously you will need to store the credit card data for a brief while, so you can at least run the credit card. BUT, it shouldn't be stored for any longer than a few hours (See #3 below) (3) Using a service like VeriSign, when you get the credit card information, run a charge of that card immediately (maybe a $1 handling charge). This will give you a magic reference# assigned to that credit card data at the service. VeriSign calls this a PNRef (I think). You can then use this reference for all future charges to that same credit card. (4) Make sure to get the billing zip code and street address for the credit card. This reduces your cost per transaction. (5) Did I mention to NOT store credit card numbers? DanB -- 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
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 the
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] Re: Storing Credit Cards, Passwords, Securely, two-way encryption
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? 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. Please, no more replies saying don't do it. 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
