|
Oscar, There is an old saying in business: If you want to stagnate a company, give control of it to an Accountant. If you want to kill it, give control of it to a lawyer. The point is simply this: Instead of worrying about the theoretical, do what you are doing and when you are done, people can fork the code and port it for the paranoid - or whomever. Your work has value. Don't forget that. And, you are actually doing something - not sitting back pontificating from afar. One other side comment: I've been knocking around this business since the late 70's and having worked with people from Bell Labs and other notable places, I can assure you there is no such thing as a secure language. You just have to select good tools for the job; ones you are comfortable and competent in, and move forward. ...Paul Oscar Schultz wrote: After reviewing the urls (the ones that are valid) I did not see anything to suggest php is any worse or better than any other language. My number one choice would be to use "c".The app should support winxx, mac, unix, linux and text (if possible). The app also must scale from localhost to intranet to internet. The app must also scale from a few users up to several hundred or more concurrent users. Security of data is more important than speed or user ease of use. The app should also require the minimum software installs on the user's machine and add no additional security risks for the users. As I have reviewed the various requirements and options basing app on the web is the best option I see. Feel free to make your suggestions. My Langauges - c, c++, bash, perl, php, assembler, fortran, pascal, cobal. I gave up trying to learn java - I just do not have that much time to spend. Python - it is a great language but counting columns is something I don't do anymore - too much fortran, assembler, and cobol. Maybe next time. That leaves php or perl unless someone knows some really cool c and c++ tricks. That still leaves the problem of how to secure the app and make some of the user information persistant - no one wants to enter their userid and password on every form. Cookies and hidden data fields seem to be the only real option. What are the other options? I have considered having one user enter the data and a second confirm the data. Right now cookies still look like the best option. thanks for the help and comments oscar On Saturday 19 August 2006 11:20 am, Steven H. McCown wrote:I'm resending this since it bounced. Something about being over 40KB. There are some more serious security implications with your choice of tools (e.g., injections). Far from the definitive word, these are hotly debated, demonstrated, and refuted. Here are a couple of blog articles that you should research and consider re PHP: - PHP Insecurity: Failure of Leadership (http://www.greebo.net/?p=320) - PHP Security: Dumb Users or Dumb APIs? (http://www.sitepoint.com/blogs/2006/01/24/php-security-dumb-users-or-dumb- a pis/) This is from last year's Blackhat, but it's fairly new and still relevant: - Beefed up OWASP 2.0 introduced at BlackHat (http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci111 1 443,00.html) and (http://www.owasp.org/index.php/Main_Page) How to harden this? It's a moving target. PHP6? Until it is released and then I'll say PHP7. ;-) The key is that if you don't *really* have to be web-accessible, then don't. Steve_______________________________________________ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss |
_______________________________________________ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
