Also für mich klingt das ganz anders, als du beschreibst:
[1] dachte ich immer, daß Zend im Prinzip den Source in einen P-Code übersetzt
und u.a. damit die Performance erhöht. Dann hast aber deinen Source net
verschlüsselt sondern maximal verschleiert. Die Frage wäre - kannst sicher
schnell ausprobieren - ob man mit einem trivialen "strings" net einfach auf
die Kennwörter kommt.

S1:
es geht dir also darum, deinen Rechner zu schützen, falls die böse Eve ihn
heimsuchte.
Nun denn, dann bleibt uneinsichtig, warum irgendein user (außer www) auf die
Dateien Zugriff haben soll. Ein Plaintext-PW ist net schlecht, wenn net einmal
root auf die Datei zugreifen darf. Kurzum: Du hast dann ein gaaanz schlimmes
Security-Problem - daß du besser durch die Kombination von 2 anderen
Mechanismen löst: SE (um im Betrieb zu schützen) und vercryptete Dateisysteme
(um vor dem mit einer Knoppix bewaffneten und physichem Zugriff auf den
Rechner habenden zu schützen).

S4: Alles beim Server, du bist net root, ...
Auch das macht i.d.R. keinen Streß.
Meine PHP-Scripts sind in der Regel nur die Userinterfaces (ähnlich wie andere
gerne Access als Frontend verwenden). Die Business Logic hat am Frontend IMHO
eh' nix zu suchen, denn dann mußt sie doppelt warten (Jeden denkbaren
Constraint bau' ich in die DB ein - das erspart viel Streß nachher) - in der
DB und am Frontend. Im Endeffekt findet das ganze "schützenswerte" eh' in den
Stored Procedures in der DB statt - und der Kunde soll sich seine eigenen
Kennwörter ausdenken (die ich net mal wissen will). Wenn es ein Prob gibt,
soll er dir temporär ein Kennwort geben und du dann remote oder lokal
einsteigen. Das "Timeout" für die Testphase hast dann bequem in einer der DO
INSTEAD-Rules verpackt...

Wunschdomain noch frei?