[Web] Session Hijacking achter NAT

[eghie]

Gezien dit over serverside programmeren gaat, zet ik dit topic hier neer.

Ik ben bezig met beveiliging van een authenticatie systeem, wat via PHP werkt. Nu is dit een SSO systeem. Omdat dit een authenticatie systeem is, wil ik dit zo veilig mogelijk hebben. Nu is er 1 probleem waar ik wat moeite mee heb en dat is het voorkomen van session hijacking.

De meeste van jullie weten waarschijnlijk wel, dat een standaard PHP sessie makkelijk te hijacken is. Je grijpt een session cookie van iemand (eigenlijk alleen de session id) en je bent binnen. De bekende if ($_SESSION["loggedin"]) werkt zelf niet daartegen.

Nu heb je in PHP de functie, session_regenerate_id(true). Deze functie hergenereerd je sessie id. Dit verkleind enorm de tijd op waarop iemand je sessie kan hijacken. Dit komt omdat hij bij elke keer bij het laden een nieuwe sessie id krijgt, waardoor de oude ongeldig wordt. Nu is dat een redelijk goede beveiliging. Maar stel nu dat bij de laatste handeling die de gebruiker doet op de site, de cookie wordt gejat, dan krijgt de aanvaller alsnog een geldige id.

Nu kun je de sessie ook nog aan een IP koppelen. Ik neem meteen ook maar even mee dat je de sessie ook aan useragent, accept language, accept charset, etc zou koppelen. Dus dan heb je een identiteit te pakken die bijna zeker aan jouw browser is gekoppeld. Maar nu komt het probleem:

Stel je zit in een groot bedrijf. Dit bedrijf zit achter een NAT router. Bedrijf heeft allemaal gestandariseerde software. Dit betekend dat bij dit bedrijf, bij elke PC de volgende gegevens gelijk zijn: extern ip, useragent, accept language, accept charset, nog wat browser specifieke dingen.
Stel ze gebruiken geen proxy die X-forwarded-for meegeeft, dus aan intern IP kun je ze ook niet aan herkennen. Als conclusie uit dit laatste stukje kun je trekken, dat elke PC, binnen het bedrijfs netwerk, gelijk is voor de webserver. Ze hebben allemaal dezelfde identiteit. Dus de IP
koppeling en andere browser checks die gekoppeld zijn aan de sessie komen ze door.

Als ze nu in dit geval, de laatste cookie van de gebruiker jatten, vanuit het bedrijfsnetwerk, dan kunnen ze gewoon verder met de sessie. Dit omdat ze alle checks gewoon doorkomen.

Nu zou je ook nog met een idle timeout kunnen werken, waardoor de tijd, dat de cookie gejat kan worden, nog kleiner wordt. Maar het kan nog steeds.

Cookie encrypten helpt ook geen zak, want dat geeft alleen een andere representatie van de cookie, in plaats van dat het echt helpt.

Uiteraard is een zowat verplichte beveiliging, anti- Session Fixation (http://en.wikipedia.org/wiki/Session_fixation).

XSS (Cross Site Scripting) moet natuurlijk ook gewoon beveiligd worden, maar dit valt onder input validation. Die wil ik zowieso erg streng maken.

Nu zeg ik er even bij dat dit SSO systeem WEB only is, dus niet iets als kerberos ofzo, wat ook systemen in het netwerk identificeerd. Ga er ook maar even van uit dat we niet altijd controlle hebben over het netwerk.

Nu kun je met SSL client certificaten gaan werken. Dit neemt echter administratief veel werk met zich mee. Daarnaast heb ik, zoals ik al zei, weinig controlle over het netwerk waar de client op werkt. Ik mag dus ook niet altijd iets installeren daar.

Hoe kun je toch voorkomen, dat mensen binnen het netwerk (achter NAT), toch niet de sessie kunnen overnemen van de collega?

Het probleem wat er namelijk is, je hebt namelijk geen 100% zekere identiteit van de specifieke PC. Dit is ook wel logisch, vanwege privacy redenen. Anders kon Google wel heel makkelijk een profiel van je schetsen, wat ze nu overigens ook heel goed kunnen.

Hoe gaan jullie met dit probleem om?

Houd er wel even rekening mee dat het SSO is, dus ook niet bedoeld is om voor elke pagina opnieuw te authenticeren. Uiteraard gaan erg belangrijke pagina's, zoals wachtwoord wijziging, wel met de vraag om nog een keer je wachtwoord in te voeren.

[voodooless]

Kijk, als je al zover bent dat je een session ID kunt onderscheppen, dan kun je ook een login en wachtwoord onderscheppen, effectief maakt dat het hele session ID verhaal oninteressant. Waarom is https geen optie i.c.m de al genoemde technieken? Iedere browser heeft daar ondersteuning voor.

[eghie]

voodooless schreef op maandag 08 oktober 2007 @ 22:22:
Kijk, als je al zover bent dat je een session ID kunt onderscheppen, dan kun je ook een login en wachtwoord onderscheppen, effectief maakt dat het hele session ID verhaal oninteressant. Waarom is https geen optie i.c.m de al genoemde technieken? Iedere browser heeft daar ondersteuning voor.

De inlog procedure wordt zowieso via HTTPS geregeld. En ik zou ook wel alle verkeer over HTTPS kunnen dwingen. Maar cookies jatten kan ook via spyware/trojans/malware/etc. De inlog procedure wordt ook nog een met javascript goed beveiligd, oa met een hash over de lijn sturen icm anti replay attack beveiliging. Waardoor het wachtwoord eigenlijk niet te achterhalen valt, ondanks het misschien plain text te sniffen zou zijn.

[wboevink]

je kunt de client zijn computer ip opvragen, als de client dat niet blocked.
Vervolgens encrypt je zijn ip en geef je deze mee.
Daarna kun je altijd zijn ip met de gedecrypte ip vergelijken. Aangenomen dat 1 client tijdens een browser sessie altijd hetzelfde ip heeft.
Anders zou je de sessie op zijn pc ge-hashed met als salt zijn ip-nummer in een cookie kunnen opslaan en die steeds vergelijken. Maar dan gaat het idee van een cookieless session een beetje verloren :-)

[ Voor 14% gewijzigd door wboevink op 08-10-2007 22:47 ]

[wboevink]

eghie schreef op maandag 08 oktober 2007 @ 22:27:
oa met een hash over de lijn sturen icm anti replay attack beveiliging. Waardoor het wachtwoord eigenlijk niet te achterhalen valt, ondanks het misschien plain text te sniffen zou zijn.

Gehashde wachtwoorden zijn vrij eenvoudig en redelijk snel te hacken met een hashing dictionary.
En aangezien de hash functie in een javascript staat die voor iedereen te lezen is valt dat ook simpel te hacken.

[DarkFire]

Ik denk misschien heel dom maar waarom zou je uberhaupt je sessie id met een cookie naar de gebruiker sturen?

Op mijn website gebruik ik ook sessie's maar zonder cookies, en tot nu toe heeft dit altijd gewerkt.

[nu ik er over nadenk vraag ik me af hoe mijn website werkt als er 2 gebruikers met exact dezelfde informatie/ user agent/ NAT, etc inloggen... mmm]
iemand een idee of dit goed werkt zonder cookies te gebruiken?

[wboevink]

DarkFire schreef op maandag 08 oktober 2007 @ 22:42:
[nu ik er over nadenk vraag ik me af hoe mijn website werkt als er 2 gebruikers met exact dezelfde informatie/ user agent/ NAT, etc inloggen... mmm]
iemand een idee of dit goed werkt zonder cookies te gebruiken?

Dat zal niet uitmaken, omdat ze beiden een eigen http sessie hebben met je server krijgen ze ook beiden een unieke sessie id.

[Priet]

eghie schreef op maandag 08 oktober 2007 @ 22:27:De inlog procedure wordt zowieso via HTTPS geregeld. (...) De inlog procedure wordt ook nog een met javascript goed beveiligd, oa met een hash over de lijn sturen icm anti replay attack beveiliging. Waardoor het wachtwoord eigenlijk niet te achterhalen valt, ondanks het misschien plain text te sniffen zou zijn.

Even een domme vraag: waarom zou je met Javascript het wachtwoord gaan hashen (challenge-response system) als je de inloggegevens toch al niet kunt afluisteren omdat je die pagina via HTTPS serveert

[wboevink]

Priet schreef op maandag 08 oktober 2007 @ 22:46:
[...]

Even een domme vraag: waarom zou je met Javascript het wachtwoord gaan hashen (challenge-response system) als je de inloggegevens toch al niet kunt afluisteren omdat je die pagina via HTTPS serveert

Het is geen challenge-response want het wachtwoord (gehashed?) viel plain text te sniffen.
Euh, duh......plain text word door HTTPS ge-encrypt

[ Voor 6% gewijzigd door wboevink op 08-10-2007 22:50 ]

[voodooless]

wboevink schreef op maandag 08 oktober 2007 @ 22:36:
je kunt de client zijn computer ip opvragen, als de client dat niet blocked.

Dat is nu precies het probleem, vandaar ook de topic titel: "Session Hijacking achter NAT"

Als spyware of andere software je cookie achterhalen, waarom zouden ze dan ook niet via jou eigen PC, en jou eigen browser, zonder dat jij het weet gewoon hun shit doen, ook gewoon via HTTPS. Hoe wil je dat detecteren

[wboevink]

voodooless schreef op maandag 08 oktober 2007 @ 22:50:
[...]


Dat is nu precies het probleem, vandaar ook de topic titel: "Session Hijacking achter NAT"

Als spyware of andere software je cookie achterhalen, waarom zouden ze dan ook niet via jou eigen PC, en jou eigen browser, zonder dat jij het weet gewoon hun shit doen, ook gewoon via HTTPS. Hoe wil je dat detecteren

Inderdaad, in het geval van spyware is er weinig aan te doen, maar volgens mij is de discussie breder dan spyware....toch?

[voodooless]

De discussie gaat hoofdzakelijk over het detecteren van losse clients achter en NAT netwerk. Als je dat kan, dan kun je al een heleboel dingen tegengaan natuurlijk.

Er zijn verschillende technieken om dingen te detecteren, probleem is waarschijnlijk dat php daar niet zo makkelijk bij zal kunnen.

[ Voor 29% gewijzigd door voodooless op 08-10-2007 22:55 ]

[eghie]

wboevink schreef op maandag 08 oktober 2007 @ 22:36:
je kunt de client zijn computer ip opvragen, als de client dat niet blocked.
Vervolgens encrypt je zijn ip en geef je deze mee.
Daarna kun je altijd zijn ip met de gedecrypte ip vergelijken. Aangenomen dat 1 client tijdens een browser sessie altijd hetzelfde ip heeft.
Anders zou je de sessie op zijn pc ge-hashed met als salt zijn ip-nummer in een cookie kunnen opslaan en die steeds vergelijken. Maar dan gaat het idee van een cookieless session een beetje verloren :-)

Soortgelijks doe ik al, maar dan niet met cookie meesturen, maar gewoon in de sessie opslaan aan de server kant. Achter NAT werkt dat dus nog niet. En X-Forwarded-For is ook te faken.

wboevink schreef op maandag 08 oktober 2007 @ 22:42:
[...]


Gehashde wachtwoorden zijn vrij eenvoudig en redelijk snel te hacken met een hashing dictionary.
En aangezien de hash functie in een javascript staat die voor iedereen te lezen is valt dat ook simpel te hacken.

Iets met challenge-response. Dus samen met een key hashen terwijl je dat ook aan de server kant doet. De volgende keer een andere key gebruiken. Zelfs plaintext kom je er nog moeilijk achter.

wboevink schreef op maandag 08 oktober 2007 @ 22:45:
[...]


Dat zal niet uitmaken, omdat ze beiden een eigen http sessie hebben met je server krijgen ze ook beiden een unieke sessie id.

Maar hij is dan wel te jatten. Als is het cookieless. Het transport middel van je ID/key/whatever maakt niets uit.

Priet schreef op maandag 08 oktober 2007 @ 22:46:
[...]

Even een domme vraag: waarom zou je met Javascript het wachtwoord gaan hashen (challenge-response system) als je de inloggegevens toch al niet kunt afluisteren omdat je die pagina via HTTPS serveert

Omdat je altijd op verschillende niveau's moet beveiligen. Stel je hebt een applicatie en dat kan toch via HTTP worden ingelogd omdat de beheerder van de server is vergeten om SSL te forceren. Of misschien willen ze helemaal gaan SSL gaan gebruiken. Of misschien zijn in de toekomst de computers wel zo snel dat ze SSL on-the-fly kunnen kraken. Of is er via een proxy achtige manier/man-in-the-middle als nog de boel te sniffen. Door eigenlijk gewoon een SSL verbinding te maken met die man-in-the-middle machine. De meeste mensen letten toch niet op de SSL certificaat.

wboevink schreef op maandag 08 oktober 2007 @ 22:49:
[...]


Het is geen challenge-response want het wachtwoord (gehashed?) viel plain text te sniffen.
Euh, duh......plain text word door HTTPS ge-encrypt

HTTPS wordt bij inloggen geforceerd. Ik bedoel ermee te zeggen, dat zelfs zonder SSL een challenge response systeem met hashen van wachtwoord, moeilijk te kraken is.

Maar inlog systeem is nog verder te beveiligen met hardware/software tokens, die elke keer anders zijn. Net zoals ongeveer telebankieren. Dus ga er maar even van uit dat de inlog procedure veilig genoeg is.

voodooless schreef op maandag 08 oktober 2007 @ 22:53:
De discussie gaat hoofdzakelijk over het detecteren van losse clients achter en NAT netwerk. Als je dat kan, dan kun je al een heleboel dingen tegengaan natuurlijk.

Er zijn verschillende technieken om dingen te detecteren, probleem is waarschijnlijk dat php daar niet zo makkelijk bij zal kunnen.

Jep. Laat het overigens wel even duidelijk zijn, dat dit niet alleen PHP hoeft te zijn. ASP.NET, JSP of andere serverside taal mag ook natuurlijk. Het is altijd wel terug te vertalen naar PHP.

[ Voor 18% gewijzigd door eghie op 08-10-2007 23:12 ]

[Cartman!]

wboevink schreef op maandag 08 oktober 2007 @ 22:42:
[...]
Gehashde wachtwoorden zijn vrij eenvoudig en redelijk snel te hacken met een hashing dictionary.
En aangezien de hash functie in een javascript staat die voor iedereen te lezen is valt dat ook simpel te hacken.

Niet perse waar wat je zegt. Als jij mn user tabel te pakken weet te krijgen dan zit je met een hash van het wachtwoord+salt. Je kunt dan ieder geval geen rainbowtables meer gebruiken want de uitkomst heb je niets aan. Je zult dan alle mogelijkheden moeten genereren en dat kost wat tijd Zelf gebruik ik nu een tijdje SHA256 in PHP om te hashen en dat levert genoeg mogelijkheden op om echt te lang bezig te zijn om vol te houden. Overigens vind ik dat een login in een cookie dmv. een sessie id niet per definitie slecht is. GoT gebruikt dat bijv ook met het ReactID/TnetID en dat is naar mijn mening een prima methode.

edit: dit is nog wel een interessant stukje waar je denk ik wat aan hebt: http://en.wikipedia.org/wiki/Session_fixation

[ Voor 6% gewijzigd door Cartman! op 08-10-2007 23:34 ]

[voodooless]

Wat misschien ook nog wel interessant is om het geintje met het inloggen iedere keer weer opnieuw te doen als je informatie gaat wijzigen, zoals het submiten van forms. Nadeel is natuurlijk dat je steeds weer het wachtwoord zult moeten invullen

[eghie]

Cartman! schreef op maandag 08 oktober 2007 @ 23:31:
[...]
...knip...

edit: dit is nog wel een interessant stukje waar je denk ik wat aan hebt: http://en.wikipedia.org/wiki/Session_fixation

Zie startpost.

voodooless schreef op maandag 08 oktober 2007 @ 23:47:
Wat misschien ook nog wel interessant is om het geintje met het inloggen iedere keer weer opnieuw te doen als je informatie gaat wijzigen, zoals het submiten van forms. Nadeel is natuurlijk dat je steeds weer het wachtwoord zult moeten invullen

In startpost heb ik dat ook al genoemd, dat iig bij belangrijke wijzigingen oa aan profiel je opnieuw je wachtwoord moet invullen ja. Uiteraard weer via challenge-response systeem. Dus dat geeft al een redelijke bescherming aan de gegevens van de gebruiker.

[Cartman!]

Excuus eghie, niet goed gelezen blijkbaar...

Ik denk dat je je niet heel druk moet maken om sessies jatten achter een NAT. Iemand die dit kan kapen heeft dus toegang tot het netwerk achter het NAT kan net zo goed het wachtwoord vragen of keyloggen. Zou wel cool zijn als er iemand met een ontzettend goed idee komt naast HTTPS natuurlijk

[Janoz]

DarkFire schreef op maandag 08 oktober 2007 @ 22:42:
Ik denk misschien heel dom maar waarom zou je uberhaupt je sessie id met een cookie naar de gebruiker sturen?

Omdat de client moet vertellen wie hij is voordat de server de bijbehorende sessiegegevens bij die client kan zoeken. Verder stuur je die over het algemeen niet handmatig, maar gebeurt dat automatisch.

Op mijn website gebruik ik ook sessie's maar zonder cookies, en tot nu toe heeft dit altijd gewerkt.

Tenzijn je je sessieid ahcter al je url's plakt maak je toch echt gerbuik van een cookie. Installeer maar eens de web developers toolbar in firefox en zie welke cookies er bij je site ge-set worden.

[nu ik er over nadenk vraag ik me af hoe mijn website werkt als er 2 gebruikers met exact dezelfde informatie/ user agent/ NAT, etc inloggen... mmm]
iemand een idee of dit goed werkt zonder cookies te gebruiken?

Waarschijnlijk werkt het omdat er wel cookies gebruikt worden, maar omdat dit automatisch door de sessiehandler gebeurt was je hier nog niet helemaal van op de hoogte .

[eghie]

Cartman! schreef op dinsdag 09 oktober 2007 @ 08:26:
Excuus eghie, niet goed gelezen blijkbaar...

Ik denk dat je je niet heel druk moet maken om sessies jatten achter een NAT. Iemand die dit kan kapen heeft dus toegang tot het netwerk achter het NAT kan net zo goed het wachtwoord vragen of keyloggen. Zou wel cool zijn als er iemand met een ontzettend goed idee komt naast HTTPS natuurlijk

Maakt niet uit, het is en blijft een goede tip, waarvoor toch bedankt. Mjah, ik maak me ook niet heel druk, aangezien het niet zo vaak gaat voorkomen, maar ik wil het wel zoveel mogelijk beveiligen, dat dit eigenlijk niet mogelijk zou moeten zijn. Aangezien het een systeem is wat met meerdere applicaties gaat werken en waarvoor je maar 1 malig hoeft te authenticeren, wil ik niet dat het makkelijk hackbaar/hijackbaar is. Het moet eigenlijk zelfs veilig kunnen zijn, bij internet bankieren bijvoorbeeld. Niet dat dit systeem uberhaubt daarbij gebruikt gaat worden, maar ik wil het wel zo veilig hebben. Als je een collega hebt binnen je bedrijf waarmee je niet goed overweg kan en die is een beetje geintresseerd in beveiligingen en het kraken ervan. Je wilt niet dat hij je identiteit steelt. Tegen keyloggers en sniffers valt wel wat te doen. Antivirus, antikeylogger, key scramblers, beetje opletten en manier van inloggen aanpassen dmv muis een code in te klikken, die als een 2e wachtwoord dient of je software/hardware token inklikken. Dat kun je wel filmen, maar niet met een keylogger monitoren. Maar session hijacking kan op de achtergrond gebeuren. Misschien met sniffen, maar een web developers toolbar met cookie bekijken en even sessie id kopieeren werkt ook net zo goed. Als het een argeloze gebruiker is, die weet toch niet wat er gebeurd en wat hij allemaal met die sessie id kan.

[voodooless]

Ik heb misschien een ideetje... Je zegt dat je de login via HTTPS doet. Als je nu een frameset gebruikt, en die frameset gebruikt om een key op te slaan die je bij het inloggen meegeeft. Deze key zit dus niet in een cookie, en alleen de browser weet deze.

Nu kun je bij iedere nieuw request, het challenge response geintje weer uithalen. Dit kun je doen door na het laden met javascript een hash te maken van de challenge + key, en deze in een cookie te zetten, welke bij de volgende request weer mee wordt verzonden naar de webserver. Daar kun je dan checken of alles nog koek en ei is

En trouwens, al je de admin al niet kan vertrouwen dat ie zijn werk doet:

Stel je hebt een applicatie en dat kan toch via HTTP worden ingelogd omdat de beheerder van de server is vergeten om SSL te forceren

Waarom zou je dan de gebruikers wel vertrouwen:

Tegen keyloggers en sniffers valt wel wat te doen. Antivirus, antikeylogger, key scramblers, beetje opletten

[ Voor 25% gewijzigd door voodooless op 09-10-2007 10:15 ]

[eghie]

voodooless schreef op dinsdag 09 oktober 2007 @ 10:12:
Ik heb misschien een ideetje... Je zegt dat je de login via HTTPS doet. Als je nu een frameset gebruikt, en die frameset gebruikt om een key op te slaan die je bij het inloggen meegeeft. Deze key zit dus niet in een cookie, en alleen de browser weet deze.

Nu kun je bij iedere nieuw request, het challenge response geintje weer uithalen. Dit kun je doen door na het laden met javascript een hash te maken van de challenge + key, en deze in een cookie te zetten, welke bij de volgende request weer mee wordt verzonden naar de webserver. Daar kun je dan checken of alles nog koek en ei is

Hmm, klinkt goed. Ik zie het echter nog niet helemaal voor me met het frameset, maar ik ga dat eens even uitwerken. Bedankt in ieder geval, het klinkt wel leuk.

[Chesta]

Sessions zijn volgens mij altijd wel te bruteforcen. Om dit moeilijker te maken zou je de sessie kunnen beveiligen met een sessie-wachtwoord die je gewoon in een extra cookie opslaat.

[voodooless]

Ik vind het wel interessant allemaal aangezien wij ook met bepaalde gegevens zitten die strikt vertrouwelijk zijn, en toegankelijk via internet (ritadministratie, realtime locatie van objecten, dat soort shit). Wij gebruiken enkel en alleen HTTPS, maar eigenlijk verder niet echt actief andere maatregelen tegen het hijacken van verbindingen. Bovenstaande is helaas voor ons geen optie omdat we ook met applets en andere zooi zitten waardoor het nooit zou werken. HTTPS kan hopelijk afdoende bescherming bieden. Maar de challenge response heb ik vanmorgen ook maar effe gefixed voor het inloggen, ben nu even aan het kijken of ik de session kan fixen aan een IP (helaas geen NAT) en userAgent. Ik ga ook eens kijken of ik nog wat kan doen met ssl session ID's...

Maar toch: het forceren naar HTTPS lost eigenlijk een berg van je problemen op en maakt het leven een stuk makkelijker.

[ Voor 11% gewijzigd door voodooless op 09-10-2007 10:33 ]

[eghie]

Chesta schreef op dinsdag 09 oktober 2007 @ 10:21:
Sessions zijn volgens mij altijd wel te bruteforcen. Om dit moeilijker te maken zou je de sessie kunnen beveiligen met een sessie-wachtwoord die je gewoon in een extra cookie opslaat.

Hoe bedoel je dit? Als je sessies aan een IP koppeld. Dan kun je alleen sessies jatten die van hetzelfde IP zijn als de jouwe. Een sessie id is een lange string die uniek is. Deze heeft ontzettend veel mogelijkheden. Plus als je nog session id hergenereerd per oproep aan de pagina, hoe reeel is het dan dat je sessie wordt gebruteforced?

voodooless schreef op dinsdag 09 oktober 2007 @ 10:22:
Ik vind het wel interessant allemaal aangezien wij ook met bepaalde gegevens zitten die strikt vertrouwelijk zijn, en toegankelijk via internet (ritadministratie, realtime locatie van objecten, dat soort shit). Wij gebruiken enkel en alleen HTTPS, maar eigenlijk verder niet echt actief andere maatregelen tegen het hijacken van verbindingen. Bovenstaande is helaas voor ons geen optie omdat we ook met applets en andere zooi zitten waardoor het nooit zou werken. HTTPS kan hopelijk afdoende bescherming bieden. Maar de challenge response heb ik vanmorgen ook maar effe gefixed voor het inloggen, ben nu even aan het kijken of ik de session kan fixen aan een IP (helaas geen NAT) en userAgent. Ik ga ook eens kijken of ik nog wat kan doen met ssl session ID's...

Maar toch: het forceren naar HTTPS lost eigenlijk een berg van je problemen op en maakt het leven een stuk makkelijker.

Misschien is het wel handig als je dit artikel eens leest: http://www.ibm.com/developerworks/library/s-sniff.html Uiteraard zal het zowat niet gebeuren, maar bij beveiliging is het de risico's zoveel mogelijk beperken, terwijl het systeem toch bruikbaar blijft. Dus ik vertrouw niet helemaal op SSL. Het is alleen maar een encryptie laag en geen host verificatie (wel aan de server kant uiteraard), alhoewel SSL client certificaten daar wel weer goed mee werkt. Gezien een argeloze gebruiker toch niet oplet wat er bij die SSL meldingen staat, vind ik het wel handig om het systeem te beveiligen alsof SSL niet aanwezig is.

[ Voor 56% gewijzigd door eghie op 09-10-2007 11:01 ]

[voodooless]

Thanks voor de info. Rede zat om nog eens met het een en ander te spelen natuurlijk

[Woy]

eghie schreef op dinsdag 09 oktober 2007 @ 10:33:
[...]

Hoe bedoel je dit? Als je sessies aan een IP koppeld. Dan kun je alleen sessies jatten die van hetzelfde IP zijn als de jouwe. Een sessie id is een lange string die uniek is. Deze heeft ontzettend veel mogelijkheden. Plus als je nog session id hergenereerd per oproep aan de pagina, hoe reeel is het dan dat je sessie wordt gebruteforced?


[...]

Misschien is het wel handig als je dit artikel eens leest: http://www.ibm.com/developerworks/library/s-sniff.html Uiteraard zal het zowat niet gebeuren, maar bij beveiliging is het de risico's zoveel mogelijk beperken, terwijl het systeem toch bruikbaar blijft. Dus ik vertrouw niet helemaal op SSL. Het is alleen maar een encryptie laag en geen host verificatie (wel aan de server kant uiteraard), alhoewel SSL client certificaten daar wel weer goed mee werkt. Gezien een argeloze gebruiker toch niet oplet wat er bij die SSL meldingen staat, vind ik het wel handig om het systeem te beveiligen alsof SSL niet aanwezig is.

Tja servercertificaten zorgen er ieder geval voor dat het certificaat klopt met de hostname die in je browser staat. Tja als je gebruiker niet op de hostnaam let en allemaal spyware heeft dan is er weinig wat je nog kunt doen.

Dingen als spywaren enzo is toch moeilijk tegen te gaan. Als ik als spyware jouw loginsysteem zou willen kraken, dan maak ik gewoon een IE plugin die meteen uit de textboxen de username/wachtwoord uitleest.
Dan kun je nog zo veel daar tegen beveiligen maar als iemand al toegang tot de computer heeft valt er weinig meer tegen te doen.

[eghie]

rwb schreef op dinsdag 09 oktober 2007 @ 12:40:
[...]

Tja servercertificaten zorgen er ieder geval voor dat het certificaat klopt met de hostname die in je browser staat. Tja als je gebruiker niet op de hostnaam let en allemaal spyware heeft dan is er weinig wat je nog kunt doen.

Dingen als spywaren enzo is toch moeilijk tegen te gaan. Als ik als spyware jouw loginsysteem zou willen kraken, dan maak ik gewoon een IE plugin die meteen uit de textboxen de username/wachtwoord uitleest.
Dan kun je nog zo veel daar tegen beveiligen maar als iemand al toegang tot de computer heeft valt er weinig meer tegen te doen.

Stel dat ik je ze vrijwillig zou weggeven die gebruikersnaam en wachtwoord. Hoe wil je dan inloggen als er ook nog een software/hardware token in het spel is (net zoals de random reader van de rabobank)?

[Woy]

eghie schreef op dinsdag 09 oktober 2007 @ 15:14:
[...]

Stel dat ik je ze vrijwillig zou weggeven die gebruikersnaam en wachtwoord. Hoe wil je dan inloggen als er ook nog een software/hardware token in het spel is (net zoals de random reader van de rabobank)?

Tja als er toch al spyware op die computer draait is het natuurlijk niet zo moeilijk om die extra software/hardware token ook af te vangen.

Ik ben het met je eens dat je het zo goed mogenlijk moet beveiligen enzo, maar tegen iemand die toegang tot de client computer heeft zou ik geen goede beveiliging kunnen bedenken. Daarom zou ik me vooral focussen op hetgeen wat er over de lijn gaat.
Op het moment dat iemand de private key van je SSL certificaat heeft is je HTTPS ook niet meer veilig. En Certificate Revocation lists worden in IE en in Firefox nog niet gebruikt ( Ieder geval de laatste keer dat ik keek, Opera was hier de enige uitzondering op ). Hoe mooi het ook zou zijn, ik weet daar ook geen oplossing voor als je geen controle over je client systemen hebt.

[ Voor 5% gewijzigd door Woy op 09-10-2007 15:30 ]

[roy-t]

Edit: maakt tekst iets vriendelijker/leesbaarder

Waarom cryp je het wachtwoord uberhaupt met javascript, wat direct in de webpagina staat en wat iedereen kan lezen? Of zie ik dit verkeerd?

Kies liever voor een soort van serverside programmering (.Net?) al de code wordt dan uitgevoerd door de codebackend op de server, en de site geeft alleen maar variabelen heen en weer.(doe je al met PHP, maar volgens mij is dat net iets minder server side, en nogsteeds dat wachtwoord verhaal)

(anti-rant! )
Oh btw: JA het is MS software, en JA firefox, opera en alle andere webbrowser kunnen ook overweg met .Net, het werkt via postbacks, de server draait wel windows, maar de browser heeft geen idee dat er windows (C# vaak) codes op de achtergrond gedraait worden.

(Btw dit is met mijn beperkte kennis van Visual Web Developer.NET geschreven, en zonder verder onderbouwde kennis, en zo ver ik het verhaal snap, zo werkt het niet misschien precies, en misschien wordt veel Javascript code ook niet direct in de website gezet maar dat idee heb ik erbij, en als dat het geval is, en je wilt het echt veilig dan zou ik dit niet gebruiken)

(dus ja eigenlijk schreeuw ik wat en heb ik de klepel in mijn hand en ben ik de klok kwijt

[ Voor 25% gewijzigd door roy-t op 09-10-2007 18:12 ]

[Woy]

therat10430 schreef op dinsdag 09 oktober 2007 @ 18:06:
Edit: maakt tekst iets vriendelijker/leesbaarder

Waarom cryp je het wachtwoord uberhaupt met javascript, wat direct in de webpagina staat en wat iedereen kan lezen? Of zie ik dit verkeerd?

Kies liever voor een soort van serverside programmering (.Net?) al de code wordt dan uitgevoerd door de codebackend op de server, en de site geeft alleen maar variabelen heen en weer.(doe je al met PHP, maar volgens mij is dat net iets minder server side, en nogsteeds dat wachtwoord verhaal)

(anti-rant! )
Oh btw: JA het is MS software, en JA firefox, opera en alle andere webbrowser kunnen ook overweg met .Net, het werkt via postbacks, de server draait wel windows, maar de browser heeft geen idee dat er windows (C# vaak) codes op de achtergrond gedraait worden.

(Btw dit is met mijn beperkte kennis van Visual Web Developer.NET geschreven, en zonder verder onderbouwde kennis, en zo ver ik het verhaal snap, zo werkt het niet misschien precies, en misschien wordt veel Javascript code ook niet direct in de website gezet maar dat idee heb ik erbij, en als dat het geval is, en je wilt het echt veilig dan zou ik dit niet gebruiken)

(dus ja eigenlijk schreeuw ik wat en heb ik de klepel in mijn hand en ben ik de klok kwijt

Zoals je idd al aangeeft vertel je een klok/klepel verhaal.

Tuurlijk moet je ook serverside beveiligen, maar daarbij is het ook niet slecht om ook het wachtwoord wat naar de server gepost word te beveiligen. Zeker als je dit met bijvoorbeel een a-symetrische encrypty doet waarvan je alleen op de server een private key hebt, en daarbij ook nog rekening houdt met replay attacks ( een seed erbij optellen bijvoorbeeld ) is het zeker wel handig. Bovenop je HTTPS is het mischien wat overbodig omdat alles al ge-encrypt is.

Verder haalt het natuurlijk niet uit of je PHP of C#/ASP.NET gebruikt wat betreft veiligheid en dat is dan ook een hele andere discussie.

De technieken die hier besproken worden staan in princiepe los van de serverside taal die gebruikt wordt.

[eghie]

therat10430 schreef op dinsdag 09 oktober 2007 @ 18:06:
Edit: maakt tekst iets vriendelijker/leesbaarder

Waarom cryp je het wachtwoord uberhaupt met javascript, wat direct in de webpagina staat en wat iedereen kan lezen? Of zie ik dit verkeerd?

Kies liever voor een soort van serverside programmering (.Net?) al de code wordt dan uitgevoerd door de codebackend op de server, en de site geeft alleen maar variabelen heen en weer.(doe je al met PHP, maar volgens mij is dat net iets minder server side, en nogsteeds dat wachtwoord verhaal)

(anti-rant! )
Oh btw: JA het is MS software, en JA firefox, opera en alle andere webbrowser kunnen ook overweg met .Net, het werkt via postbacks, de server draait wel windows, maar de browser heeft geen idee dat er windows (C# vaak) codes op de achtergrond gedraait worden.

(Btw dit is met mijn beperkte kennis van Visual Web Developer.NET geschreven, en zonder verder onderbouwde kennis, en zo ver ik het verhaal snap, zo werkt het niet misschien precies, en misschien wordt veel Javascript code ook niet direct in de website gezet maar dat idee heb ik erbij, en als dat het geval is, en je wilt het echt veilig dan zou ik dit niet gebruiken)

(dus ja eigenlijk schreeuw ik wat en heb ik de klepel in mijn hand en ben ik de klok kwijt

Ik heb een jaar gewerkt als C# .NET programmeur. Heb ASP.NET gedaan maar ook Windows applicaties geprogrammeerd en Services geprogrammeerd. Nu maak ik gebruik van PHP, omdat ik Linux servers gebruik (vanwege beheers redenen en kosten plaatje, etc). Ook zijn de applicaties in PHP. Maakt niet uit, ben niet boos. Maar inderdaad, leg die klepel maar weer neer, dan zoek ik er de klok wel bij. Aangezien ik bedoel met wachtwoord encrypten (eigenlijk hashen) in Javascript als een soort van challenge response systeem. rwb noemde dat ook al. Hierdoor gaat nooit de originele wachtwoord over de lijn.

[roy-t]

eghie schreef op dinsdag 09 oktober 2007 @ 20:27:
[...]

Ik heb een jaar gewerkt als C# .NET programmeur. Heb ASP.NET gedaan maar ook Windows applicaties geprogrammeerd en Services geprogrammeerd. Nu maak ik gebruik van PHP, omdat ik Linux servers gebruik (vanwege beheers redenen en kosten plaatje, etc). Ook zijn de applicaties in PHP. Maakt niet uit, ben niet boos. Maar inderdaad, leg die klepel maar weer neer, dan zoek ik er de klok wel bij. Aangezien ik bedoel met wachtwoord encrypten (eigenlijk hashen) in Javascript als een soort van challenge response systeem. rwb noemde dat ook al. Hierdoor gaat nooit de originele wachtwoord over de lijn.

Excusez moi, ik dacht dat je met een in de html zelf gestopte javascript code het wachtwoord encrypte:

(pseudo code zoals ik dacht dat jij dacht)

HTML:

<body>
<scriptcode =javascript>
checkwachtwoord()
encryptwachtwoord met hash #$*@*%@*
verstuurwachtwoord
</script>
</body>

* roy-t legt de klepel voorzichtig neer

[eghie]

therat10430 schreef op dinsdag 09 oktober 2007 @ 21:13:
[...]


Excusez moi, ik dacht dat je met een in de html zelf gestopte javascript code het wachtwoord encrypte:

(pseudo code zoals ik dacht dat jij dacht)

HTML:

<body>
<scriptcode =javascript>
checkwachtwoord()
encryptwachtwoord met hash #$*@*%@*
verstuurwachtwoord
</script>
</body>

* eghie legt de klepel voorzichtig neer

Even in code uitgelegd:

HTML:

<html>
<head>
<title>blub</title>
<script type="text/javascript">
   function login()
   {
       var hashedpass = sha1(document.getElementById('password').value + document.getElementById('challenge').value);

       document.getElementById('password').value = hashedpass;

       document.form[0].submit();
   }
</script>
<body>
<form method="post">
<input type="text" name="username" />
<input type="password" name="password" id="password" />
<input type="hidden" name="challenge"  id="challenge" value="<?=$_SESSION["challenge"]; ?>" />
<input type="button" name="Login"  id="submit" onclick="login()" />
</form>
</body>
</html>

[ Voor 5% gewijzigd door eghie op 09-10-2007 21:25 ]

[Voutloos]

therat10430 schreef op dinsdag 09 oktober 2007 @ 21:13:
ik dacht dat je met een in de html zelf gestopte javascript code het wachtwoord encrypte

Er zijn prima veilige (en nuttige) protocollen te bedenken wel ongeveer zoals die pseudocode werken hoor. Dat het in de html staat is het probleem niet. Het RSA-algoritme of dat van menig ander encryptie danwel hash algoritme is ook gewoon bekend, geen probleem hoor. Encrypten met een public key is geen probleem, zolang je de private key maar, tja private houd. En ook hashen met een publiekelijk zichtbare salt kan nut hebben, het kost op zijn minst nog tijd om te bruteforcen cq de rainbow tabel aan te leggen. Van het wisselen van salt heeft de client weinig last (het hashen blijft even duur), maar ondertussen kan de aanvaller zijn rainbow tabel weggooien.

Dit allemaal algemeen bedoeld, over elk begrip is veel verder uit te wijden, maar het is niet altijd erg als een deel van algoritme enigszins zichtbaar is voor de client (en dus aanvaller).

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 98% gewijzigd door Ruudjah op 01-12-2009 22:10 ]

[Gomez12]

Met een java-applet kan je toch wel het echte ip-adres van de client achterhalen. Ook achter NAT.

Kan je dit niet onderdeel laten uitmaken van je challenge respons? Is iets wat echt uniek zou zijn per client ( binnen het NAT )

[eamelink]

Ruudjah schreef op dinsdag 09 oktober 2007 @ 21:41:
Werkt dit sowieso niet omdat het respons pakketje van het gespoofde IP naar het IP wordt gestuurd van de originele aanvrager? Zodat IP spoofen dus geen zin heeft, het respons pakketje komt nooit aan bij de hacker. Is dit een correcte denkwijze, of zie ik (en jullie dus ook) nog extern IP spoofen over het hoofd?

In principe wel ja. De response op een ip-gespoofde request komt niet bij de spoofer aan. IP-spoofing is dan ook nauwelijks een probleem. Alleen als de aanvaller de controle heeft over een stuk netwerk tussen host en client kan ip-spoofing succesvol toegepast worden. Dat is vrijwel nooit het geval.

Normale session-hijacking is ook meestal geen probleem. Zolang session-id's in cookies staan en niet in URL's is er weinig risico dat je session-ID's lekt. Geef je session cookie een http-only vlaggetje mee en je hebt weer een extra bescherming mocht je site toch vatbaar zijn voor XSS.

Session fixation is een potentieel veel groter probleem. Ga maar eens naar een standaard php installatie en zet PHPSESSID=12345 achter de URL. Je krijgt dan inderdaad gewoon een sesie met 12345 als id. Als je vervolgens dus een link stuurt naar een slachtoffer met PHPSESSID=12345 achter de url, dan zitten jullie vervolgens op dezelfde sessie. Wacht tot hij is ingelogd, druk op F5, en voila, jij bent ook ingelogd... Daar zul je zelf een beveiliging tegen moeten implementeren

[ Voor 18% gewijzigd door eamelink op 09-10-2007 23:03 ]

[voodooless]

Bovenstaande is met cookies natuurlijk niet veel moeilijker, die kun je met de juiste toolbars ook gewoon zelf aanmaken. Voor de noob is dat natuurlijk iets lastiger dan een url copy/pasten

[Voutloos]

Het zijn gewoon verschillende soorten aanvallen. Session fixation vereist slechts wat social networking om het slachtoffer zover te krijgen, sessies stelen is wat technischer (maar kan idd eenvoudig zijn) en kan plaatsvinden zonder dat het slachtoffer meewerkt.

[FragFrog]

voodooless schreef op woensdag 10 oktober 2007 @ 11:39:
Bovenstaande is met cookies natuurlijk niet veel moeilijker, die kun je met de juiste toolbars ook gewoon zelf aanmaken. Voor de noob is dat natuurlijk iets lastiger dan een url copy/pasten

Daarom genereer je dus sessies op je server en sta je geen usersessies toe als je slim bent

Combineer dat met session regeneration en een koppeling aan IP en je hoeft echt niet zo bang te zijn dat iemand je sessie overneemt. Bij een beetje actieve surfer heb je minder dan een paar minuten voor de sessie die je gekaapt hebt niet meer geldig is, dus tenzij je direct bij je collega's filesystem kan heb je geen schijn van kans. En ja, dit legt de verantwoordelijkheid ook deels bij de systeembeheerder van je clients, maar is dat zo'n rare eis? Als die zijn zaken niet goed op orde heeft kan ik simpeler een keylogger installeren middels een USB key en windows' autoplay (kwestie van even eraan hangen en klaar) dan dat ik geheime netwerkshares / filesharing software op mijn collega's PC kan krijgen.

Blijft over MitM attacks, en zoals gezegd, met HTTPS kom je dan al een behoorlijk eind.

Ik krijg een beetje het idee alsof men een kasteel probeert te bouwen met fortificaties, slotgracht, vuurspuwende draken op't dak () etcetera maar vergeet dat er ook een achterdeur is Je grootste gevaar ligt bijna altijd bij 'domme' users die op duizend malifide sites hetzelfde wachtwoord gebruiken, post-IT's aan hun monitor hangen, ingelogde computers onbewaakt achterlaten, etc etc.

[Confusion]

eghie schreef op maandag 08 oktober 2007 @ 22:16:
Hoe kun je toch voorkomen, dat mensen binnen het netwerk (achter NAT), toch niet de sessie kunnen overnemen van de collega?

Niet, tenzij je kan zorgen dat alle computers op alle locaties goed beveiligd zijn, niemand zijn wachtwoord verliest en zijn workstation altijd locked als hij er fysiek bij weggaat.

Uiteraard gaan erg belangrijke pagina's, zoals wachtwoord wijziging, wel met de vraag om nog een keer je wachtwoord in te voeren.

Dat, en bijvoorbeeld een nieuw sessieID uitdelen zodra je op HTTPS bent overgegaan.

wboevink schreef op maandag 08 oktober 2007 @ 22:42:
Gehashde wachtwoorden zijn vrij eenvoudig en redelijk snel te hacken met een hashing dictionary.

Als je alleen fatsoenlijke wachtwoorden toestaat, dan kan daar geen rainbow table tegenop.

eghie schreef op maandag 08 oktober 2007 @ 23:02:
Omdat je altijd op verschillende niveau's moet beveiligen. Stel je hebt een applicatie en dat kan toch via HTTP worden ingelogd omdat de beheerder van de server is vergeten om SSL te forceren.

En stel dat morgen de maan omlaag stort, dan zijn we allemaal dood. Als iemand echt ongeoorloofde toegang tot de applicatie wil, dan krijgt hij dat wel. Client side certificates kan je ook stelen. Desnoods steel je de hele computer en spoof je het IP. Zonder procedure waarmee dat certificaat onmiddellijk ingetrokken wordt, voorkom je dat niet. En dat soort procedures gaan falen, tenzij je in een zwaar-beveiligde omgeving zit, waar alle gebruikers er mee om kunnen gaan. Maar als dat het geval is, dan kan je dat certificaat ook als basis voor een VPN verbinding gebruiken.

Iemand heeft een sessie en zal zichzelf moeten identificeren, wil de juiste sessie aan het request gekoppeld worden. Als je de identificatie-data over HTTP verstuurd, dan is het te sniffen. Als je de identificatie-data over HTTPS verstuurd, dan is het niet te sniffen, maar blijft een man-in-the-middle attack mogelijk. Dat is gewoon het einde van het verhaal: als je iets anders wilt, dan is HTTP niet het geschikte protocol om deze data te verschepen.

Als het belangrijk genoeg is, dan moet je alle activiteiten loggen zodat je achteraf in ieder geval kan traceren wat er gebeurd is en melding laten maken van verdachte of zeldzame activiteiten.

De vraag is: van wie wil je voorkomen dat ze ongeoorloofde toegang verwerven? Security for securities sake is zinloos. Heb je echt betere beveiliging dan pakweg Amazon.com nodig?

[voodooless]

Confusion schreef op donderdag 11 oktober 2007 @ 11:09:
Als je alleen fatsoenlijke wachtwoorden toestaat, dan kan daar geen rainbow table tegenop.

Met een challenge erbij wordt het sowiso al niet meer te doen met tabelletjes

Misschien heeft iemand anders nog een idee wat betreft dit: Wat te doen met login ID, dus cookies die de gebruiker over meerdere sessies identificeren, los van het sessionID. Als je het login ID hebt, kun je gewoon buiten de sessie om inloggen. En sessies dagen lang maken lijkt me geen goed plan eigenlijk, dus al een user ingelogd wil blijven over meerdere sessies, zonder steeds opnieuw username en wachtwoord te hoeven geven, hoe doe je dat veilig?

[Confusion]

voodooless schreef op donderdag 11 oktober 2007 @ 11:25:
Misschien heeft iemand anders nog een idee wat betreft dit: Wat te doen met login ID, dus cookies die de gebruiker over meerdere sessies identificeren, los van het sessionID. Als je het login ID hebt, kun je gewoon buiten de sessie om inloggen. En sessies dagen lang maken lijkt me geen goed plan eigenlijk, dus al een user ingelogd wil blijven over meerdere sessies, zonder steeds opnieuw username en wachtwoord te hoeven geven, hoe doe je dat veilig?

Als je een user een cookie geeft met een gegeven waarmee hij in kan loggen, dan is dat effectief een sessieID, of het nu in de praktijk een bestaande sessie voortzet of een nieuwe sessie start.

Ik denk dat T.net het zo veilig doet als mogelijk is. Als iemand je cookie steelt, dan heb je een probleem (zoals we in het verleden al eens gezien hebben) (waarbij je reactID aan IP binden een klein beetje extra veiligheid geeft, maar ook niet echt veel). De oplossing is dan: logging, waardoor je in ieder geval kan zien wat er gedaan is.

[voodooless]

Precies, effectief is dat gewoon een session ID, en dat is natuurlijk tricky. Nu fixen we dit wel op IP, maar hier zit je ook weer vast aan je NAT beperking.

misschien een idee: met het echte inloggen sturen we een berg info mee van de browser, zo uniek mogelijk, en die slaan we netjes op met het sessionID. Met het inloggen van het sessionID gebruiken we weer een challenge, waarmee we in combo met het browserinfo een hash maken, met welke we kunnen inloggen.

Probleem is alleen om die info zo uniek mogelijk te krijgen, en dat deze info natuurlijk eenvoudig te faken is. Je kunt dit soort dingen eigenlijk alleen maar doen door de user nogmaals om zijn wachtwoord te vragen, helaas is dat nu net iets wat je juist niet wil

't is echter altijd beter dan alleen een loginID.

[ Voor 3% gewijzigd door voodooless op 11-10-2007 11:51 ]

[Confusion]

voodooless schreef op donderdag 11 oktober 2007 @ 11:48:
't is echter altijd beter dan alleen een loginID.

Dat is maar de vraag: het maakt de code ingewikkelder, waardoor daar makkelijker fouten insluipen. Toch denk ik dat het wel behoorlijk effectief is: mensen die sessieID te pakken krijgen, pakken (denk ik) meestal niet ook je browser properties. Dat je al die properties doorstuurt maakt niet direct duidelijk dat ze voor authenticatie gebruikt worden en de meeste sites doen dat ook niet. Gaan ze echter vermoeden dat het daar in moet schuilen (en die deductie is nou ook weer niet al te lastig), dan kunnen ze gemakkelijk default properties van browsers repliceren. Het aantal keren dat iemand het cookie met ongeldige browserproperties mag aanbieden zou ik dan ook limiteren.

[voodooless]

De truck is natuurlijk ook dat je niet al te voor de hand liggende proporties gebruikt. Je zou zelfs naar plugins kunnen scannen bijvoorbeeld, of screen reso, en dat soort zaken. risoco is natuurlijk dat de gebruiker opnieuw moet inloggen als er wijzigingen zijn, maar goed, dat is dan jammer

[eghie]

Gomez12 schreef op dinsdag 09 oktober 2007 @ 22:46:
Met een java-applet kan je toch wel het echte ip-adres van de client achterhalen. Ook achter NAT.

Kan je dit niet onderdeel laten uitmaken van je challenge respons? Is iets wat echt uniek zou zijn per client ( binnen het NAT )

Mjah, dit wordt weer teveel een geklier. Ten 1e is dat veel werk. Ten 2e geeft dat ook weer beveiligings risico's. Geheugen verbruik en laad tijd enzo van de applet zijn nou ook niet bepaald laag. Je hebt een website binnen een seconde binnen en je kunt verder, maar een java applet moet ook nog geladen worden en dan met slome pc's enzo is dat niet echt prettig. En die output is natuurlijk ook weer te faken.

FragFrog schreef op woensdag 10 oktober 2007 @ 22:29:
...

Ik krijg een beetje het idee alsof men een kasteel probeert te bouwen met fortificaties, slotgracht, vuurspuwende draken op't dak () etcetera maar vergeet dat er ook een achterdeur is Je grootste gevaar ligt bijna altijd bij 'domme' users die op duizend malifide sites hetzelfde wachtwoord gebruiken, post-IT's aan hun monitor hangen, ingelogde computers onbewaakt achterlaten, etc etc.

Voor dat gebeuren hebben we die software token. Zodat ze iemand anders die het wachtwoord kent, niet kan inloggen omdat hij niet over het token beschikt.

Confusion schreef op donderdag 11 oktober 2007 @ 11:09:
...

En stel dat morgen de maan omlaag stort, dan zijn we allemaal dood. Als iemand echt ongeoorloofde toegang tot de applicatie wil, dan krijgt hij dat wel. Client side certificates kan je ook stelen. Desnoods steel je de hele computer en spoof je het IP. Zonder procedure waarmee dat certificaat onmiddellijk ingetrokken wordt, voorkom je dat niet. En dat soort procedures gaan falen, tenzij je in een zwaar-beveiligde omgeving zit, waar alle gebruikers er mee om kunnen gaan. Maar als dat het geval is, dan kan je dat certificaat ook als basis voor een VPN verbinding gebruiken.

Iemand heeft een sessie en zal zichzelf moeten identificeren, wil de juiste sessie aan het request gekoppeld worden. Als je de identificatie-data over HTTP verstuurd, dan is het te sniffen. Als je de identificatie-data over HTTPS verstuurd, dan is het niet te sniffen, maar blijft een man-in-the-middle attack mogelijk. Dat is gewoon het einde van het verhaal: als je iets anders wilt, dan is HTTP niet het geschikte protocol om deze data te verschepen.

Als het belangrijk genoeg is, dan moet je alle activiteiten loggen zodat je achteraf in ieder geval kan traceren wat er gebeurd is en melding laten maken van verdachte of zeldzame activiteiten.

De vraag is: van wie wil je voorkomen dat ze ongeoorloofde toegang verwerven? Security for securities sake is zinloos. Heb je echt betere beveiliging dan pakweg Amazon.com nodig?

Omdat het een authenticatie systeem opzich is, wil ik het zoveel mogelijk beveiligd hebben, maar dat de gebruiker er toch nog goed mee kan werken. Security for securities is inderdaad zinloos, maar beveiliging tegen session hijacking achter NAT vind ik zelf niet echt zinloos. Ik merk wel dat het verotte moeilijk is, zo niet onmogelijk om dat op een acceptabele manier te doen, dus ik zal me er maar bij moeten neerleggen.

Ook wil ik jullie met dit topic bewust maken (als secundair doel), dat dit ook met telebankieren kan. Uiteraard heb je een hardware token en bij het overmaken enzo moet je dat nog een keer invoeren en daarom maakt het niet echt uit bij telebankieren, maar het is wel mogelijk.

voodooless schreef op donderdag 11 oktober 2007 @ 13:15:
De truck is natuurlijk ook dat je niet al te voor de hand liggende proporties gebruikt. Je zou zelfs naar plugins kunnen scannen bijvoorbeeld, of screen reso, en dat soort zaken. risoco is natuurlijk dat de gebruiker opnieuw moet inloggen als er wijzigingen zijn, maar goed, dat is dan jammer

Ik denk dat sha1(user agent + accept languages + HTTP_ACCEPT + accept charset + REMOTE_ADDR + X_FORWARDED_FOR) wel genoeg is voor de identiteit. Iets met, jammer dan, dan het risico maar lopen en dat via logging, account blokkade na aantal "hijack pogingen" proberen op te vangen.

[Muthas]

eghie schreef op donderdag 11 oktober 2007 @ 14:55:
Ik denk dat sha1(user agent + accept languages + HTTP_ACCEPT + accept charset + REMOTE_ADDR + X_FORWARDED_FOR) wel genoeg is voor de identiteit. Iets met, jammer dan, dan het risico maar lopen en dat via logging, account blokkade na aantal "hijack pogingen" proberen op te vangen.

Het gaat erom dat als de NAT op een netwerk de X_FORWARED_FOR blokkeerd en stel er staan allemaal dezelfde computers er absoluut geen verschil in identificatie van de gebruikers vanaf dat netwerk is en dus simpel de cookie jatten genoeg zou moeten zijn.

[eghie]

Muthas schreef op donderdag 11 oktober 2007 @ 15:08:
[...]


Het gaat erom dat als de NAT op een netwerk de X_FORWARED_FOR blokkeerd en stel er staan allemaal dezelfde computers er absoluut geen verschil in identificatie van de gebruikers vanaf dat netwerk is en dus simpel de cookie jatten genoeg zou moeten zijn.

Dat klopt en dat realiseer ik me ook donders goed, vandaar ook dit topic. Die X_FORWARDED_FOR enzo is ook te faken, dus als hij doorkomt dan nog is hij te faken, maar als hij aanwezig is, dan is het mooi meegenomen. Uiteraard die andere beveiligingen die ik in dit topic heb genoemd, die blijven er wel gewoon in zitten. Dus het is niet zo dat ik er alleen op vertrouw.

[voodooless]

Ik dacht zelf meer aan iets als dit als identifier:

Mozilla;Netscape;5.0 (Windows; en-US);true;Win32;Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7;Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7;true;1280x1024@32bits;localhost/127.0.0.1;Java(TM) Platform SE 6 U2,npoji610.dll:application/x-java-vm,Java, ,false;Java(TM) Platform SE 6 U2,npjava13.dll:application/x-java-applet;version=1.3.1,Java Applet,,falseapplication/x-java-bean;version=1.3.1,JavaBeans,,falseapplication/x-java-applet;version=1.4,Java Applet,,falseapplication/x-java-bean;version=1.4,JavaBeans,,falseapplication/x-java-applet;version=1.4.1,Java Applet,,falseapplication/x-java-bean;version=1.4.1,JavaBeans,,false;Shockwave Flash,NPSWF32.dll:application/x-shockwave-flash,Adobe Flash movie,swf,falseapplication/futuresplash,FutureSplash movie,spl,false;QuickTime Plug-in 7.2,npqtplugin.dll:application/sdp,SDP stream descriptor,sdp,falseapplication/x-sdp,SDP stream descriptor,sdp,falseapplication/x-rtsp,RTSP stream descriptor,rtsp,rts,falsevideo/quicktime,QuickTime Movie,mov,qt,mqv,falsevideo/flc,AutoDesk Animator (FLC),flc,fli,cel,falseaudio/x-wav,WAVE audio,wav,bwf,falseaudio/wav,WAVE audio,wav,bwf,false;QuickTime Plug-in 7.2,npqtplugin7.dll:image/tiff,TIFF image,tif,tiff,falseimage/x-tiff,TIFF image,tif,tiff,falseimage/jp2,JPEG2000 image,jp2,falseimage/jpeg2000,JPEG2000 image,jp2,falseimage/jpeg2000-image,JPEG2000 image,jp2,falseimage/x-jpeg2000-image,JPEG2000 image,jp2,false;QuickTime Plug-in 7.2,npqtplugin6.dll:video/x-m4v,Video (protected),m4v,falseimage/x-macpaint,MacPaint image,pntg,pnt,mac,falseimage/pict,PICT image,pict,pic,pct,falseimage/x-pict,PICT image,pict,pic,pct,falseimage/png,PNG image,png,falseimage/x-png,PNG image,png,falseimage/x-quicktime,QuickTime image,qtif,qti,falseimage/x-sgi,SGI image,sgi,rgb,falseimage/x-targa,TGA image,targa,tga,false;QuickTime Plug-in 7.2,npqtplugin5.dll:audio/3gpp,3GPP media,3gp,3gpp,falsevideo/3gpp2,3GPP2 media,3g2,3gp2,falseaudio/3gpp2,3GPP2 media,3g2,3gp2,falsevideo/sd-video,SD video,sdv,falseapplication/x-mpeg,AMC media,amc,falsevideo/mp4,MPEG-4 media,mp4,falseaudio/mp4,MPEG-4 media,mp4,falseaudio/x-m4a,AAC audio,m4a,falseaudio/x-m4p,AAC audio (protected),m4p,falseaudio/x-m4b,AAC audio book,m4b,false;QuickTime Plug-in 7.2,npqtplugin4.dll:video/mpeg,MPEG media,mpeg,mpg,m1s,m1v,m1a,m75,m15,mp2,mpm,mpv,mpa,falseaudio/mpeg,MPEG audio,mpeg,mpg,m1s,m1a,mp2,mpm,mpa,m2a,falseaudio/x-mpeg,MPEG audio,mpeg,mpg,m1s,m1a,mp2,mpm,mpa,m2a,falsevideo/3gpp,3GPP media,3gp,3gpp,false;QuickTime Plug-in 7.2,npqtplugin3.dll:audio/x-gsm,GSM audio,gsm,falseaudio/AMR,AMR audio,AMR,falseaudio/aac,AAC audio,aac,adts,falseaudio/x-aac,AAC audio,aac,adts,falseaudio/x-caf,CAF audio,caf,falsevideo/x-mpeg,MPEG media,mpeg,mpg,m1s,m1v,m1a,m75,m15,mp2,mpm,mpv,mpa,false;QuickTime Plug-in 7.2,npqtplugin2.dll:audio/aiff,AIFF audio,aiff,aif,aifc,cdda,falseaudio/x-aiff,AIFF audio,aiff,aif,aifc,cdda,falseaudio/basic,uLaw/AU audio,au,snd,ulw,falseaudio/mid,MIDI,mid,midi,smf,kar,falseaudio/x-midi,MIDI,mid,midi,smf,kar,falseaudio/midi,MIDI,mid,midi,smf,kar,falseaudio/vnd.qcelp,QUALCOMM PureVoice audio,qcp,false;Mozilla Default Plug-in,npnul32.dll:*,Mozilla Default Plug-in,*,false;Adobe Acrobat,nppdf32.dll:application/pdf,Acrobat Portable Document Format,pdf,falseapplication/vnd.adobe.x-mars,Acrobat Portable XML Document Format,mars,falseapplication/vnd.fdf,Acrobat Forms Data Format,fdf,falseapplication/vnd.adobe.xfdf,XML Version of Acrobat Forms Data Format,xfdf,falseapplication/vnd.adobe.xdp+xml, Acrobat XML Data Package,xdp,falseapplication/vnd.adobe.xfd+xml,Adobe FormFlow99 Data File,xfd,false;WindizUpdate Plug-in,npupd62.dll:application/x-windizupdate,WindizUpdate data,u62,false;<a href="http://www.cult3d.com">Cult3D Player</a> v5.3.0.154,NPMCult3DP.dll:application/x-cult3d-object,Cult3D,co,false;Microsoft Office 2003,NPOFFICE.DLL:application/x-msoffice,11.0.5510,*,false;iTunes Application Detector,npitunes.dll:application/itunes-plugin,This plug-in detects the presence of iTunes when opening iTunes Store URLs in a web page with Firefox.,,false;Java(TM) Platform SE 6 U2,npjava14.dll:application/x-java-applet;version=1.4.2,Java Applet,,falseapplication/x-java-bean;version=1.4.2,JavaBeans,,falseapplication/x-java-applet;version=1.5,Java Applet,,falseapplication/x-java-bean;version=1.5,JavaBeans,,falseapplication/x-java-applet;version=1.6,,,falseapplication/x-java-bean;version=1.6,,,false;Java(TM) Platform SE 6 U2,npjava32.dll:application/x-java-applet;version=1.3,Java Applet,,falseapplication/x-java-bean;version=1.3,JavaBeans,,falseapplication/x-java-applet;version=1.2.2,Java Applet,,falseapplication/x-java-bean;version=1.2.2,JavaBeans,,falseapplication/x-java-applet;version=1.2.1,Java Applet,,falseapplication/x-java-bean;version=1.2.1,JavaBeans,,false;Java(TM) Platform SE 6 U2,npjava11.dll:application/x-java-applet;version=1.1.1,Java Applet,,falseapplication/x-java-bean;version=1.1.1,JavaBeans,,falseapplication/x-java-applet;version=1.1,Java Applet,,falseapplication/x-java-bean;version=1.1,JavaBeans,,falseapplication/x-java-applet,Java Applet,,falseapplication/x-java-bean,JavaBeans,,false;Java(TM) Platform SE 6 U2,npjava12.dll:application/x-java-applet;version=1.2,Java Applet,,falseapplication/x-java-bean;version=1.2,JavaBeans,,falseapplication/x-java-applet;version=1.1.3,Java Applet,,falseapplication/x-java-bean;version=1.1.3,JavaBeans,,falseapplication/x-java-applet;version=1.1.2,Java Applet,,falseapplication/x-java-bean;version=1.1.2,JavaBeans,,false;Java(TM) Platform SE 6 U2,npjpi160_02.dll:application/x-java-applet;jpi-version=1.6.0_02,Java Applet,,falseapplication/x-java-bean;jpi-version=1.6.0_02,JavaBeans,,false;Windows Media Player Plug-in Dynamic Link Library,npdsplay.dll:application/asx,Media Files,*,falsevideo/x-ms-asf-plugin,Media Files,*,falseapplication/x-mplayer2,Media Files,*,falsevideo/x-ms-asf,Media Files,asf,asx,*,falsevideo/x-ms-wm,Media Files,wm,*,falseaudio/x-ms-wma,Media Files,wma,*,falseaudio/x-ms-wax,Media Files,wax,*,falsevideo/x-ms-wmv,Media Files,wmv,*,falsevideo/x-ms-wvx,Media Files,wvx,*,false;Microsoft® DRM,npdrmv2.dll:application/x-drm-v2,Network Interface Plugin,nip,false;Microsoft® DRM,npwmsdrm.dll:application/x-drm,Network Interface Plugin,nip,false

Dan een sha256 eroverheen als hash, en dat geef ik bij het inloggen aan de webserver. Als ik dan met mijn logincookie aan het inloggen ga, vraag ik al deze info weer op, maar dan met een challenge erbij. Je moet eigenlijk wel de initieel info (bij het inloggen) encrypted overzenden, misschien met TEA of AES.

[eghie]

voodooless schreef op donderdag 11 oktober 2007 @ 15:23:
Ik dacht zelf meer aan iets als dit als identifier:

Mozilla;Netscape;5.0 (Windows; en-US);true;Win32;Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7;Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7;true;1280x1024@32bits;localhost/127.0.0.1;Java(TM) Platform SE 6 U2,npoji610.dll:application/x-java-vm,Java, ,false;Java(TM) Platform SE 6 U2,npjava13.dll:application/x-java-applet;version=1.3.1,Java Applet,,falseapplication/x-java-bean;version=1.3.1,JavaBeans,,falseapplication/x-java-applet;version=1.4,Java Applet,,falseapplication/x-java-bean;version=1.4,JavaBeans,,falseapplication/x-java-applet;version=1.4.1,Java Applet,,falseapplication/x-java-bean;version=1.4.1,JavaBeans,,false;Shockwave Flash,NPSWF32.dll:application/x-shockwave-flash,Adobe Flash movie,swf,falseapplication/futuresplash,FutureSplash movie,spl,false;QuickTime Plug-in 7.2,npqtplugin.dll:application/sdp,SDP stream descriptor,sdp,falseapplication/x-sdp,SDP stream descriptor,sdp,falseapplication/x-rtsp,RTSP stream descriptor,rtsp,rts,falsevideo/quicktime,QuickTime Movie,mov,qt,mqv,falsevideo/flc,AutoDesk Animator (FLC),flc,fli,cel,falseaudio/x-wav,WAVE audio,wav,bwf,falseaudio/wav,WAVE audio,wav,bwf,false;QuickTime Plug-in 7.2,npqtplugin7.dll:image/tiff,TIFF image,tif,tiff,falseimage/x-tiff,TIFF image,tif,tiff,falseimage/jp2,JPEG2000 image,jp2,falseimage/jpeg2000,JPEG2000 image,jp2,falseimage/jpeg2000-image,JPEG2000 image,jp2,falseimage/x-jpeg2000-image,JPEG2000 image,jp2,false;QuickTime Plug-in 7.2,npqtplugin6.dll:video/x-m4v,Video (protected),m4v,falseimage/x-macpaint,MacPaint image,pntg,pnt,mac,falseimage/pict,PICT image,pict,pic,pct,falseimage/x-pict,PICT image,pict,pic,pct,falseimage/png,PNG image,png,falseimage/x-png,PNG image,png,falseimage/x-quicktime,QuickTime image,qtif,qti,falseimage/x-sgi,SGI image,sgi,rgb,falseimage/x-targa,TGA image,targa,tga,false;QuickTime Plug-in 7.2,npqtplugin5.dll:audio/3gpp,3GPP media,3gp,3gpp,falsevideo/3gpp2,3GPP2 media,3g2,3gp2,falseaudio/3gpp2,3GPP2 media,3g2,3gp2,falsevideo/sd-video,SD video,sdv,falseapplication/x-mpeg,AMC media,amc,falsevideo/mp4,MPEG-4 media,mp4,falseaudio/mp4,MPEG-4 media,mp4,falseaudio/x-m4a,AAC audio,m4a,falseaudio/x-m4p,AAC audio (protected),m4p,falseaudio/x-m4b,AAC audio book,m4b,false;QuickTime Plug-in 7.2,npqtplugin4.dll:video/mpeg,MPEG media,mpeg,mpg,m1s,m1v,m1a,m75,m15,mp2,mpm,mpv,mpa,falseaudio/mpeg,MPEG audio,mpeg,mpg,m1s,m1a,mp2,mpm,mpa,m2a,falseaudio/x-mpeg,MPEG audio,mpeg,mpg,m1s,m1a,mp2,mpm,mpa,m2a,falsevideo/3gpp,3GPP media,3gp,3gpp,false;QuickTime Plug-in 7.2,npqtplugin3.dll:audio/x-gsm,GSM audio,gsm,falseaudio/AMR,AMR audio,AMR,falseaudio/aac,AAC audio,aac,adts,falseaudio/x-aac,AAC audio,aac,adts,falseaudio/x-caf,CAF audio,caf,falsevideo/x-mpeg,MPEG media,mpeg,mpg,m1s,m1v,m1a,m75,m15,mp2,mpm,mpv,mpa,false;QuickTime Plug-in 7.2,npqtplugin2.dll:audio/aiff,AIFF audio,aiff,aif,aifc,cdda,falseaudio/x-aiff,AIFF audio,aiff,aif,aifc,cdda,falseaudio/basic,uLaw/AU audio,au,snd,ulw,falseaudio/mid,MIDI,mid,midi,smf,kar,falseaudio/x-midi,MIDI,mid,midi,smf,kar,falseaudio/midi,MIDI,mid,midi,smf,kar,falseaudio/vnd.qcelp,QUALCOMM PureVoice audio,qcp,false;Mozilla Default Plug-in,npnul32.dll:*,Mozilla Default Plug-in,*,false;Adobe Acrobat,nppdf32.dll:application/pdf,Acrobat Portable Document Format,pdf,falseapplication/vnd.adobe.x-mars,Acrobat Portable XML Document Format,mars,falseapplication/vnd.fdf,Acrobat Forms Data Format,fdf,falseapplication/vnd.adobe.xfdf,XML Version of Acrobat Forms Data Format,xfdf,falseapplication/vnd.adobe.xdp+xml, Acrobat XML Data Package,xdp,falseapplication/vnd.adobe.xfd+xml,Adobe FormFlow99 Data File,xfd,false;WindizUpdate Plug-in,npupd62.dll:application/x-windizupdate,WindizUpdate data,u62,false;<a href="http://www.cult3d.com">Cult3D Player</a> v5.3.0.154,NPMCult3DP.dll:application/x-cult3d-object,Cult3D,co,false;Microsoft Office 2003,NPOFFICE.DLL:application/x-msoffice,11.0.5510,*,false;iTunes Application Detector,npitunes.dll:application/itunes-plugin,This plug-in detects the presence of iTunes when opening iTunes Store URLs in a web page with Firefox.,,false;Java(TM) Platform SE 6 U2,npjava14.dll:application/x-java-applet;version=1.4.2,Java Applet,,falseapplication/x-java-bean;version=1.4.2,JavaBeans,,falseapplication/x-java-applet;version=1.5,Java Applet,,falseapplication/x-java-bean;version=1.5,JavaBeans,,falseapplication/x-java-applet;version=1.6,,,falseapplication/x-java-bean;version=1.6,,,false;Java(TM) Platform SE 6 U2,npjava32.dll:application/x-java-applet;version=1.3,Java Applet,,falseapplication/x-java-bean;version=1.3,JavaBeans,,falseapplication/x-java-applet;version=1.2.2,Java Applet,,falseapplication/x-java-bean;version=1.2.2,JavaBeans,,falseapplication/x-java-applet;version=1.2.1,Java Applet,,falseapplication/x-java-bean;version=1.2.1,JavaBeans,,false;Java(TM) Platform SE 6 U2,npjava11.dll:application/x-java-applet;version=1.1.1,Java Applet,,falseapplication/x-java-bean;version=1.1.1,JavaBeans,,falseapplication/x-java-applet;version=1.1,Java Applet,,falseapplication/x-java-bean;version=1.1,JavaBeans,,falseapplication/x-java-applet,Java Applet,,falseapplication/x-java-bean,JavaBeans,,false;Java(TM) Platform SE 6 U2,npjava12.dll:application/x-java-applet;version=1.2,Java Applet,,falseapplication/x-java-bean;version=1.2,JavaBeans,,falseapplication/x-java-applet;version=1.1.3,Java Applet,,falseapplication/x-java-bean;version=1.1.3,JavaBeans,,falseapplication/x-java-applet;version=1.1.2,Java Applet,,falseapplication/x-java-bean;version=1.1.2,JavaBeans,,false;Java(TM) Platform SE 6 U2,npjpi160_02.dll:application/x-java-applet;jpi-version=1.6.0_02,Java Applet,,falseapplication/x-java-bean;jpi-version=1.6.0_02,JavaBeans,,false;Windows Media Player Plug-in Dynamic Link Library,npdsplay.dll:application/asx,Media Files,*,falsevideo/x-ms-asf-plugin,Media Files,*,falseapplication/x-mplayer2,Media Files,*,falsevideo/x-ms-asf,Media Files,asf,asx,*,falsevideo/x-ms-wm,Media Files,wm,*,falseaudio/x-ms-wma,Media Files,wma,*,falseaudio/x-ms-wax,Media Files,wax,*,falsevideo/x-ms-wmv,Media Files,wmv,*,falsevideo/x-ms-wvx,Media Files,wvx,*,false;Microsoft® DRM,npdrmv2.dll:application/x-drm-v2,Network Interface Plugin,nip,false;Microsoft® DRM,npwmsdrm.dll:application/x-drm,Network Interface Plugin,nip,false

Dan een sha256 eroverheen als hash, en dat geef ik bij het inloggen aan de webserver. Als ik dan met mijn logincookie aan het inloggen ga, vraag ik al deze info weer op, maar dan met een challenge erbij. Je moet eigenlijk wel de initieel info (bij het inloggen) encrypted overzenden, misschien met TEA of AES.

Mjah, dat is wel handig ja. Dit is nog weer specifiekere info, die het faken nog weer lastiger maakt. Thnks trouwens voor de javascript code van AES.

[voodooless]

Ja, kwam er ook maar net tegen Die ga ik in ieder geval gebruiken om de hash van bovenstaande info te encrypten (met ingegeven wachtwoord als key+challenge natuurlijk).

[voodooless]

Om hier nog even op terug te komen. Ik heb het geïmplementeerd, en het lijkt erop dat het prima werkt. Voor de AES encryptie heb ik uiteindelijk een andere variant gekozen. Deze werkte wat makkelijker met de backend AES samen

Wat ik dus nu doe:
1. bij inloggen verstuur ik een SHA256 van de berg browserdata encrypted met AES, met een MD5 van het loginwachtwoord als key (MD5 levert makkelijk een 128bit key op) mee. Natuurlijk gaat het loginwachtwoord met SHA256 hash en challenge, en dus niet clear text. De decrypted hash sla ik op in de database samen met het loginID cookie wat de browser krijgt.
2. Bij een nieuwe login zonder actieve sessie check ik op het loginID cookie, en redirect ik naar een pagina, met een form en een hidden field. Hierin verzamel ik weer de SHA256 van de browserdata , en stuur deze SHA256 hashed en challenged weer terug. Serverside check ik dan of alles in order is, en zoja, ben je ingelogd, zoniet, moet je je username/password opgeven (zie 1.)

Zo gaat de data waar je effectief op checked nooit cleartext over de lijn. Je hebt dus niets aan enkel het loginID cookie. Zonder de hash van de browserdata kun je helemaal niets beginnen, en je zult dus al heel wat extra moeite moeten doen om deze data te achterhalen.

Ik moest heel wat in het backend framework aanpassen om dit een beetje netjes voor elkaar te krijgen, maar 't is gelukt. Komende dagen flink testen

[eghie]

voodooless schreef op maandag 15 oktober 2007 @ 16:45:
Om hier nog even op terug te komen. Ik heb het geïmplementeerd, en het lijkt erop dat het prima werkt. Voor de AES encryptie heb ik uiteindelijk een andere variant gekozen. Deze werkte wat makkelijker met de backend AES samen

Wat ik dus nu doe:
1. bij inloggen verstuur ik een SHA256 van de berg browserdata encrypted met AES, met een MD5 van het loginwachtwoord als key (MD5 levert makkelijk een 128bit key op) mee. Natuurlijk gaat het loginwachtwoord met SHA256 hash en challenge, en dus niet clear text. De decrypted hash sla ik op in de database samen met het loginID cookie wat de browser krijgt.
2. Bij een nieuwe login zonder actieve sessie check ik op het loginID cookie, en redirect ik naar een pagina, met een form en een hidden field. Hierin verzamel ik weer de SHA256 van de browserdata , en stuur deze SHA256 hashed en challenged weer terug. Serverside check ik dan of alles in order is, en zoja, ben je ingelogd, zoniet, moet je je username/password opgeven (zie 1.)

Zo gaat de data waar je effectief op checked nooit cleartext over de lijn. Je hebt dus niets aan enkel het loginID cookie. Zonder de hash van de browserdata kun je helemaal niets beginnen, en je zult dus al heel wat extra moeite moeten doen om deze data te achterhalen.

Ik moest heel wat in het backend framework aanpassen om dit een beetje netjes voor elkaar te krijgen, maar 't is gelukt. Komende dagen flink testen

Mooie manier. Lastig om dat te sniffen, al helemaal als het over SSL gaat. Vind het een goed idee. Ga ik waarschijnlijk dan ook maar gebruiken.

[voodooless]

nadeel is dat je niet om javascript heen komt, maar in ons geval is dat niet erg omdat dat toch verplicht is voor de services die wij aanbieden (en nee, 't gaat niet zonder ).