Also ob das das Gelbe vom Ei ist..

PHP-Scripte verschlüsseln leicht gemacht... (20 Beiträge, 219 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

hi @all
an alle PHP freaks die PHP scripten den besseren schutz verpassen wollen will ich auf diesem wege meine persönliche erfahrung mitteilen...

motivation: mir war es leid meine DB-Passwörter in plaintext abzulegen und ich wollte meinen kunden trialware (zeit limitierte software) anbieten können ohne der gefahr zu laufen dass wer auf die dumme idee kommt ein sicherheits-backup der scripte zu erstellen...

ich war auf der suche nach einer PHP-Verschlüsselung (encoding) und habe mehrere systeme unter die lupe genommen...

die 3 kandidaten waren:
IonCube ( http://www.ioncube.com/  )
Zend ( http://www.zend.com/store/products/zend-safeguard-suite.php  )
SourceGuardian ( http://www.sourceguardian.com  )

ich will jetzt nicht alle vor und nachteile aufzählen aber;

IonCube
+ sehr günstig
+ viele funktionen
- man muss den ApacheServer neustarten und in der php.ini herum pfuschen
- da ich den INODE server nicht rebooten durfte konnte ich es nichmal testen

Zend
- sehr teuer
- nicht alle encoder versionen sind mit allen PHP versionen kompatibel

- nicht alle encoder versionen sind mit dem hauseigenen Zend Optimizer kompatiebel

- wollte einfach nicht funktionieren (PHP version war zu alt)
+ verdammt gute verschlüsselung
+ dateien sind im binary format
+ PHP Acceleration
+ alle funktionen die sich ein developer wünscht

SourceGuardian
+ preis ist im grünen bereich
+ gute funktionen
+ mit 4 klicks sind die dateien servierfertig (hehe SERV(i)ER-FERTIG

)
+ hat auf anhieb am server funktioniert
+ verschlüsselung ist gut
+ funktioneiert unter linux, windows, mac os x, freebsd und sun
+ man muss keine zusätzliche software am server installieren oder gar http-server restarten

+ kleine updates sind gratis
- um die backupfiles muss man sich selbst kümmern (dateien werden sonst überschreiben)
- die funktionen sind zwar gut aber eher unflexiebel...
- man kann nach der encodierung nur händisch copyright infos hinzufügen
- keine PHP Acceleration, im gegenteil wird es unbedeutend wenig langsamer

Fazit: SourceGuardian ist gut und bietet genug schutz... also viel spass beim ENCODIEREN

lg.
Ice-Tea (mit Zitrone)

Wunschdomain noch frei?

"Es gibt 3 Stadien der Verblödung. Im ersten merkt man es nur selber, im zweiten merken es auch die anderen und im dritten merken es nur noch die anderen. Dann ist es wieder schön. Bei mir ist es schön."

Re: PHP-Scripte verschlüsseln leicht gemacht... (Spedi am 17.03.2005, 09:35:01)

Re(2): PHP-Scripte verschlüsseln leicht gemacht... (Robert Craven am 17.03.2005, 09:37:17)

Re(3): PHP-Scripte verschlüsseln leicht gemacht... (Spedi am 17.03.2005, 09:39:24)

Re(4): PHP-Scripte verschlüsseln leicht gemacht... (Robert Craven am 17.03.2005, 09:42:17)

Re: PHP-Scripte verschlüsseln leicht gemacht... (Robert Craven am 17.03.2005, 09:36:51)

Re(2): PHP-Scripte verschlüsseln leicht gemacht... (Ice-Tea am 17.03.2005, 13:25:15)

Re(3): PHP-Scripte verschlüsseln leicht gemacht... (gepeinigter_aon_neukunde am 17.03.2005, 13:46:19)

Re(4): PHP-Scripte verschlüsseln leicht gemacht... (Ice-Tea am 17.03.2005, 13:52:54)

Re(5): PHP-Scripte verschlüsseln leicht gemacht... (gepeinigter_aon_neukunde am 17.03.2005, 13:59:22)

Re(6): PHP-Scripte verschlüsseln leicht gemacht... (Ice-Tea am 17.03.2005, 14:25:19)

Re(7): PHP-Scripte verschlüsseln leicht gemacht... (mIstA am 17.03.2005, 14:45:52)

Re(8): PHP-Scripte verschlüsseln leicht gemacht... (Ice-Tea am 17.03.2005, 16:06:00)

Hi !

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.

[2] Versteh' ich die Aufgabe net (Klartext-DB-Kennwörter) und so.
Unterscheiden wir Szenarien:
S1: Webserver bei dir
S2: Webserver bei Kunde, DB-Server bei dir
S3: Alles beim Kunden, dedizierter Server
S4: Alles beim Kunden, deine App ist eine von vielen.

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).

S2:
Wenn nur der Webserver beim Kunden steht - dann würde ich einen User für die ganze Firma verwenden - sodaß du leicht die ganze Firma in ihren Permissions ändern kannst. Das hat den Vorteil, daß du dann leicht die Tabellen benutzer, tabelle, benutzer_tabelle anlegen kannst und die Firma dann ganz leicht durch inserts/updates/deletes (egal wie - du bietest in deiner App natürlich einen Menüpunkt dafür an) die 3 Tabellen warten kann und die Firma sich leicht neue Benutzer mit eingeschränketen Rechten anlegen kann. Die Security (daß sich eine Firma net mehr Rechte gibt als sie soll) kannst dann bequem durch ein paar
ON INSERT/UPDATE/DELETE INTO ... DO INSTEAD... - Rules abfackeln.

S3: Alles beim Kunden, dedicated Server
Das ist mein persönlicher "Standardfall". Den erschlag' ich in der Regel so, daß ich die komplette Systemwartung übernehme. Mit ein bißchen Redundanz der üblichen Verdächtigen (RAID, Netzteile, ..) kannst bei HW-Ausfällen Reaktionszeit gewinnen.

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...

Ich persönlich mag Verschlüsselung net. Aus der Praxis: Die Masse der Leutchen (will net auf dich anspielen) schreibt irgendeinen Schrott, verschlüsselt den und liefert aus. Du als Endkunde hast dann das Problem, daß du net einfach ermitteln kannst, warum denn in deinem Fall das Ding net so läuft wie dokumentiert. Oft hast dann einen Riesenaufwand (gdb, [sl]trace, ...) nur um zu ermitteln, wo der Coder den genau Schrott baute um einen Workaround)

Re: Also ob das das Gelbe vom Ei ist.. (Ice-Tea am 17.03.2005, 13:18:14)

Re(2): Also ob das das Gelbe vom Ei ist.. (gepeinigter_aon_neukunde am 17.03.2005, 13:28:22)

Re(3): Also ob das das Gelbe vom Ei ist.. (Ice-Tea am 17.03.2005, 13:46:11)

Re(4): Also ob das das Gelbe vom Ei ist.. (gepeinigter_aon_neukunde am 17.03.2005, 13:57:31)

Re(5): Also ob das das Gelbe vom Ei ist.. (Ice-Tea am 17.03.2005, 14:13:39)

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung