...so unfucking-secure that this should never see the light of day...
Do you have a pseudonym named Bastian Koert? :-)
On Feb 13, 2015 12:04 AM, php-db-digest-h...@lists.php.net wrote:
php-db Digest 13 Feb 2015 05:03:55 - Issue 5067
Topics (messages 48953 through 48953):
Re: Code Security
48953 by: Ethan Rosenberg
Administrivia:
To subscribe to the digest, e-mail:
php-db-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-db-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-db@lists.php.net
--
-- Forwarded message --
From: Ethan Rosenberg erosenb...@hygeiabiomedical.com
To: Bastien Koert phps...@gmail.com
Cc: php-db@lists.php.net php-db@lists.php.net
Date: Fri, 13 Feb 2015 00:03:48 -0500
Subject: Re: [PHP-DB] Code Security
On 02/06/2015 02:45 PM, Bastien Koert wrote:
Hold on, so you've written a point of sale app that exists on the client
machine as whole? Does this
take credit card data?
If so, its so un-fucking-secure that this should never see the light of
day. The CC companies won't
accept this at all and would remove any ability to accept CCs by the
business. This style of app is
in violation of so many terms of service (not to mention basic security
programming practices when
dealing with sensitive data).
I worked with a guy who wrote an app like that (but not POS, still
sensitive data. I took one look
at it and yanked it from production and replaced it with a proper client
/ server app. Its not safe,
its not secure and to code a POS on a single machine that the user has
access to is just dumb.
I would strongly suggest that your client have a look at square or
similar if he wants to process CC
data.
Bastien
On Thu, Feb 5, 2015 at 11:24 PM, Ethan Rosenberg
erosenb...@hygeiabiomedical.com
mailto:erosenb...@hygeiabiomedical.com wrote:
On 02/05/2015 11:04 AM, Bastien Koert wrote:
I'm with the two Richard's on this, those users shouldn't have
telnet
access to the host server at all. Users should be using the
browser to
access your site.
Other than that, the most important thing you can do is to
regularly back
up your code and database to another location so that if
something happens
to the working box (and likely all tech products, its not IF its
WHEN) you
can restore the code and database with minimal data loss
Bastien
On Thu Feb 05 2015 at 9:39:43 AM Omar Muhsin mrfroa...@gmail.com
mailto:mrfroa...@gmail.com wrote:
You forgot this one keep the box OFFLINE ... best security
:-D
On 05-02-15 14:10, Richard Quadling wrote:
1 - Don't allow terminal access to your box.
2 - Use a PHP byte code encoder (IonCube, Zend Guard) -
not perfect as
they
can be reversed to access the code in a form.
3 - Don't use PHP.
Thanks to all.
I apologize, but I did not properly define the problem I am
addressing. I have written code for
a POS [Point Of Sale] system to be used in a store. I don't expect
the store owner to play with
the code. His friends [or enemies] might try. There are two logins
to the computer, ethan [me]
and worker. Worker has to be able to access the code to use it. He
has to be blocked from
reading, writing or copying the code.
How??
TIA
Ethan
Bastien
Cat, the other other white meat Grrr... I have a gingy cat, and she is
very nice. Don't insult her [LOL]
---
Thanks all.
Sorry, my fault by not being clear.
The POS system is free standing and not on a network.
The server is Apache.
So
Mr Nice has bought my system.
His friend, Mr. Ugly, wants to steal my code.
He asks Mr.[naive]Nice if he could look at the computer while it is logged
in.
Ctrl-Alt-F1 A terminal.
cd /var/www
cp *.* memoryStick He now has my code
look at the code to find out where the passwords are stored and copy to
memoryStick
history |grep mys* He has the login, and hopefully the password
show databases;
/usr/bin/mysqldump -u root -p Database /pathtodatabasefolder/
Database.sql
Everything gone!!!
How do I prevent the above?
TIA
Ethan
