Re: [PHP-DB] Code Security

2015-03-09 Thread Bastien Koert
Cloud computing is just another computer in a remote network. If you have a
website with some host somewhere, you are cloud computing. Just run your
site from a secure host

On Sun, Mar 8, 2015 at 1:04 AM Ethan Rosenberg 
erosenb...@hygeiabiomedical.com wrote:

 On 02/16/2015 12:10 AM, Mark Murphy wrote:
  How do you prevent access to the second partition? What good is a second
 partition going to do? Both
  partitions are visible to the OS. If you only have a single OS, then
 both the client and the server
  are running on the same OS, and there is only one logon. The number of
 partitions is irrelavant.
 
  So your choices are choose a compiled language like C or Java, or use
 multiple computers. You can
  use a hammer to drive a screw if you get a big enough hammer, but you
 will probably break something
  and it won't work very well. You are trying to use PHP to do something
 it was never meant to do, and
  that can only turn out badly. You can think about it all you want, but
 you are just looking for a
  bigger hammer to drive something that isn't a nail.
 
  On Sun, Feb 15, 2015 at 7:21 PM, Ethan Rosenberg 
 erosenb...@hygeiabiomedical.com
  mailto:erosenb...@hygeiabiomedical.com wrote:
 
  On 02/15/2015 05:39 PM, Mark Murphy wrote:
 
  I would say no. It isn't the hard drive that is the problem, you
 need a separate operating
  system.
  My thought is that even a small retailer will already have a
 computer, so all you have to
  sell is
  the appliance which is all server. No one needs to log in to the
 server. To make it useable
  you just
  need a config application that will let the owner set the IP
 address.
 
  On Feb 15, 2015 1:25 PM, Ethan Rosenberg
 erosenberg@hygeiabiomedical.__com
  mailto:erosenb...@hygeiabiomedical.com
  mailto:erosenberg@__hygeiabiomedical.com mailto:erosenberg@
 hygeiabiomedical.com wrote:
 
   On 02/14/2015 08:54 PM, Mark Murphy wrote:
 
   There might be a virtual machine solution, probably not
 the VMWare hypervisor since you
   can't get it
   to boot into one of the VMs. I don't know about any of
 the others. Maybe put the
  server at a
   hosting
   service like pair networks. You just can't run any
 scripted solution stand alone
  because of the
   security risks. You might be able to use something that
 encrypts the source, but it
  might
   have the
   same security risks for a determined attacker. Look at
 Zend Guard or Ioncube. These
  aren't
   free, but
   less expensive than a whole server.
 
   That said, the most secure option is a separate server
 machine which you could set
  up as a
   Linux box
   without the GUI, and a cheap 4 port switch to hook up
 to your POS client. No one
  needs to
   have logon
   authority to the server except you, or other support
 personnel. Kind of like a POS
  appliance.
 
   On Feb 14, 2015 8:27 PM, Ethan Rosenberg
 erosenberg@hygeiabiomedical.com
   mailto:erosenberg@__hygeiabiomedical.com mailto:
 erosenb...@hygeiabiomedical.com
   mailto:erosenberg@ mailto:erosenberg@__hygeiabi
 o__medical.com
  http://hygeiabiomedical.com mailto:erosenberg@__hygeiabio
 medical.com
  mailto:erosenb...@hygeiabiomedical.com wrote:
 
On 02/13/2015 02:12 PM, Mark Murphy wrote:
 
Ahh... You have both client and server on the
 same computer. While this
  might be
   fine for
demonstration, it is not ok for production
 because you cannot keep anyone
  out of
   the code.
If you
are going to use PHP, you MUST -- I can't
 emphasize that enough -- you
  MUST have
   the server
parts
(PHP, Apache, MySQL) on a server machine that
 is separate from the client
  machine
   or you
will not
have any security. You can keep folks out of
 the database, but only until
  they look
   at the
PHP code.
 
On Fri, Feb 13, 2015 at 12:03 AM, Ethan
 Rosenberg
  erosenberg@hygeiabiomedical.__com
 
mailto:erosenberg@ mailto:erosenberg@__
 hygeiabio__medical.com
  http://hygeiabiomedical.com mailto:erosenberg@__hygeiabio
 medical.com
  mailto:erosenb...@hygeiabiomedical.com
mailto:erosenberg@ mailto:erosenberg@
 

Re: [PHP-DB] Code Security

2015-03-07 Thread Ethan Rosenberg

On 02/16/2015 12:10 AM, Mark Murphy wrote:

How do you prevent access to the second partition? What good is a second 
partition going to do? Both
partitions are visible to the OS. If you only have a single OS, then both the 
client and the server
are running on the same OS, and there is only one logon. The number of 
partitions is irrelavant.

So your choices are choose a compiled language like C or Java, or use multiple 
computers. You can
use a hammer to drive a screw if you get a big enough hammer, but you will 
probably break something
and it won't work very well. You are trying to use PHP to do something it was 
never meant to do, and
that can only turn out badly. You can think about it all you want, but you are 
just looking for a
bigger hammer to drive something that isn't a nail.

On Sun, Feb 15, 2015 at 7:21 PM, Ethan Rosenberg 
erosenb...@hygeiabiomedical.com
mailto:erosenb...@hygeiabiomedical.com wrote:

On 02/15/2015 05:39 PM, Mark Murphy wrote:

I would say no. It isn't the hard drive that is the problem, you need a 
separate operating
system.
My thought is that even a small retailer will already have a computer, 
so all you have to
sell is
the appliance which is all server. No one needs to log in to the 
server. To make it useable
you just
need a config application that will let the owner set the IP address.

On Feb 15, 2015 1:25 PM, Ethan Rosenberg 
erosenberg@hygeiabiomedical.__com
mailto:erosenb...@hygeiabiomedical.com
mailto:erosenberg@__hygeiabiomedical.com 
mailto:erosenb...@hygeiabiomedical.com wrote:

 On 02/14/2015 08:54 PM, Mark Murphy wrote:

 There might be a virtual machine solution, probably not the 
VMWare hypervisor since you
 can't get it
 to boot into one of the VMs. I don't know about any of the 
others. Maybe put the
server at a
 hosting
 service like pair networks. You just can't run any scripted 
solution stand alone
because of the
 security risks. You might be able to use something that 
encrypts the source, but it
might
 have the
 same security risks for a determined attacker. Look at Zend 
Guard or Ioncube. These
aren't
 free, but
 less expensive than a whole server.

 That said, the most secure option is a separate server machine 
which you could set
up as a
 Linux box
 without the GUI, and a cheap 4 port switch to hook up to your 
POS client. No one
needs to
 have logon
 authority to the server except you, or other support 
personnel. Kind of like a POS
appliance.

 On Feb 14, 2015 8:27 PM, Ethan Rosenberg 
erosenberg@hygeiabiomedical.com
 mailto:erosenberg@__hygeiabiomedical.com 
mailto:erosenb...@hygeiabiomedical.com
 mailto:erosenberg@ 
mailto:erosenberg@__hygeiabio__medical.com
http://hygeiabiomedical.com mailto:erosenberg@__hygeiabiomedical.com
mailto:erosenb...@hygeiabiomedical.com wrote:

  On 02/13/2015 02:12 PM, Mark Murphy wrote:

  Ahh... You have both client and server on the same 
computer. While this
might be
 fine for
  demonstration, it is not ok for production because 
you cannot keep anyone
out of
 the code.
  If you
  are going to use PHP, you MUST -- I can't emphasize 
that enough -- you
MUST have
 the server
  parts
  (PHP, Apache, MySQL) on a server machine that is 
separate from the client
machine
 or you
  will not
  have any security. You can keep folks out of the 
database, but only until
they look
 at the
  PHP code.

  On Fri, Feb 13, 2015 at 12:03 AM, Ethan Rosenberg
erosenberg@hygeiabiomedical.__com

  mailto:erosenberg@ 
mailto:erosenberg@__hygeiabio__medical.com
http://hygeiabiomedical.com mailto:erosenberg@__hygeiabiomedical.com
mailto:erosenb...@hygeiabiomedical.com
  mailto:erosenberg@ mailto:erosenberg@ 
mailto:erosenberg@
mailto:erosenberg@__hygeiabi__o__medical.com 
http://hygeiabio__medical.com
 http://hygeiabiomedical.com mailto:erosenberg@
mailto:erosenberg@__hygeiabio__medical.com 
http://hygeiabiomedical.com
 mailto:erosenberg@__hygeiabiomedical.com
mailto:erosenb...@hygeiabiomedical.com wrote:

   On 02/06/2015 02:45 PM, Bastien Koert 

Re: [PHP-DB] Code Security

2015-02-13 Thread Ethan Rosenberg

On 02/13/2015 02:58 AM, Karl DeSaulniers wrote:

Prevent THIS from ever happening.

On Feb 12, 2015, at 11:03 PM, Ethan Rosenberg erosenb...@hygeiabiomedical.com 
wrote:


He asks Mr.[naive]Nice if he could look at the computer while it is logged in.



Otherwise, I would say an external key that has a salt stored on it that the 
user has to insert in the computer before the system can be accessed.
Like an access key card. Immediate shut down when tampered and/or removed.

Just a stab in the dark though.

Best,

Karl DeSaulniers
Design Drumm
http://designdrumm.com

---

Karl -

Thanks.

The key is already plugged in.  Mr [Naive] Nice is using the computer, and is logged in.  Mr. Ugly 
just want to look at the computer.


Ethan



--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



RE: [PHP-DB] Code Security

2015-02-13 Thread Arneson, Joshua
Ethan,

It seems like you're looking for a programmatic solution to a physical 
security problem. In the end, your most viable solution will likely be to train 
Mr. Goodguy to remove the key the same way he needs to remember his ATM card 
after a withdrawal. I've seen programmatic work-arounds to solve similar 
issues, but they have always ended up being significantly arduous for the end 
users...

Respectfully,
 
Joshua D. Arneson

-Original Message-
From: Ethan Rosenberg [mailto:erosenb...@hygeiabiomedical.com] 
Sent: Friday, February 13, 2015 9:12 AM
To: php-db@lists.php.net
Subject: Re: [PHP-DB] Code Security

On 02/13/2015 02:58 AM, Karl DeSaulniers wrote:
 Prevent THIS from ever happening.

 On Feb 12, 2015, at 11:03 PM, Ethan Rosenberg 
 erosenb...@hygeiabiomedical.com wrote:

 He asks Mr.[naive]Nice if he could look at the computer while it is logged 
 in.


 Otherwise, I would say an external key that has a salt stored on it that the 
 user has to insert in the computer before the system can be accessed.
 Like an access key card. Immediate shut down when tampered and/or removed.

 Just a stab in the dark though.

 Best,

 Karl DeSaulniers
 Design Drumm
 https://urldefense.proofpoint.com/v2/url?u=http-3A__designdrumm.comd=
 AwIC-gc=4R1YgkJNMyVWjMjneTwN5tJRn8m8VqTSNCjYLg1wNX4r=pRBqy2P3JaV_0yI
 qjAsPRpV2yZymYr9X5J_0Y74t654m=kIedOn0p3VGnUZ1gfYdWWnG5241UJdD7tnYY_Ju
 HC18s=ig7LiGzP4X2ZJJMrsq4695g43cu8ghuBAAdEq6F3jrYe=
---

Karl -

Thanks.

The key is already plugged in.  Mr [Naive] Nice is using the computer, and is 
logged in.  Mr. Ugly just want to look at the computer.

Ethan



--
PHP Database Mailing List 
(https://urldefense.proofpoint.com/v2/url?u=http-3A__www.php.net_d=AwIC-gc=4R1YgkJNMyVWjMjneTwN5tJRn8m8VqTSNCjYLg1wNX4r=pRBqy2P3JaV_0yIqjAsPRpV2yZymYr9X5J_0Y74t654m=kIedOn0p3VGnUZ1gfYdWWnG5241UJdD7tnYY_JuHC18s=saaG6YC7fWss2eAYUsXw7GU0vdZKj74Uz3iVA1Enu40e=
 ) To unsubscribe, visit: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.php.net_unsub.phpd=AwIC-gc=4R1YgkJNMyVWjMjneTwN5tJRn8m8VqTSNCjYLg1wNX4r=pRBqy2P3JaV_0yIqjAsPRpV2yZymYr9X5J_0Y74t654m=kIedOn0p3VGnUZ1gfYdWWnG5241UJdD7tnYY_JuHC18s=b2pGut3zlmECebRRBhfyRBYokCPeQHk8ZPkcdNA2RzQe=
 


--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DB] Code Security

2015-02-13 Thread Karl DeSaulniers
And in the same way, don't let him withdraw money from your account while your 
logged into the ATM. I mean it sounds like mr. Nice shouldn't have a business. 
At all. 

Best,
Karl

Sent from losPhone

 On Feb 13, 2015, at 8:17 AM, Arneson, Joshua joshua.arne...@mssm.edu 
 wrote:
 
 Ethan,
 
It seems like you're looking for a programmatic solution to a physical 
 security problem. In the end, your most viable solution will likely be to 
 train Mr. Goodguy to remove the key the same way he needs to remember his ATM 
 card after a withdrawal. I've seen programmatic work-arounds to solve similar 
 issues, but they have always ended up being significantly arduous for the end 
 users...
 
 Respectfully,
  
 Joshua D. Arneson
 
 -Original Message-
 From: Ethan Rosenberg [mailto:erosenb...@hygeiabiomedical.com] 
 Sent: Friday, February 13, 2015 9:12 AM
 To: php-db@lists.php.net
 Subject: Re: [PHP-DB] Code Security
 
 On 02/13/2015 02:58 AM, Karl DeSaulniers wrote:
 Prevent THIS from ever happening.
 
 On Feb 12, 2015, at 11:03 PM, Ethan Rosenberg 
 erosenb...@hygeiabiomedical.com wrote:
 
 He asks Mr.[naive]Nice if he could look at the computer while it is logged 
 in.
 
 
 Otherwise, I would say an external key that has a salt stored on it that the 
 user has to insert in the computer before the system can be accessed.
 Like an access key card. Immediate shut down when tampered and/or removed.
 
 Just a stab in the dark though.
 
 Best,
 
 Karl DeSaulniers
 Design Drumm
 https://urldefense.proofpoint.com/v2/url?u=http-3A__designdrumm.comd=
 AwIC-gc=4R1YgkJNMyVWjMjneTwN5tJRn8m8VqTSNCjYLg1wNX4r=pRBqy2P3JaV_0yI
 qjAsPRpV2yZymYr9X5J_0Y74t654m=kIedOn0p3VGnUZ1gfYdWWnG5241UJdD7tnYY_Ju
 HC18s=ig7LiGzP4X2ZJJMrsq4695g43cu8ghuBAAdEq6F3jrYe=
 ---
 
 Karl -
 
 Thanks.
 
 The key is already plugged in.  Mr [Naive] Nice is using the computer, and is 
 logged in.  Mr. Ugly just want to look at the computer.
 
 Ethan
 
 
 
 --
 PHP Database Mailing List 
 (https://urldefense.proofpoint.com/v2/url?u=http-3A__www.php.net_d=AwIC-gc=4R1YgkJNMyVWjMjneTwN5tJRn8m8VqTSNCjYLg1wNX4r=pRBqy2P3JaV_0yIqjAsPRpV2yZymYr9X5J_0Y74t654m=kIedOn0p3VGnUZ1gfYdWWnG5241UJdD7tnYY_JuHC18s=saaG6YC7fWss2eAYUsXw7GU0vdZKj74Uz3iVA1Enu40e=
  ) To unsubscribe, visit: 
 https://urldefense.proofpoint.com/v2/url?u=http-3A__www.php.net_unsub.phpd=AwIC-gc=4R1YgkJNMyVWjMjneTwN5tJRn8m8VqTSNCjYLg1wNX4r=pRBqy2P3JaV_0yIqjAsPRpV2yZymYr9X5J_0Y74t654m=kIedOn0p3VGnUZ1gfYdWWnG5241UJdD7tnYY_JuHC18s=b2pGut3zlmECebRRBhfyRBYokCPeQHk8ZPkcdNA2RzQe=
  
 
 
 -- 
 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] Code Security

2015-02-12 Thread Ethan Rosenberg

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


--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DB] Code Security

2015-02-12 Thread Karl DeSaulniers
Prevent THIS from ever happening.

On Feb 12, 2015, at 11:03 PM, Ethan Rosenberg erosenb...@hygeiabiomedical.com 
wrote:

 He asks Mr.[naive]Nice if he could look at the computer while it is logged in.


Otherwise, I would say an external key that has a salt stored on it that the 
user has to insert in the computer before the system can be accessed. 
Like an access key card. Immediate shut down when tampered and/or removed.

Just a stab in the dark though. 

Best,

Karl DeSaulniers
Design Drumm
http://designdrumm.com




--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DB] Code Security

2015-02-06 Thread Bastien Koert
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 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 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



 --
 PHP Database Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php




-- 

Bastien

Cat, the other other white meat


Re: [PHP-DB] Code Security

2015-02-06 Thread Richard


 Original Message 

 On Feb 5, 2015, at 8:24 PM, Ethan Rosenberg
 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 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

 Date: Friday, February 06, 2015 04:49:04 +
 From: Felicia Case feli...@cwu.edu

 Hi Ethan,
 
 If the user is to neither write nor use the code then why do they
 have access in the first place? Just wondering.  
 
 F 
 

Your post is, still, rather lacking in useful details...

You are saying that you have written a POS system in interpreted
code, without an interface/wrapper (much less client/server
separation), so for someone to use it they can have direct access to
the (plain text) code files? In my book, this type of setup wouldn't
pass the most basic security audit, and I can only imagine the
potential issues with pci and hippa (assuming the latter given your
previous posts).

You haven't indicated the OS. If it's windows, I think the bets are
mostly off. In a *nix environment, you can control writes with
ownerships and file permissions, but with interpreted code the
(plain text) files need to be readable. Given what you seem to be
trying to do, I don't think that chrooting the worker's login will
work. 

You may want to look into kiosk mode options -- for both windows
and *nix -- as that generally disables access options other than the
controlled interface.

In a *nix environment I would probably start with VMs in order to
provide client/server separation, but still on a single box. 

Of course, all this is well beyond the scope of the php-db (or even
php-general) list. You should really take your questions to
os-specific security/hardening lists.


   - Richard




-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DB] Code Security

2015-02-05 Thread Felicia Case
Hi Ethan,

If the user is to neither write nor use the code then why do they have access 
in the first place? Just wondering.  

F 



 On Feb 5, 2015, at 8:24 PM, Ethan Rosenberg 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 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
 
 
 -- 
 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] Code Security

2015-02-05 Thread Ethan Rosenberg

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 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


--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DB] Code Security

2015-02-05 Thread Richard Quadling
On 5 February 2015 at 05:52, Ethan Rosenberg 
erosenb...@hygeiabiomedical.com wrote:

 How do I prevent someone from opening a terminal window, going to /var/www
 and stealing all my code?


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.



-- 
Richard Quadling


Re: [PHP-DB] Code Security

2015-02-05 Thread Richard


 Original Message 
 Date: Thursday, February 05, 2015 13:10:51 +
 From: Richard Quadling rquadl...@gmail.com
 To: E Rosenberg erosenb...@hygeiabiomedical.com
 Cc: PHP Database List php-db@lists.php.net
 Subject: Re: [PHP-DB] Code Security

 On 5 February 2015 at 05:52, Ethan Rosenberg 
 erosenb...@hygeiabiomedical.com wrote:
 
 How do I prevent someone from opening a terminal window, going to
 /var/www and stealing all my code?
 
 
 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.

  -- 
  Richard Quadling


As Richard [Q...] implies, the only people who are going to be able
to open[ing] a terminal window to your site are those you've given
that level of access to. A user only has access to the
server-parsed php files (whether they are using a browser or
telnetting directly to port 80). They don't have filesystem access.

Now, if you have open/poorly secured ftp/sftp/scp/telnet/ssh ...
access, someone who can utilize that route will have fairly
unconstrained access to your site and its contents. However, that's
basic access control security and not a php-specific issue.

If it's contractors/co-workers who have filesystem access to the
site, in order to manage content, then you have a trust issue. 

If your concern is with others on the site (e.g., a shared hosting
environment) then you have a basic hosting security issue, and
problems well beyond the control/scope of anything php. 



- Richard




-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DB] Code Security

2015-02-05 Thread Bastien Koert
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 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.
 


 --
 PHP Database Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DB] Code Security

2015-02-05 Thread Omar Muhsin

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.




--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php