[PHP/Javascript] Encryptie verschil

[sorted.bits]

De situatie is als volgt :

Ik heb 2 servers :
Server 1 : In eigen beheer, draait Windows 2000, IIS 5, ServerSide Javascript, ASP, ASP.NET (1.1 en 2.0).
Server 2 : Niet in eigen beheer, draait PHP 4.4.x.

Het is de bedoeling dat server 2 een tekst genereert, deze encrypt en dan een simpele HTTP GET uitvoert op server 1. Ik heb het internet afgespeurd en kwam er achter dat Blowfish een goede encryptie is voor onze toepassing en ook waren er leuke SSJS en PHP modules voor te vinden.

Tot zover alles nog goed, echter...

Bij het testen van de encryptie functies, krijg ik elke keer op beide machines een andere uitkomst. Ik probeer een simpele tekst met dezelfde key te encrypten en toch heb ik elke keer een andere uitkomst.

Op de PHP machine maak ik gebruik van de laatste Crypt versie van PEAR. Veel andere mooie encryptie scripts kan ik niet vinden.
Bij de SSJS machine heb ik een aantal scripts geprobeerd, allemaal gaven ze een ander resultaat dan de PHP machine. Het rare is ook dat het ene script weer een andere uitkomst gaf dan de andere.

Is er iemand met ervaring in dit soort dingen? Ik wil wel source code kopieren plakken, maar aangezien het om enorme lappen code gaat, lijkt het me handig eerst te kijken of iemand anders dit al eens bij de hand heeft gehad.

Wat heb ik nog niet geprobeerd (ga ik nu doen) : kijken of er in ASP.NET 2.0 encryptie mogelijkheden zitten, welke ik eventueel ook in PHP kan maken. Echter SSJS heeft mijn voorkeur, aangezien de complete website hier al op draait.

[gorgi_19]

Wat heb ik nog niet geprobeerd (ga ik nu doen) : kijken of er in ASP.NET 2.0 encryptie mogelijkheden zitten, welke ik eventueel ook in PHP kan maken. Echter SSJS heeft mijn voorkeur, aangezien de complete website hier al op draait.

Ja, die zijn er. Zie de cryptography namespace. dit horen standaard methodieken te zijn; evt. kan je met reflector eea achterhalen.

[sorted.bits]

Yup, thanks, zover was ik inmiddels al wel, nadeel is echter dat ik dit dus weer in een ASP (icm ServerSide JS) website moet gaan inpassen .

[RobIII]

Ook iets om op te letten: Unicode strings leveren nog wel eens andere "uitkomsten" dan "gewone strings"

[Annie]

sorted.bits schreef op dinsdag 26 september 2006 @ 21:48:
Het is de bedoeling dat server 2 een tekst genereert, deze encrypt en dan een simpele HTTP GET uitvoert op server 1.

SSL is geen optie?

[crisp]

Je zegt dat je een HTTP GET doet; ik neem aan dat je je query-parameters wel urlencode? Oftewel: check serverside eens of de waarde die je binnenkrijgt wel exact de waarde is die je verstuurd hebt.

[sorted.bits]

Nou het probleem is, dat ik eerst gewoon wat tests doe zonder de HTTP GET, dus ik laat PHP en de SSJS allebei gewoon een string op het scherm tonen. Aangezien die uitkomsten allebei al niet hetzelfde zijn heeft het ook nog geen zin om die door te gaan sturen.

SSL is inderdaad geen optie, want de URL moet niet leesbaar zijn, maar wel decryptable zijn (anders had ik nog md5 hashing ofzo kunnen gebruiken).

Unicode, mmm, dat zou ik nog eens kunnen bekijken.

[Annie]

sorted.bits schreef op woensdag 27 september 2006 @ 07:37:
SSL is inderdaad geen optie, want de URL moet niet leesbaar zijn, maar wel decryptable zijn (anders had ik nog md5 hashing ofzo kunnen gebruiken).

Voor wie moet de URL niet leesbaar zijn? Voor de gebruiker zelf? Dat lijkt me niet de beste manier om "beveiliging" toe te passen.
Sowieso ben ik dan wel benieuwd waarom de gebruiker die gegevens niet zou mogen zien. Zou je wat meer toelichting kunnen geven over wat je aan het bouwen bent?

[ Voor 7% gewijzigd door Annie op 27-09-2006 08:40 ]

[frickY]

Bekend probleem, heb er ook even mee zitten stoeien. Zie mijn topic en mijn eigen edit in de TS voor mijn oplossing: [PHP +VB] Blowfish encryptie

[ Voor 79% gewijzigd door frickY op 27-09-2006 09:18 ]

[Equator]

Annie schreef op woensdag 27 september 2006 @ 08:39:
[...]

Voor wie moet de URL niet leesbaar zijn? Voor de gebruiker zelf? Dat lijkt me niet de beste manier om "beveiliging" toe te passen.
Sowieso ben ik dan wel benieuwd waarom de gebruiker die gegevens niet zou mogen zien. Zou je wat meer toelichting kunnen geven over wat je aan het bouwen bent?

* Eensch is..
En is het anders niet interessanter om de data te posten naar de PHP pagina i.p.v. een querystring verkeerdom gelezen..

[sorted.bits]

Hetgeen wat ik aan het bouwen ben is redelijk simpel.

Er is een website (op de php machine), welke een link op zijn frontpage heeft staan naar de website die bij ons gehost wordt. Aangezien je op onze site moet inloggen, willen ze vanaf die link direct op onze website komen en ingelogt zijn.

Wat ook de bedoeling is, is dat die url maar bijvoorbeeld 24 uur geldig mag zijn. Er moeten dus een paar dingen verstuurd worden vanaf die website. Een datum/tijd, een gebruikers-naam en evt. iets van een wachtwoord.

Als ik de url niet encrypt dan kan natuurlijk iedereen die URL pakken en de datum in die url aanpassen, zodat hij altijd kan inloggen.

Wat ik nu gemaakt heb, is een URL die een username, een password, een datum/tijd en een random string bevat. Deze wordt ge-encrypt op de php server en weer ge-uncrypt op de JS server. Dan wordt gecontroleerd of de url nog valide is.

Ja het is een ietwat omslachtige manier, maar zoiets willen ze graag gebruiken.

De manier waarop ik het nu heb opgelost is nog omslachtiger (om het encryptie probleem te omzeilen).

Ik laat de PHP server, de gegenereerde URL uitlezen vanaf onze JS server. Deze plaatst hij (gecached) op zijn frontpage. De URL kan natuurlijk alleen uitgelezen worden vanaf een bepaald IP adres.

[frickY]

Je had niets aan het topic dat ik noemde in mijn eerdere post

[sorted.bits]

Ik ga dit nog even proberen inderdaad, alleen nog geen tijd voor gehad. Tenminste, geen tijd meer aan willen verspillen Ik ga er morgen nog even voor zitten en laat het weten.

[Annie]

sorted.bits schreef op woensdag 27 september 2006 @ 18:59:
Hetgeen wat ik aan het bouwen ben is redelijk simpel.

Er is een website (op de php machine), welke een link op zijn frontpage heeft staan naar de website die bij ons gehost wordt. Aangezien je op onze site moet inloggen, willen ze vanaf die link direct op onze website komen en ingelogt zijn.

Wat ook de bedoeling is, is dat die url maar bijvoorbeeld 24 uur geldig mag zijn. Er moeten dus een paar dingen verstuurd worden vanaf die website. Een datum/tijd, een gebruikers-naam en evt. iets van een wachtwoord.

Wat heeft het voor zin om de URL maar een bepaalde tijd geldig te laten zijn of om uberhaupt te encrypten, als je toch gewoon naar de PHP site kan gaan om weer een link te krijgen waarmee je kan "inloggen" op de JS site? Of mis ik nog wat informatie?

Als ik de url niet encrypt dan kan natuurlijk iedereen die URL pakken en de datum in die url aanpassen, zodat hij altijd kan inloggen.

Zoals ik het nu begrijp, kunnen ze ook gewoon terugkeren naar de PHP site voor een nieuwe URL.


Je zou imho eens moeten kijken naar single sign-on (SSO) principes. In het kort: laat gebruikers inloggen via de PHP site op een centrale authenticatie applicatie (die een ticket retourneert). De JS site kan dan via het ticket controleren of de gebruiker een geldige inlogsessie heeft.

De constructies die je nu zelf aan het bedenken bent, geven een pseudo-veiligheid. Imho verspilde tijd en moeite.

[Helza]

Vergeet niet dat eventuele returns (\n -> \r\n) verschillend zijn tussen *nix platvormen en windows..
dus als er een return in de tekst zit kan dit ook verschil genereren..

[sorted.bits]

Annie schreef op woensdag 27 september 2006 @ 22:39:
[...]

Wat heeft het voor zin om de URL maar een bepaalde tijd geldig te laten zijn of om uberhaupt te encrypten, als je toch gewoon naar de PHP site kan gaan om weer een link te krijgen waarmee je kan "inloggen" op de JS site? Of mis ik nog wat informatie?

Dit is exact de werking die ze willen hebben, ze willen inderdaad dat je elke keer de andere site bezoekt. Dat het om 'pseudo' veiligheid gaat, dat is ook bij de klant duidelijk. Het voordeel is ook dat het account waarmee ze inloggen op de SSJS site, een account is waar niet bijzonder veel rechten aan zitten.

De manier die ik nu gekozen heb, is misschien wat ingewikkeld, maar een stuk simpeler te implementeren op de externe site (3 regels PHP code). Voordeel is ook dat wanneer er nog zo'n constructie moet komen voor een andere externe website, welke evt weer in een andere prog. taal is gemaakt, ik bijna niets hoef te veranderen . (ook erg belangrijk voor onze klant..)

[MBV]

Waarom maak je geen MD5 hash van de eerste 3 parameters (user/passwd/tijd) + vaste salt en geeft die als 4e parameter mee? Vervolgens check je of de hash klopt op de andere server, en je bent klaar. Letterlijk 3 regels code (als je een beetje je best doet ) op de PHP server, 3 regels op de SSJS server, en geen javascript-afhankelijkheid.
Alles wat je in JS gaat rommelen kan de gebruiker nadoen (Firefox met DOM Inspector) dus veiligheid geeft het niet. Ook zijn er gebruikers (toegegeven, weinig) die geen JS hebben.

[ripexx]

MBV schreef op donderdag 28 september 2006 @ 19:17:
Waarom maak je geen MD5 hash van de eerste 3 parameters (user/passwd/tijd) + vaste salt en geeft die als 4e parameter mee? Vervolgens check je of de hash klopt op de andere server, en je bent klaar. Letterlijk 3 regels code (als je een beetje je best doet ) op de PHP server, 3 regels op de SSJS server, en geen javascript-afhankelijkheid.
Alles wat je in JS gaat rommelen kan de gebruiker nadoen (Firefox met DOM Inspector) dus veiligheid geeft het niet. Ook zijn er gebruikers (toegegeven, weinig) die geen JS hebben.

Volgens mij bedoeld de TS dat hij in de ASP pagina's Javascript serverside gebruikt, ipv bijvoorbeeld vbscript. Dus echt ver kom je dan niet met FF DOM inspector.