website beveiliging

[wasigh]

Voor een website wil ik een backend systeem bouwen natuurlikj moet dat beveiligd worden.. Mijn vraag is of dit systeem veilig genoeg is:

Doordat het back-end systeem een java-client is die een connectie met een een php pagina maakt is. Is het mogelijk om een beter beveiligingssysteem in te bouwen. Dan alleen met sessions. Sessions moeten verplicht unieke IDs hebben en deze kunnen geraden worden. Waarschijnlijk is het systeem dat ik beschrijf ook implementeerbaar in php op zich. Maar aangezien mijn kennis van PHP niet groot genoeg is zal ik het toch op de java manier doen;)

Ik dacht zelf aan een inlog systeem vergelijkbaar met het MSN systeem
In grote lijnen is het als volgd.
Het programma meld zich aan op de server met de username van de gebruiker
Een identifier wordt door de server naar de client gestuurd.
Deze identifier wordt met het password gecodeerd en wordt gestuurd naar de server.
Wanneer alles succesvol blijkt te zijn wordt er via een een standaard sessie id gekoppeld aan gebruiker + zijn ip. Zodat niet elke keer wachtwoorden nodig zijn.

Voordelen:
Wachtwoorden gaan niet plain-text over het intertnet
Session variabelen kunnen niet gefaket worden aangezien ze gekoppeld zijn aan IP.

Nadelen:
Geen standaard implementatie alles moet van de grond af opgebouwd worden.

Het ene gevaarlijke is dat een hacker als een soort proxy tussen de client en de server in kan gaan zitten en zo toegang kan krijgen tot de back-end.
Dit kan voorkomen worden door de client het ip-address mee te laten encoden. En op de server ook de encoden met het address waar de request vandaan komt. Het nadeel hierbij is dat waarschijnlijk mensen achter een proxy server niet in kunnen loggen. Maar dat is iets wat we moeten testen. Eventueel kunnen we een optie maken om ip-encoding aan en uit te zetten op te backend.

De hacker kan nu nog zijn IP spoofen om binnen te komen. Dit is vrijwel niet te controleren. Misschien weet iemand anders hier iets op. ?

[chem]

zoals ik je per icq voorstelde:
laat je Java client nog een HTTP header naar de server sturen met zijn public key. Deze kan je vrij obscuur en tussen neus-en-lippen-door sturen als bv. een verscholen string in de User Agent oid.

Is iig iets wat niet zo snel opvalt...

[Verwijderd]

Op dinsdag 16 oktober 2001 10:04 schreef wasigh het volgende:
Voor een website wil ik een backend systeem bouwen natuurlikj moet dat beveiligd worden.. Mijn vraag is of dit systeem veilig genoeg is:

Doordat het back-end systeem een java-client is die een connectie met een een php pagina maakt is. Is het mogelijk om een beter beveiligingssysteem in te bouwen. Dan alleen met sessions. Sessions moeten verplicht unieke IDs hebben en deze kunnen geraden worden.

Daarom dat je ze zo lang en random mogelijk moet maken. Ook als je bij elke nieuwe sessie en nieuw uniek id gebruikt, maak jet het nog moeilijker om een sessie te raden. Zet er dan ook nog een expire bij van een dag ofzo, en je hebt toch wel een redelijk secure manier van authentication.

Waarschijnlijk is het systeem dat ik beschrijf ook implementeerbaar in php op zich. Maar aangezien mijn kennis van PHP niet groot genoeg is zal ik het toch op de java manier doen

Mijn ervaring is dat als je in Java kunt coden, je ook 100% zeker in PHP kunt coden. PHP is nog makkelijker en relaxer dan Java. www.php.net/manual zou voor jou meer dan voldoende moeten zijn om met PHP te beginnen.

Ik dacht zelf aan een inlog systeem vergelijkbaar met het MSN systeem
In grote lijnen is het als volgd.
Het programma meld zich aan op de server met de username van de gebruiker
Een identifier wordt door de server naar de client gestuurd.
Deze identifier wordt met het password gecodeerd en wordt gestuurd naar de server.
Wanneer alles succesvol blijkt te zijn wordt er via een een standaard sessie id gekoppeld aan gebruiker + zijn ip. Zodat niet elke keer wachtwoorden nodig zijn.

Ik hou voor mijn PHP sites een session id bij in een cookie bij de client en in de db. Als een sessie id van een client overeenkomt met een sessie id in de db, dan neem ik aan dat dat de user is die bij dat sessie id in de db genoteerd staat.

Dat sessie id maak je dus aan als de user een geldige login heeft. Een sessie is na 1 dag verlopen (timestamp bij sessie in de db) en dan moet de user dus opnieuw inloggen en krijgt een nieuw id.

Voordelen:
Wachtwoorden gaan niet plain-text over het intertnet

Gebruik een SSL connectie, een https:// server dus. Makkelijker kan niet. De https kun je desnoods alleen gebruiken voor je login.php pagina, de rest kan gewoon un-encrypted.

Session variabelen kunnen niet gefaket worden aangezien ze gekoppeld zijn aan IP.

Dat kun je idd doen, maar ik vind het TE. Maar als je het toch gebruikt, zorg dan dat je voorziet dat er proxies gebruikt kunnen worden en dat je dus niet het proxy ip hebt, maar het echte ip van de client.

Nadelen:
Geen standaard implementatie alles moet van de grond af opgebouwd worden.

Voor PHP is er dus een hele hoop code beschikbaar, maar helaas is een groot deel daarvan rotzooi code, geschreven door mensen die totaal niet kunnen programmeren. Omdat PHP zo makkelijk is, gaat iedereen er zich mee bezig houden en soms zie ik echt vreselijk slechte dingen... pas dus op waar je je code vandaan haalt

Het ene gevaarlijke is dat een hacker als een soort proxy tussen de client en de server in kan gaan zitten en zo toegang kan krijgen tot de back-end.
Dit kan voorkomen worden door de client het ip-address mee te laten encoden. En op de server ook de encoden met het address waar de request vandaan komt. Het nadeel hierbij is dat waarschijnlijk mensen achter een proxy server niet in kunnen loggen. Maar dat is iets wat we moeten testen. Eventueel kunnen we een optie maken om ip-encoding aan en uit te zetten op te backend.

Als je inzit over het sniffen van je data, gebruik dan voor heel je connectie een SSL. IP adressen zijn ook te faken (als je je proxy gaat modifyen bv.), dus het IP meecoden gaat niet veel helpen.

De hacker kan nu nog zijn IP spoofen om binnen te komen. Dit is vrijwel niet te controleren. Misschien weet iemand anders hier iets op. ?

SSL !

[wasigh]

En als ik geen SSL tot mijn beschikking heb?

[chem]

dan kun je een kunstmatige SSL maken. Zijn er geen encryptie libs voor zowel PHP (of linux) en Java bv. PGP etc.?

Kwestie van public keys versturen en kloar. Nadeel: als iemand de Java applet onderschept tijdens versturen is het wellicht mogelijk de private key te acherhalen?

[dusty]

Eigen "sessie" systeem maken, kan je zelf de cookie zetten van hoe groot ze moeten zijn (b.v. 200 tot 250 karakters. = erg veel mogelijkheden..) dat koppelen aan de IP.

Je stuurt een random string over naar de "gebruiker" met java encrypt je die met die random string, stuurt die terug naar de server daar decodeer je, kijk je of de login klopt. klopt het dan geef je de cookie met bijbehorende IP de rechten van de gebruiker.

Ik zou zeggen ik steek weer mijn verhaaltje af waarom een eigen sessie mechanisme beter is dan de standaard maar dan kom ik toch maar weer in een standaard discussie terecht die al te vinden is via de zoek

[dusty]

Op dinsdag 16 oktober 2001 10:36 schreef chem het volgende:
dan kun je een kunstmatige SSL maken. Zijn er geen encryptie libs voor zowel PHP (of linux) en Java bv. PGP etc.?

Kwestie van public keys versturen en kloar. Nadeel: als iemand de Java applet onderschept tijdens versturen is het wellicht mogelijk de private key te acherhalen?

In principe wel, echter kan je wel zorgen dat er bij elke nieuwe bezoek een nieuwe key wordt aangemaakt dat alleen DIE sessie wordt gebruikt

[chem]

Op dinsdag 16 oktober 2001 10:44 schreef dusty het volgende:

[..]

In principe wel, echter kan je wel zorgen dat er bij elke nieuwe bezoek een nieuwe key wordt aangemaakt dat alleen DIE sessie wordt gebruikt

maar hij ZAL verstuurd moeten worden... het embedden van die string elke keer (of apart versturen) zal uiteindelijk plaats moeten vinden. En of dat nu in 1x of via een aparte verbinding plaats vindt: de pakkans blijft even groot (en toch weer heel klein)

[dusty]

Op dinsdag 16 oktober 2001 10:47 schreef chem het volgende:
maar hij ZAL verstuurd moeten worden... het embedden van die string elke keer (of apart versturen) zal uiteindelijk plaats moeten vinden. En of dat nu in 1x of via een aparte verbinding plaats vindt: de pakkans blijft even groot (en toch weer heel klein)

De kans is altijd daar, daarvoor is het internet, ben je er te bang voor moet je niet op internet gaan zitten

Laten we met zijn allen hysterisch gaan doen, blijkbaar is het "in" omdat te doen namelijk (anthrax)

[wasigh]

Op dinsdag 16 oktober 2001 10:43 schreef dusty het volgende:
[...]

Dat is eigenlijk wat ik in mijn hoofd heb.
Maar:

1> werkt dit met een proxy?
2> hoe controleer ik of IP gespoofd word?

[dusty]

Op dinsdag 16 oktober 2001 10:59 schreef wasigh het volgende:
1> werkt dit met een proxy?
2> hoe controleer ik of IP gespoofd word?

1. Ja, zorg wel dat de proxy server NIET mag cachen

2. Niet, daarvoor is het IP spoofing, moet je een beveiliging inbouwen zodat je kan controleren of het wel de echte server is. Helaas is dit ook weer na te bootsen

[wasigh]

De gekozen oplossing(met dank aan dusty)

De client meld ik zich aan. met zijn usernaam.
OP de server word een random string gegenereerd (+- 250 chars)
deze String wordt verstuurd naar de client.
De client codeerd met de String het wachtwoord (md5?) en stuurt het naar de server.
De server checkt de geldigheid, en indien het geldig is slaat hij de username en ip + recht op
De server genereerd dan weer een Random String (+- 250 chars) en stuurt deze naar de client
De client verdeeld deze string via een bepaald algoritme in 25 Strings. en stuurt met elke request een string mee. (1 vaste volgorde)
(of deze string als session identifier werkt, of als basis voor encodering weet ik nog niet, misschien dat deze string gecodeeerd word met het password oid.. sniffers mogen wel de inhoud zijn van de request. als ze maar geen functies uit kunnen voeren)
Na 25 request wordt er door de server weer een nieuwe verzonden..

De kans dat een hacker een identifier van de server haalt is nu verlaagd met 25X

[chem]

nog leuker: hou een logboek van de laatste 25 transacties bij. Indien er een 26e wordt uitgevoerd (en die mocht neit, want 1 daarvan is buiten de javaclient uitgevoerd) dan worden alle acties ge-ROLLBACK'ed.. ?

[Verwijderd]

wasigh: Op de server wordt een random string gegenereerd (+- 250 chars), deze string wordt verstuurd naar de client. De client codeert met de String het wachtwoord (md5?) en stuurt het naar de server.

Hoe gaat decode om te coderen naar de client? Applet neem ik aan? Dan is er wel achter te komen hoe jij je md5-jes maakt.
Vervolgens kan je een random string en de bijbehorende md5 string sniffen en brute force doet de rest.

De server checkt de geldigheid, en indien het geldig is slaat hij de username en ip + recht op.

Hoe voorkom je IP spoofing?

De server genereert dan weer een random string (+- 250 chars) en stuurt deze naar de client. De client verdeelt deze string via een bepaald algoritme in 25 Strings en stuurt met elke request een string mee. (1 vaste volgorde).

Zelfde problemen als hierboven: sniffen, kraken van applet etc.

De kans dat een hacker een identifier van de server haalt is nu verlaagd met 25X.

Zeker weten?

[wasigh]

Op dinsdag 16 oktober 2001 12:16 schreef Arien het volgende:

[..]

Hoe gaat decode om te coderen naar de client? Applet neem ik aan? Dan is er wel achter te komen hoe jij je md5-jes maakt.
Vervolgens kan je een random string en de bijbehorende md5 string sniffen en brute force doet de rest.
[..]

Hoe voorkom je IP spoofing?
[..]

Zelfde problemen als hierboven: sniffen, kraken van applet etc.
[..]

Zeker weten?

Server-side is php.
client-side is een losstaande Java-application geen applet.

Dat het niet onkraakbaar is weet ik,
Hoe ik ip-spoofing aan moet pakken weet ik niet..

De beveiliging is iig een stuk beter als een standaard session beveilig. Met een ID in een cookie etc...

Je moet veel meer moeite doen om binnen te komen..
Ik zou het graag perfect maken maar heb eigenlijk geen idee hoe..

[dusty]

Op dinsdag 16 oktober 2001 12:16 schreef Arien het volgende:
Hoe gaat decode om te coderen naar de client? Applet neem ik aan? Dan is er wel achter te komen hoe jij je md5-jes maakt.
Vervolgens kan je een random string en de bijbehorende md5 string sniffen en brute force doet de rest.

Dan heb je dus alleen de public key te pakken. Die dus elke 25e request compleet veranderd. Dus moet je wel ontzettend snel zijn met die brute force.

Hoe voorkom je IP spoofing?

Niet, maar in samenwerking tussen de session ID en de IP kan je na 3 keer "hacken" het IP weigeren.

Zelfde problemen als hierboven: sniffen, kraken van applet etc.

Dan heb je de methode voor de public kant. Niet voor aan de host kant. Ben je even ver als met een compleet PHP oplossing. Zie je ook alle code. Moet het inloggen nog steeds met brute force gehacked worden.

Zeker weten?

Ruw-weg 25 keer jah.

[ACM]

Probeer es wat documentatie over het kerberos5 "algoritme" te vinden.
En vergelijkbare authenticatie algoritmen/systemen.

En uiteraard naar het idee achter bijvoorbeeld RSA (daar weet iedereen het algoritme van, als ze willen en toch is het erg rottig te kraken )

[ACM]

Op dinsdag 16 oktober 2001 12:26 schreef wasigh het volgende:
Dat het niet onkraakbaar is weet ik,
Hoe ik ip-spoofing aan moet pakken weet ik niet..

Dit soort problemen worden geloof ik ook in Kerberos 4 en 5 afgevangen

Dik boek met de uitleg ligt thuis
Misschien dat ik het nog snap als ik het straks weer lees.

[Verwijderd]

dusty: Dan heb je dus alleen de public key te pakken. Die dus elke 25e request compleet veranderd. Dus moet je wel ontzettend snel zijn met die brute force.

Nee, als je weet hoe je met een random string die van de server komt een goede md5 string kan maken ben je altijd binnen.

Niet, maar in samenwerking tussen de session ID en de IP kan je na 3 keer "hacken" het IP weigeren.

En met "normale zo goed als nieuw in originele verpakking" sessies niet? (Welk voordeel heeft dit dus?)

Dan heb je de methode voor de public kant. Niet voor aan de host kant.

Server stuurt een string en client hakt die op in 25 string volgens vast partoon... Dus de client kant is waar het probleem zit en als je die kan kraken houdt de server kant je niet tegen met alleen maar random strings die hij je toestuurt.

Ruw-weg 25 keer jah.

Hmm...

[tomato]

Op dinsdag 16 oktober 2001 12:28 schreef ACM het volgende:
Probeer es wat documentatie over het kerberos5 "algoritme" te vinden.
En vergelijkbare authenticatie algoritmen/systemen.

Of natuurlijk een directe concurrent hiervan: MS Passport

[wasigh]

mmm hier begrijp ik niet veel van:
http://world.std.com/~franl/crypto/rsa-guts.html

(met rsa in 2 regels Perl!)

[ACM]

Op dinsdag 16 oktober 2001 12:45 schreef tomato het volgende:
Of natuurlijk een directe concurrent hiervan: MS Passport

Volgens mij valt dat onder "

Op dinsdag 16 oktober 2001 12:28 schreef ACM het volgende:
En vergelijkbare authenticatie algoritmen/systemen.

Alleen moet ik eerlijk zeggen dat kerberos me wat transparanter over komt

Op dinsdag 16 oktober 2001 12:47 schreef wasigh het volgende:
mmm hier begrijp ik niet veel van:
http://world.std.com/~franl/crypto/rsa-guts.html

(met rsa in 2 regels Perl!)

Tsja, dat boek van me heeft ook daar wel een goede uitleg over.

Ik zal je de titel wel es sturen, was iig een netwerk-boek van Tanenbaum

[Verwijderd]

Computer Networks - A.S. Tanenbaum.

Die?

[wasigh]

Op dinsdag 16 oktober 2001 12:47 schreef ACM het volgende:

[..]

Volgens mij valt dat onder "
[..]

Alleen moet ik eerlijk zeggen dat kerberos me wat transparanter over komt
[..]

Tsja, dat boek van me heeft ook daar wel een goede uitleg over.

Ik zal je de titel wel es sturen, was iig een netwerk-boek van Tanenbaum

Je bent niet op ICQ anders had ik je het al gevraagd..
(damn toch maar naar de universiteit dan )

[wasigh]

Arien,

ik waardeer het dat je kritisch meekijkt
maar heb je misschien ook tips om het te verbeteren
(anders dan het boek van acm?)

[ACM]

Op dinsdag 16 oktober 2001 12:51 schreef Arien het volgende:
Computer Networks - A.S. Tanenbaum.

Die?

Yupz, dat is hem.

Vond het een leuk-te-lezen en erg begrijpelijk boek

[Verwijderd]

wasigh: Heb je misschien ook tips om het te verbeteren (anders dan het boek van acm?)

Ik heb nog wel meer boeken voor je...

Kan je echt geen SSL draaien? (Dat bespaart een hoop denk werk. )

[dusty]

Op dinsdag 16 oktober 2001 12:38 schreef Arien het volgende:
Nee, als je weet hoe je met een random string die van de server komt een goede md5 string kan maken ben je altijd binnen.

Dan moet je nog steeds de username en login weten, immers heb je nu alleen de methode waarop je alle informatie moet encoden.

En met "normale zo goed als nieuw in originele verpakking" sessies niet? (Welk voordeel heeft dit dus?)

Met "deze" sessie variabelen kan je spelen (en springen) en meer onzin uithalen. En zit je niet aan dezelfde ID voor de gehele sessie vast.

Server stuurt een string en client hakt die op in 25 string volgens vast partoon... Dus de client kant is waar het probleem zit en als je die kan kraken houdt de server kant je niet tegen met alleen maar random strings die hij je toestuurt.

Nee, maar je hebt dan alleen de string waarmee je moet encoden. Nog niet de informatie zelf.

[wasigh]

Op dinsdag 16 oktober 2001 12:58 schreef Arien het volgende:

[..]

Ik heb nog wel meer boeken voor je...

Kan je echt geen SSL draaien? (Dat bespaart een hoop denk werk. )

Zijn die net zo duur?

mm ik ga dan maar achter SSL aan... Moet opzich wel te regelen zijn.

[dusty]

Op dinsdag 16 oktober 2001 13:02 schreef wasigh het volgende:
Zijn die net zo duur?

mm ik ga dan maar achter SSL aan... Moet opzich wel te regelen zijn.

Als SSL mogelijk is, altijd SSL gebruiken

[ACM]

Op dinsdag 16 oktober 2001 12:58 schreef Arien het volgende:
Kan je echt geen SSL draaien? (Dat bespaart een hoop denk werk. )

SSL zal je trouwens weinig beschermen tegen echte algoritme-kraking

Maar het wel een stuk moeilijker maken.
Je zou ook nog leuke trucjes met de ssl-sessionkey gecombineerd met je eigen sessions uit kunnen halen.

[wasigh]

Op dinsdag 16 oktober 2001 13:10 schreef ACM het volgende:

[..]

SSL zal je trouwens weinig beschermen tegen echte algoritme-kraking

Maar het wel een stuk moeilijker maken.
Je zou ook nog leuke trucjes met de ssl-sessionkey gecombineerd met je eigen sessions uit kunnen halen.

* wasigh staat altijd open voor leuke trucjes

[ACM]

Op dinsdag 16 oktober 2001 13:11 schreef wasigh het volgende:
* wasigh staat altijd open voor leuke trucjes

't Komt er gewoon op neer, dat SSL je niet beschermt tegen kraken "op de client zelf" (dus iemand die weet te authorizeren vanaf een andere pc zonder SSL verbinding, kan dat ook met SSL verbinding)

Wat overigens ook een leuke manier van beveiligen is, is het gebruiken van clientside SSL-certificaten, het is alleen een rotwerk om alles dan op te stellen

[Zoijar]

Overigens slaat de opmerking dat je session keys zou kunnen raden niet echt ergens op, het is namelijk iha makkelijker om het wachtwoord te raden Een eventuele verbetering is idd om session keys aan IP te koppelen, om helemaal zeker te zijn.

Die challenge authentication zonder SSL (server stuurt *random* string, client codeert wachtwoord+string met md5 en stuurt dat naar de server, die het zelfde doet en verglijkt; let erop dat je dus niet de string en het wachtwoord appart verstuurt) "is veilig" zolang de potentiele hacker alleen netwerk packets kan lezen, en dus niet *veranderen*. Als dat wel kan is het mogelijk de code aan te passen zodat het wachtwoord te achterhalen is.

Naar mijn idee is dit "veilig genoeg" om in te loggen. Simpel en effectief, hoe meer troep je er omheen bouwt, des te meer kans heb je op een loophole.

Let er weer op dat veilig altijd een relatief begrip is. Een grote multiprocessor kan namelijk md5 hashes kraken bv.
En een user kan ook z'n wachtwoord met een Post-It-je op z'n monitor plakken

[eamelink]

Inderdaad, als je een goede random sessionkey hebt, van zeg 40 tekens , dan heb je dus 36^40 mogelijkheden .

Dat is zooveeel : 1,21*10^59

Als je dat raadt, dan heb je er ook recht op om naar binnen te mogen vind ik

[mbravenboer]

Goh, dat zal wel goede content worden .

[chem]

Op dinsdag 16 oktober 2001 12:47 schreef wasigh het volgende:
mmm hier begrijp ik niet veel van:
http://world.std.com/~franl/crypto/rsa-guts.html

(met rsa in 2 regels Perl!)

quote uit de 1e regel:

Here's the relatively easy to understand math behind RSA public key encryption.

[The - DDD]

Op dinsdag 16 oktober 2001 10:34 schreef wasigh het volgende:
En als ik geen SSL tot mijn beschikking heb?

Kwestie van kijken op: http://java.sun.com/products/jsse/

Dit werkt met JDK1.1 en alle Java2 implementaties. Waar het omgaat is dat je 3 jar files beschikbaar moet maken voor je client: jcert.jar, jnet.jar, jsse.jar Dus beschikbaar maken door het bij de client te plaatsen in de classpath (dus lokaal) of op de webserver zetten en runtime laden in je applet.

Je kan geloof ik alleen geen gebruik maken van de URL classes. Maar je kan uiteraard wel handmatig je GET, POSTS en dergelijke doen.

JSSE ondersteund de volgende algoritmes:
RSA public key (authentication and key agreement) 2048 bits (authentication), 2048 bits (key agreement)
RC4 (bulk encryption) 128 bits
DES (bulk encryption) 64 bits (56 effective)
Triple DES (bulk encryption) 192 bits (112 effective)
Diffie-Hellman public key (key agreement) 1024 bits
DSA public key (authentication) 2048 bits

[mbravenboer]

De client-side is niet echt een probleem. Ik kan vanuit Java alles gebruiken wat je maar wilt (voor de omstanders: het is de bedoeling dat ik de client opzet). SSL kan uitstekend gebruikt worden, andere algoritmen zijn ook mogelijk.

Het gaat volgens mij ook niet echt een beveiliging van de data die verzonden wordt, maar een beveiliging, zodat alleen gerechtigde personen de content kunnen beheren. Uiteraard heeft dit ook wel veel met beveiliging van de data te maken .

Het genereren van een session id in combinatie met een ip zie ik echter niet als een probleem. Uiteraard kan die geraden worden, een key die gebruikt wordt voor encryptie kan echter ook worden geraden...

Ik denk dus dat er wel ff een goede afweging moet worden gemaakt tussen het nut van een perfecte beveiliging en de doelstellingen die bereikt zouden moeten worden .