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

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

Reply via email to