Posted by Gordon Burditt on 12/07/87 11:27

>We are not trying to hide sensitive data that belongs to us. The
>sensitive info is the users' data (e.g., their passwords).

Does the admin of the server on which the PHP code is running want
the check to work, or does he want to subvert it?

If it's a user's password, why is it in the PHP script (as distinguished
from a database)? Or are you talking about passwords users enter
into their clients to log in?

>Are you saying that this is theoretically impossible? Then we should
>just find a solution that makes the hacker's life more difficult.

If the *SERVER ADMIN* is trying to compromise your code (e.g. it's
some kind of copy protection or licensing check), you don't have
much chance of stopping it. The same applies to a hacker who manages
to get root on the box and who spends enough time to understand the
problem. Pre-scripted attacks are much easier to stop. Another approach
is to put a key part of the operation of the system on a server *YOU*
control, so, for instance, if an activation key gets posted on the
Internet and is widely abused, you can deactivate it.

Doing something like opening the file $_SERVER['PHP_SELF'], computing
a checksum of it, and checking it against a known value is easily
defeated by a human who understands the code, but it will trip up
a virus that simply sticks logging code at the beginning of the
script to leak passwords to a remote (evil) system, at least until
your technique becomes so common that it's worth writing an attack
to defeat it. Oh, yes, you probably have to checksum all of the
file EXCEPT the part containing the 'correct answer', as computing
the checksum of the script when it already contains the answer you're
trying to compute is intentionally difficult, so you might checksum
all but the first line, and the first line is:
<?php $md5sum='a37862648cde79877987383992';

It would work better if you can introduce a system that can be
considered secure. For example, you don't just check the checksum
of the script *in the script*, you also output it to the browser
(perhaps hidden in a HTML comment). Your customer registers his
URL where he installs the script with you, and you poll them all,
verifying the checksum. If it changes, you raise an alarm. We're
assuming that the hacker can't get your customer's server and your
monitoring system at the same time, so replacing the 'correct answer'
is harder to do. Nagios is a nice monitoring system that can run
all sorts of periodic remote checks on your network (like that your
web server is up, that your cert is not expired, and you could do
just about any check on a web page returned that you can write a
script to verify).

>We cannot be the first one running on to this problem. There must be a
>solution that doesnt require temper-proof smart cards.

Tamper-proof smart cards are needed where the holder of the card wants
to cheat the system and there's enough monetary incentive for him
to use a lot of effort trying to do so. I originally thought this
was the situation you were describing, apparently I misinterpreted
what you wanted.

Gordon L. Burditt

[Back to original message]