security advice

[Cees De Groot]

On 11/10/05, Chris Muller <chris at funkyobjects.org> wrote:
> Magma must have security or it will never work directly on the Net.

Well, you are free to do as you like with Magma, but I could not care
less. I'm not even sure it'd be nice to have security in Magma, and if
so - please make it optional.

> "I would suggest going with a system that always encrypts automatically to see
> how you like it..."

Now, that's the sort of stuff that makes me cringe. Crippling local
network speed by encrypting everything. It's still hard for a CPU to
saturate network bandwidth on an ecrypted link, and for
high-performance applications can well do without that burden.

If you really insist on adding it, I would strongly suggest that you
create latent security in the server (iow - the server can accept by
default both clear and encrypted links and a policy setting could
always disable the cleartext bit) and a secure client as an
alternative to the default.

But what's the idea of exposing a database to the internet anyway? I
really can't think of a reason. I'd never in my life do it.

Case in point - the last project I setup where security was anywhere
on the requirements list we didn't even expose the database to the
webserver. Instead, we allowed access to the database only from
localhost, and on that host we ran a basic apache server and every
query that the webserver wanted to do got wrapped in an xml-rpc
service in that apache server.

So for security analysis on that site, we don't need to go through
lengthy evaluations of database-level security (or even table-level or
row-level, both absent in Mysql anyway ;)), we simple do 'more *' in
the XML-RPC service directory and get a list of queries that are
allowed.

This sort of stuff does not, IMNSHO, belong in a persistence engine.
Not even an object persistence engine. Persistent objects don't
usually form the application layer.

But then, prove me wrong. I liked to be proven wrong if it makes life
simpler for me ;)