How to protect Python source from modification

[Magnus Lycka]

Frank Millman wrote:
> Hi all
> 
> I am writing a multi-user accounting/business system. 
Good!

> The client program contains all the authentication and business logic.
Not good. You lose...if it's *only* in the client.

Of course, there is no such thing as a safe system, and you need
a pragmatic approach to deciding a level of security.

For a system like this, I'd certainly prefer to design the system
so that it's immune to modifications in any software running on a
machine that isn't "safe", such as a typical end user PC. IOW, no
direct DB access allowed (at least not with anything but select
permissions) and all authentication and security related verifications
etc in a server process which isn't available to ordinary users.

However, such schemes aren't immune to flaws. First of all, there
might be mistakes in the implementations (how ever cleverly they
are made) and there are always people who have access to servers
and databases.

You need audits and checks on various levels to handle such things.
You can probably get transaction logs for the database system to
be stored on some other server, which might make it more difficult
for someone who manipulates the system to hide their tracks. All
external transactions (especially payments from the system) need
to be audited and scanned for irregularities. Can all payments be
traced back to valid business transactions? Are there patterns in
payments that stick out, such as many small transactions to the
same receiver? Security checks like these should probably be made
completely outside your accounting/business software, and by people
who have nothing to do with your main system.

Regardless of your intentions, there is no way you can stop people
from hurting themselves. The customer of the system will basically set
a ceiling for the security of the system, depending on how ambitious
they are, and what kind of infrastructure they can provide etc.
Small customers might well demand perfect security, but they probably
don't want to pay for it.

> It has dawned on me that anyone can bypass this by modifying the
> program. As it is written in Python, with source available, this would
> be quite easy. My target market extends well up into the mid-range, but
> I do not think that any CFO would contemplate using a program that is
> so open to manipulation.

Just distribute zipped library instead of .py files, and you've raised
the bar to the same level as if you've written it in Java. I.e. it's as
if you send your mail in envelopes (just not glued together) instead of
in postcards. No one will accidentally see the source code, but the
persistent user can.

> There is the question of where state should be maintained. If on the
> server, I would have to keep all the client/server connections open,
> and maintain the state of all the sessions, which would put quite a
> load on the server. 

Really? How many users do you imagine? How would you plan to organize
your servers? One process per connection, one thread per connection or
asynchronous processing in one thread as in Twisted or asyncore? Perhaps
you should have a look at Twisted ot asyncore?

> This raises the question of whether I should even bother with a gui
> client, or bite the bullet and only have a browser based front end.
> Judging from recent comments about new technologies such as Ajax, a lot
> of the disadvantages have been overcome, so maybe this is the way to
> go.

It's still a big difference, isn't it? Have you seen a web based
accounting system that you thought was good enough?

> It would be a shame to scrap all the effort I have put into my
> wxPython-based front end. On the other hand, it would be pointless to
> continue with an approach that is never going to give me what I want.
> Any advice which helps to clarify my thinking will be much appreciated.

A wxPython client and a Twisted server might well be a useful combo. If
you have well written Python modules for validating data etc, you might
just run them in both client and server to achieve instant feedback on
the client without lowering the security bar.

A budget solution if you want to keep a simple fat client / thin server
solution is to run the clients on a box that the end users can't
manipulate. Just let them access that box via VNC and only run this
client program there. It's not completely trivial to set up such a safe
environment though, but it basically gives you an application server and
very thin clients that still give you the same rich UI as wxPython on
their desktops. They'll have to get used to a non-Windows GUI though,
unless you choose to run Citrix instead of VNC (or use one application
server per user :).