Prevent Modification of Script?

Subscriber123 subscriber123 at gmail.com
Thu Apr 5 13:53:01 EDT 2007


If you are *really* worried about the database being attacked and edited,
encrypt it by private key: require that the user set a password and use that
password every time that s/he accesses the database. I am afraid that you
cannot really prevent the database from being deleted completely, but you
can stop it from being edited such that it actually contains readable
information.

I am repeating what someone else has already said, but how likely is it that
someone will attack your program specifically with malware?

The very worst that can happen is that someone replaces your application
completely, and there is no way to prevent this. There are probably much
better things to replace than your program (such as OS files that are run
during startup).

Perhaps now would be a good time for me to begin my rant about how security
has all been gone about the wrong way within computers (network security is
just fine, with the exception of WEP).


Part I: the problem

Firstly, it is possible to bypass all security in Windows (I only talk about
windows because I have not used any other OS enough to know the security
flaws, not because they are any better). This is because Windows runs on top
of the bios, which runs on top of the hardware. Making calls to the bios or
the hardware directly therefore bypasses Windows, and allows you to do
anything that Windows might prevent you from doing (this is all theoretical,
by the way).

I have actually managed to log into other users of whom I do not know the
password in Windows 98. It is quite simple, in fact I discovered it by
accident. If that user was logged in last, and shut down the computer, you
(1) start up the computer, (2) type in a few bogus passwords in the login
screen and try to login with them, and (3) clear the password field, and
press login. You will login as that previous user.


Part II: what is wrong with this

The OS should not be inhibiting users or programs from doing things. These
things can be done anyway by bypassing it. This is a security flaw that can
be fixed (and will be in a computer that I am in the process of designing:
don't expect it to be on the market any time soon).

Current security is like security written in javascript (client side). The
browser checks a form against source code which is available to the user to
see if the password is correct, and then goes to a page, the URL of which is
also available to the user in the source code.

My planned security is more like security written in php (server side). The
browser submits the form, and the server checks it against a database,
choosing the location which the browser goes to based on that. The location
to which the browser is sent was not previously available to the user in the
source code. It was safely hidden away in a remote database for which the
user had no access.


Part III: the solution

Since I will be including the solution in my design for a computer, I can
only vaguely explain it. When programs run, they will be given a password.
When the program tries to connect to a piece of hardware, they must securely
pass the password to that hardware. The hardware then decides what rights
the program has to it based on the location of the password in a database.
The OS will inhibit nothing. The hardware will inhibit everything. Not even
the OS nor the hardware has access to the contents of the database: They can
only compare passwords against it, just like anything else.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20070405/02f78536/attachment.html>


More information about the Python-list mailing list