Authentication of machine before installation (to stop piracy) I have a web-software project which needs a bit of protection in form of authencitation…

This web based software runs on an intranet. There is no access to the internet from these terminal machines. Nevertheless, I want to stop anybody who copies the (PHP-based) software and tries to run that software on another machine. Simpler said: it should only run in the machine in which it got installed and just stop during authentication-level on any other machine. 

I would be grateful to anybody who can suggest me the logic of achieving it.
Thinking "crypto"…

One way I could imagine how you achieving at least some kind of copy-protection on your PHP-based scripts is to use solutions like these random search results: sourcecop, sourceguardian, phpcipher, … or the more well-known, and well-vetted Zend Guard or IonCube PHP Encoder who prevent reverse engineering through PHP encoding and obfuscation and thereby protecting your PHP code from unauthorized use.

But while those (partly cryptographic) script-protection solutions protect your PHP sourcecode, they (mostly) will not lock the scripts down to a single machine… 

Blending in additional "security"…

To make the "encrypted PHP scripts" idea usable in your case, you could make your encrypted scripts dependent on some kind of self-coded PHP extension/module that locks itself to a single machine by letting the module verify a machine fingerprint (which includes several serial numbers, hardware configuration, etc.). Somewhat like cryptographically secure RNGs are seeded, but you would be looking for fixed and unique instead of variable and random hardware infos.

Thinking about it, you would probably be able to solve your problem by starting out with that PHP module and make it (a) machine-dependent, and (b) handle the cryptography of your encrypted scripts. If the module isn't in place and verified it's running on the correct machine, the scripts would not execute either as they would look to the PHP interpreter as if they were random digital garbage.

But the downsides of such an approach are pretty clear too, indicating that this is not an option for regular intranet projects. You would need to code (C/C++) a PHP module from scratch, you would need to get the crypto right, you would need to handle potential bottlenecks and slowdowns due to the PHP module's calculations, and much… much more. 

And even then, someone who's able to reverse-engineer your module (or emulate the hardware environment parameters the module checks) would be able to "break" your protection. After all, if an attacker can grab your PHP files from your intranet server, he won't have too much of a problem grabbing your PHP module too. The rest of the attacker's job would boil down to a reverse-engineering effort. 

Reality-Check…

Obviously, there are some potential options that could tackle the problem, but unless you are working on a big project for some government/corporation/institution, it'll be "overkill" to even think about practically implementing them as they will simply use up too much time and manpower to create from scratch.

From my point of view, the cheapest, the fastest, and the safest way to protect your PHP scripts would not be by means of modern cryptography, but by buying a good lock for your server-room. After all, restricting physical access is the safest way to stop an attacker from copying files from the (locked-in) intranet server. And if you're really fond of cryptography, get one of those electronic locks with a nice interface to put next to the server-room's door… it looks good and entertains you with lock-codes. ;) Throw Zend Guard or IonCube PHP Encoder on top of that and you should be able to say "mission accomplished" — but only for non-critical, civilian purposes where the sole goal is to protect your PHP scripts from being stolen and executed/run on another computer system.