Heavy-duty website beveiliging

[Christiaan]

Ik ben bezig met het opzetten van een beveiligingsmodule voor een grote website waar een hoop data op komt te staan die wel enigszins veilig moet zijn. Natuurlijk is SSL mooier, maar dat valt echt buiten de mogelijkheden (helaas). Roeiend met de riemen die ik wel heb (een Win2K AS server met SQL-Server 2000 EP) heb ik het volgende zitten uitdokteren:

- user voert usernaam in op login1.asp
- client stuurt username naar ASP-script op server
- server controleert of user voorkomt en bepaalt ID van user
- server genereert random string van 40 karakters
- server redirect user naar login2.asp met de random string en userID in de URL
- user voert password in op login2.asp
- client maakt hash van ingevoerde password samen met random string
- client stuurt resultaat, samen met userID en de random string, naar de server
- server haalt password op op basis van userID
- server gebruikt random string en password uit DB om een hash te produceren
- server controleert op client gecreerde hash met op server gecreerde hash
- indien OK: user heeft correct password ingevoerd

Welk algorithme kan ik het beste gebruiken voor het maken van de hash? Op dit moment heb ik een SHA-1 implementatie voor ASP en Jscript geschreven die lekker snel zijn. MD5 lijkt me echter ook voldoende. Is het snelheidsverschil erg groot tussen deze twee?

Nu komen we bij de volgende stap. Ik wil een eigen sessie-systeem ontwikkelen. Dat zou ongeveer zo moeten gaan:

- [ user is net gevalideerd ]
- server maakt sessieID van 40/60 karakters
- server slaat sessieID, userID en IP op in een sessietabel
- server maakt cookie aan bij user met daarin de sessieID

En hier komt een vraagje tussendoor. Op dit moment werk ik met Access, maar het systeem gaat uiteindelijk op SQL-Server 2000 EP draaien. Nu is de sessieID een string van 40 of 60 karakters. Ik kan die kolom de primary key maken, maar dan loop ik het (minimale en bijna verwaarloosbare) risico dat er een kere een sessieID gegenereerd wordt die al bestaat. Het probleem, lijkt mij, is eerder de grootte van de key. Het is nogal een flinke string, en als de server iedere keer in een tabel van X records de juiste ID op moet zoeken met zo’n joekel van een string…. (of werkt een index dat tegen?). Anyways. Het lijkt me makkelijker om een autonummer-kolom op te nemen die een ID-nummertje maakt voor iedere opvolgende sessieID. In de cookie op de client wordt dan deze ID-code en de sessieID opgeslagen. Voordeel is dat de ID-code een klein getalletje is dat veel sneller opgezocht kan worden in de tabel (lijkt me). Vervolgens kan de bijbehorende sessieID in de tabel vergeleken worden met die in de cookie.

- user bezoekt page X
- server haalt sessieID op uit cookie
- server haalt record op uit sessie-tabel mbv de sessieID
- server controleert of sessieIDs klopt en of IP overeen komt
- is IP plots gewisseld, dan is er de mogelijkheid dat een session ge-hijacked is

En dan? Hoe vaak komt het voor dat users gebruik maken van proxy’s die steeds van IP wisselen? Ik neem aan dat ik dan de FORWARDED_FOR header uit kan lezen om dat probleem te omzeilen?

Verder is er nog een uitgebreid rechtensysteem dat hier verder weinig toelichting nodig heeft omdat het er niet zoveel mee te maken heeft. Het gaat meer om de verificatie van een user.

Voor de duidelijkheid; de website gebruikt een soort throttling-systeem dat automatisch overschakeld naar hogere beveiligingsniveaus (kan ik instellen per groep waar gebruiker toe behoort). De genoemde beveiliging is uiteraard voor groepen met zeer veel rechten. Ik wil bovendien nog een feature toevoegen om de client steeds een vooraf afgesproken stringetje mee te laten sturen die op de server gevalideerd kan worden. Dit stringetje is dan vergelijkbaar met telebankieren bij bijv de postbank waarbij je een TAN-code moet opgeven bij het uitvoeren van acties (alleen gaat het hier automatisch). De server stuurt bijvoorbeeld een random string op naar de client die in X stukken geknipt wordt waarvan steeds een stukje teruggestuurd wordt. Alle stukken op? Dan stuurt de server een nieuwe random string.

Wat zie ik hier over het hoofd? Is het veilig en welke gaten zitten er eventueel in? Zijn er verder nog tips of dingen die ik kan gebruiken om het geheel te verbeteren?

[Verwijderd]

Hoe lullig het ook klinkt, als je echt belangrijke data heb staan voor your eyes only dan kun je beter net dat extra bedrag uitgeven aan een SSL certificaat, ipv er later achterkomen dat er toch een slimmerik toegang had tot vertrouwelijke gegevens (zoals bijv. creditcards) en dat je aansprakelijk wordt gesteld voor schade ontstaan door jou keuzes.

Ondanks dat je aangeeft dat het geen optie is, zou ik ondanks alles nogmaals de SSL optie eens serieus gaan bekijken.

[ACM]

ChristiaanVerwijs schreef op 31 December 2002 @ 17:11:
Ik ben bezig met het opzetten van een beveiligingsmodule voor een grote website waar een hoop data op komt te staan die wel enigszins veilig moet zijn. Natuurlijk is SSL mooier, maar dat valt echt buiten de mogelijkheden (helaas). Roeiend met de riemen die ik wel heb (een Win2K AS server met SQL-Server 2000 EP) heb ik het volgende zitten uitdokteren:

een goed loginsysteem staat nogal los van SSL
Hooguit doordat de encryptie het sniffen tegengaat en dat SSL van zichzelf al een aardig sessie systeem kent is het veiliger.

- user voert usernaam in op login1.asp
- client stuurt username naar ASP-script op server
- server controleert of user voorkomt en bepaalt ID van user
- server genereert random string van 40 karakters
- server redirect user naar login2.asp met de random string en userID in de URL
- user voert password in op login2.asp
- client maakt hash van ingevoerde password samen met random string
- client stuurt resultaat, samen met userID en de random string, naar de server
- server haalt password op op basis van userID
- server gebruikt random string en password uit DB om een hash te produceren
- server controleert op client gecreerde hash met op server gecreerde hash
- indien OK: user heeft correct password ingevoerd

Aardig, moet er perse een tweetraps login komen? Waarom niet gelijk de user+pass invoeren op de eerste pagina? (en dat pass dan evt als hash opsturen).

Welk algorithme kan ik het beste gebruiken voor het maken van de hash? Op dit moment heb ik een SHA-1 implementatie voor ASP en Jscript geschreven die lekker snel zijn. MD5 lijkt me echter ook voldoende. Is het snelheidsverschil erg groot tussen deze twee?

Voor strings van bijv 20 chars (das een heel lang password) boeit het tijdsverschil werkelijk niet, het zal ergens tussen nihil en nauwelijks meetbaar zitten voor dat soort strings . Md5 is vast sneller, maar of je dat snelheidsverschil merkt?
Aangezien sha1 langer is, is dat in theorie lastiger bruteforce te kraken.

Nu komen we bij de volgende stap. Ik wil een eigen sessie-systeem ontwikkelen. Dat zou ongeveer zo moeten gaan:

- [ user is net gevalideerd ]
- server maakt sessieID van 40/60 karakters
- server slaat sessieID, userID en IP op in een sessietabel
- server maakt cookie aan bij user met daarin de sessieID

Wellicht nog even opslaan wanneer de sessie begon en wijzigde en controleren of de sessie niet te lang ongebruikt gebleven is of te lang geleden gestart?

En hier komt een vraagje tussendoor. Op dit moment werk ik met Access, maar het systeem gaat uiteindelijk op SQL-Server 2000 EP draaien. Nu is de sessieID een string van 40 of 60 karakters. Ik kan die kolom de primary key maken, maar dan loop ik het (minimale en bijna verwaarloosbare) risico dat er een kere een sessieID gegenereerd wordt die al bestaat.

Bij een duplicate id gewoon opnieuw een bakken

Het probleem, lijkt mij, is eerder de grootte van de key. Het is nogal een flinke string, en als de server iedere keer in een tabel van X records de juiste ID op moet zoeken met zo’n joekel van een string…. (of werkt een index dat tegen?).

Je moet direct je database weggooien en een ander pakken als ie dat niet met een index op kan lossen...
Kortom, ja duplicaten controleren worden over het algemeen gedaan via indices of iets dat daarop lijkt en dat kan ook prima en vlot met strings.

Anyways. Het lijkt me makkelijker om een autonummer-kolom op te nemen die een ID-nummertje maakt voor iedere opvolgende sessieID. In de cookie op de client wordt dan deze ID-code en de sessieID opgeslagen. Voordeel is dat de ID-code een klein getalletje is dat veel sneller opgezocht kan worden in de tabel (lijkt me). Vervolgens kan de bijbehorende sessieID in de tabel vergeleken worden met die in de cookie.

Lijkt me niet nodig dat id ook op te slaan, zoeken naar sessieid's gaat snel zat met een index erop. Nogmaals als je DB geen indices op varchars aankan, weggooien en een andere instellen...

- user bezoekt page X
- server haalt sessieID op uit cookie
- server haalt record op uit sessie-tabel mbv de sessieID
- server controleert of sessieIDs klopt en of IP overeen komt
- is IP plots gewisseld, dan is er de mogelijkheid dat een session ge-hijacked is

Evt dus nog checks op tijdsduren inbakken, IP's kunnen ook gekaapt worden...

En dan? Hoe vaak komt het voor dat users gebruik maken van proxy’s die steeds van IP wisselen? Ik neem aan dat ik dan de FORWARDED_FOR header uit kan lezen om dat probleem te omzeilen?

Das een probleem ja
Als je je bezoeker vertrouwd, laat het hemzelf dan aangeven (dat ie een wisselend ip kan hebben).
HTTP_X_FORWARDED_FOR is overigens geen verplicht veld, vaak zal het wel meegegeven worden, maar om daar nou op te vertrouwen?? "Browsers" die geen proxy gebruiken kunnen het alsnog wel meegeven.

Wat zie ik hier over het hoofd? Is het veilig en welke gaten zitten er eventueel in? Zijn er verder nog tips of dingen die ik kan gebruiken om het geheel te verbeteren?

Is al deze poespas werkelijk nodig?
Weeg de tijd die het kost om het te maken en te laten draaien af tegen het risico van een gehijackte sessie...
Een hiaat in je rechtensysteem kan overigens net zoveel problemen kosten als een gekaapte sessie, zonder dat de sessie ervoor gekaapt hoeft te worden.

Let dus op vele andere aspecten. Bijv, formulieren nooit accepteren van refers waar ze niet vandaan mogen komen en de formulieren die je genereerd altijd een randomid in een hidden veld mee laten geven.

[EfBe]

Bij Win2k server zit een Certificate Server. Hiermee kun je zelf voor CA spelen en certificaten uitgeven. Hiermee kun je dus de connecties beveiligen middels SSL. Het enige nadeel is hierbij dat je OF je CA service moet laten draaien want de browsers zullen jouw certificate niet als 'automatisch trusted' aanmerken, OF je moet de je bezoekers een mogelijkheid bieden dat ze het certificate in de browser installeren zodat ze niet de volgende keer weer 'wilt u dit certificate accepteren?'.

Overigens is security niet iets dat gerelateerd is aan 'heavy duty' of niet. T.a.t. moet je je security logisch en semantisch op orde hebben, zodat iedere bezoeker veilig van de geboden services gebruik kan maken. SSL vreet wel wat CPU power maar niet dermate dat je een extra machine nodig hebt daarvoor.

Als de machine niet een machine is waarop je een virtual directory huurt, zou ik absoluut de site in asp.net bouwen. Hierbij heb je al meteen een cookieless session management system, zodat je dat niet zelf hoeft te bouwen, plus voorzieningen voor formbased security.

[ Voor 17% gewijzigd door EfBe op 31-12-2002 17:56 ]

[Christiaan]

ACM schreef op 31 december 2002 @ 17:29:
een goed loginsysteem staat nogal los van SSL
Hooguit doordat de encryptie het sniffen tegengaat en dat SSL van zichzelf al een aardig sessie systeem kent is het veiliger.

True. Het probleem is dus dat de server waar mijn site op staat een server is waar ik, door een vriendschap met de admin, ruimte op heb gekregen om te doen wat ik wil. Hij heeft geen zin om SSL aan te schaffen, en ik heb geen geld om een eigen server met SSL aan te schaffen. Zoveel is het nu ook weer niet waard. Zoek de fout in wat ik schreef. Lol.

Aardig, moet er perse een tweetraps login komen? Waarom niet gelijk de user+pass invoeren op de eerste pagina? (en dat pass dan evt als hash opsturen).

Hmja, eigenlijk logischer. Mijn beredenatie bevatte een beetje een logische fout. Ik ging er van uit dat een sniffer dan de hash kan onderscheppen en zich voor kan doen als de client door zelf die hash op te sturen. Dat voorkom je eigenlijk helemaal niet door een random string mee te sturen vanaf de server die mee gehashed wordt....

Misschien is het geen gek idee om het IP-adres mee te hashen in plaats van een random string. In dat geval bestaat de hash niet enkel uit het password (alhoewel het niet terug te leiden is, kan een hacker het nog steeds submitten en zich zo voordoen als de andere user). Het IP adres voorkomt dat een ander gebruik kan maken van de hash.

Voor strings van bijv 20 chars (das een heel lang password) boeit het tijdsverschil werkelijk niet, het zal ergens tussen nihil en nauwelijks meetbaar zitten voor dat soort strings . Md5 is vast sneller, maar of je dat snelheidsverschil merkt?
Aangezien sha1 langer is, is dat in theorie lastiger bruteforce te kraken.

SHA-1 it is. Die is een stuk netter geprogrammeerd.

Wellicht nog even opslaan wanneer de sessie begon en wijzigde en controleren of de sessie niet te lang ongebruikt gebleven is of te lang geleden gestart?

Goede opmerking. Maar ook meteen een probleem. De sessie bestaat in de database in de tabel en wordt gekoppeld aan de client doordat de sessieID ook voorkomt in een lokale cookie.

Zolang de cookie blijft bestaan is er geen probleem. Dan kan de sessieID steeds gebruikt worden om te valideren. Maar als de user nu bijvoorbeeld zelf zijn cookies flushed? Dan moet ie sowieso opnieuw inloggen (da's geen probleem - heeft is aan zichzelf te wijten), maar dan zit ik ook met een sessie-record die een beetje rondhangt.

Ik kan die records ook niet zomaar weggooien na inactiviteit van, let's say, een week. Want voor hetzelfde geld is een gebruiker in die week gewoon niet op de site geweest.

Ik kan dus wel valideren of een sessie wel aanwezig is bij een client, maar ik kan niet zien welke sessie al niet meer in gebruik zijn op clients. Wat kan ik daar tegen doen? Hoe is dat door React geregeld?

Je moet direct je database weggooien en een ander pakken als ie dat niet met een index op kan lossen...
Kortom, ja duplicaten controleren worden over het algemeen gedaan via indices of iets dat daarop lijkt en dat kan ook prima en vlot met strings.

SQL-Server, en Access, kunnen dat idd wel. Ik vroeg me alleen af indexes wel zo werkten. Maar eigenlijk bijzonder logisch.

Evt dus nog checks op tijdsduren inbakken, IP's kunnen ook gekaapt worden...

Natuurlijk. De beveiliging op het hoogste niveau vereist dat gebruikers bij zeer kritieke acties sowieso de login opnieuw moeten opgeven.

Das een probleem ja
Als je je bezoeker vertrouwd, laat het hemzelf dan aangeven (dat ie een wisselend ip kan hebben).
HTTP_X_FORWARDED_FOR is overigens geen verplicht veld, vaak zal het wel meegegeven worden, maar om daar nou op te vertrouwen?? "Browsers" die geen proxy gebruiken kunnen het alsnog wel meegeven.

Goed idee. De rest heeft pecht wat mij betreft .

Is al deze poespas werkelijk nodig?
Weeg de tijd die het kost om het te maken en te laten draaien af tegen het risico van een gehijackte sessie...
Een hiaat in je rechtensysteem kan overigens net zoveel problemen kosten als een gekaapte sessie, zonder dat de sessie ervoor gekaapt hoeft te worden.

Let dus op vele andere aspecten. Bijv, formulieren nooit accepteren van refers waar ze niet vandaan mogen komen en de formulieren die je genereerd altijd een randomid in een hidden veld mee laten geven.

Al die andere zaken zijn al goed voorzien. Formulieren zijn goed afgeschermd en werkelijk ieder recht wordt direct tegen de database gevalideerd. Er wordt gebruik gemaakt van een systeem dat zones onderscheidt op de websites. Gebruikers worden lid van een groep en daar ontlenen zijn rechten aan (er zijn er nu 120 zoals ADD_USER, EDIT_USER, ADD_ARTICLE, EDIT_OWN_ARTICLE, EDIT_OTHER_ARTICLE, etc.). Het grappige is dat gebruikers in andere zones andere lidmaatschappen met andere groepen toegewezen kunnen krijgen. Lekker flexibel dus.

Maar bedankt voor de vele tips. Ik ga er meteen een nieuw plan mee opstellen. Sites beveiligen is leuk.

[Christiaan]

EfBe schreef op 31 December 2002 @ 17:54:
Bij Win2k server zit een Certificate Server. Hiermee kun je zelf voor CA spelen en certificaten uitgeven. Hiermee kun je dus de connecties beveiligen middels SSL. Het enige nadeel is hierbij dat je OF je CA service moet laten draaien want de browsers zullen jouw certificate niet als 'automatisch trusted' aanmerken, OF je moet de je bezoekers een mogelijkheid bieden dat ze het certificate in de browser installeren zodat ze niet de volgende keer weer 'wilt u dit certificate accepteren?'.

Het probleem is, zoals geschetst in de reply op ACM, dat de admin echt niet aan SSL wil. Ik wil echter wel een goed beveiligd systeem en geen eigen server hoeven aanschaffen.

Overigens is security niet iets dat gerelateerd is aan 'heavy duty' of niet. T.a.t. moet je je security logisch en semantisch op orde hebben, zodat iedere bezoeker veilig van de geboden services gebruik kan maken. SSL vreet wel wat CPU power maar niet dermate dat je een extra machine nodig hebt daarvoor.

Je hebt me betrapt op een definitiefoutje . Hij is wel heavy-duty in die zin dat er veel bezoekers komen, maar dat beveiliging relatief snel maar toch erg veilig moet zijn gezien de diversiteit aan functionaliteiten die aangeboden worden.

[Zoijar]

Je kan beter je passwords ook md5 hashed in je database opslaan. Dus de client stuurt dan:

md5(md5(input_password) + random_string)

en dat wordt vergeleken met

md5(database_password + random_string)

Verder doe ik het precies hetzelfde wegens gebrek aan SSL. Let er wel op dat dit nog steeds relatief simpel kraakbaar is als je (root) toegang hebt tot een tussenliggende router.

[ACM]

ChristiaanVerwijs schreef op 31 December 2002 @ 17:55:
Hmja, eigenlijk logischer. Mijn beredenatie bevatte een beetje een logische fout. Ik ging er van uit dat een sniffer dan de hash kan onderscheppen en zich voor kan doen als de client door zelf die hash op te sturen. Dat voorkom je eigenlijk helemaal niet door een random string mee te sturen vanaf de server die mee gehashed wordt....

Misschien is het geen gek idee om het IP-adres mee te hashen in plaats van een random string. In dat geval bestaat de hash niet enkel uit het password (alhoewel het niet terug te leiden is, kan een hacker het nog steeds submitten en zich zo voordoen als de andere user). Het IP adres voorkomt dat een ander gebruik kan maken van de hash.

Je kan dat random id ook gelijk al meesturen, als de reden van het randomid de veiligere hashing was iig

Ik kan die records ook niet zomaar weggooien na inactiviteit van, let's say, een week. Want voor hetzelfde geld is een gebruiker in die week gewoon niet op de site geweest.

Als je cookie de geldigheid verliest, kan je sessie (een tijdje later) ook zijn geldigheid verliezen. Als je superveilig wilt zijn moet je ze gewoon elke keer opnieuw in laten loggen en dus kan je echt na een week (van inactiviteit) een sessie wel ongeldig verklaren.

Ik kan dus wel valideren of een sessie wel aanwezig is bij een client, maar ik kan niet zien welke sessie al niet meer in gebruik zijn op clients. Wat kan ik daar tegen doen? Hoe is dat door React geregeld?

Geen, af en toe zal dat handmatig gedelete moeten worden (sessies waarbij een maand lang niks gedaan is kunnen echt wel weg, de users die daar gedupeerd door worden hebben dan maar pech...)

Formulieren zijn goed afgeschermd en werkelijk ieder recht wordt direct tegen de database gevalideerd.

Dat dachten we bij react ook
Bleek het toch nog gevoelig voor een vorm van crosssite scripting (de reden dat nu alle (?) form's voorzien zijn van een reactid zodat er altijd een verifieerbaar, maar wijzigende waarde instaat. Nepformulieren van buitenaf (die bijv dmv javascript gepost worden met jouw rechten!) zijn daarmee onbruikbaar.

Maar bedankt voor de vele tips. Ik ga er meteen een nieuw plan mee opstellen. Sites beveiligen is leuk.

Succes, het is trouwens ook een van de moeilijkste stukken van het webprogrammeren

[Zoijar]

ChristiaanVerwijs schreef op 31 december 2002 @ 17:55:

Hmja, eigenlijk logischer. Mijn beredenatie bevatte een beetje een logische fout. Ik ging er van uit dat een sniffer dan de hash kan onderscheppen en zich voor kan doen als de client door zelf die hash op te sturen. Dat voorkom je eigenlijk helemaal niet door een random string mee te sturen vanaf de server die mee gehashed wordt....

Misschien is het geen gek idee om het IP-adres mee te hashen in plaats van een random string. In dat geval bestaat de hash niet enkel uit het password (alhoewel het niet terug te leiden is, kan een hacker het nog steeds submitten en zich zo voordoen als de andere user). Het IP adres voorkomt dat een ander gebruik kan maken van de hash.

Je hebt twee verschillende aanvallen hier, nl. "replay attack" en "man in the middle attack". Replay attack is simpel, de has van je wachtwoord is altijd hetzelfde, dus als die onderschept wordt en op een nieuwe verbinding gestuurd wordt is de hacker binnen. Vandaar dat je een random waarde erbij voegt, dan kan dit niet meer.
Bij man-in-the-middle (of relay maar lijkt zo op replay) zit de hacker echt tussen de client en server op de lijn, en kan deze netwerk packets veranderen. Door gewoon alles van en naar client/server door te sturen naar server/client komt er een geldige sessie tot stand. Daarna is de hacker binnen. Hier is heel weinig tegen te doen, zo zal het IP mee hashen niet helpen.
Je kan er voor zover ik weet met deze setup niets tegen doen, niet met alleen hashen. Er zal echt iets encrypt moeten worden op de client, en decrpyted op de server met in elk packet een md5 van het packet en het wachtwoord. Dan kan je netwerk verkeer niet meer wijzigen, maar dit is in feite SSL.

[ACM]

En dat zijn ook weer de minder vaak voorkomende aanvallen, bij mijn weten

[EfBe]

De admin wil niet aan 'SSL' ? Wat voor reden geeft deze 'admin' daar dan voor? Want de ingewikkeldheid bij het installeren van een key kan het niet zijn Wil je veiligheid voor de passwords van je gebruikers, dan is SSL echt aan te bevelen. Maakt het niet zoveel uit, dan zou ik me er niet zo druk om maken (lees: 'bezoek is op eigen risico'). Zoals ik al zei, als je asp.net gebruikt, kun je dmv formbased security asp.net zorg laten dragen voor een hashed cookie id die zorgt voor het inloggen van de user wanneer deze terugkomt op de website (zodat deze niet weer zn username/password hoeft in te geven).

Maar goed, ik vrees dat jouw 'admin' (die wel alle patches draait? I doubt it) ook niet aan '.net' wil, als hij ook niet aan 'ssl' wil...

[Verwijderd]

ACM schreef op 31 December 2002 @ 18:04:
Succes, het is trouwens ook een van de moeilijkste stukken van het webprogrammeren

Voor iemand die niet veel met het web bezig is wel. Maar voor iemand die de techniek op het web goed kent niet. Iemand die niet van de mogelijkheden qua scripting afweet zal ook niet een beveiliging inbouwen tegen een dergelijke mogelijkheid.

[djluc]

Ik vind dit topic wel interessant, maar ik zou het niet in real-life gaan toepassen. Dit is misschien leuk om zo te proberen, en gewoon om er mee te kloten hartstikke intressant allemaal. Aan SSL zijn een hele hoop mensen enorm lang mee bezig geweest, en wordt nu nog steeds verbeterd/ontwikkeld, iets namaken wat zo veilig is zonder een implementatie aan de client zijde is vrijwel onmogelijk in je eentje. Ook omdat je alleen niet alles kunt beredeneren, alle manieren om je systeem binnen te dringen, informatie te onderscheppen enz.

Misschien moet je dit topic straks eens laten lezen door je admin, nadat we wat nog wat opmerkingen over 'zijn' beleid gegeven hebben. ;-)

[Zoijar]

ACM schreef op 31 december 2002 @ 18:24:
En dat zijn ook weer de minder vaak voorkomende aanvallen, bij mijn weten

Ja dat dachten die amerikaanse straaljagers dus ook met hun IFF

Hehe nee maar klopt, zou ik me ook niet druk om maken, tenzij je iets voor een bank maakt...:P

[ACM]

Verwijderd schreef op 31 december 2002 @ 18:43:
Voor iemand die niet veel met het web bezig is wel. Maar voor iemand die de techniek op het web goed kent niet. Iemand die niet van de mogelijkheden qua scripting afweet zal ook niet een beveiliging inbouwen tegen een dergelijke mogelijkheid.

Voor iedereen, imho

Aangezien veel bugs in een webapplicatie ook direct de veiligheid in gevaar kunnen brengen. En als je ervaring met zoiets hebt kan je uiteraard de kennis/code van de vorige keer hergebruiken, dat neemt nog niet weg dat het nog steeds moeilijk blijft om om allerlei zaken (stateless/connectionless zijn bijv) van HTTP en (niet weten waar je verkeer langsgaat en dus de route niet kunnen vertrouwen) TCP/IP heen te werken, danwel af te vangen en/of te controleren..

[Christiaan]

Het gaat niet per definitie om een systeem dat net zo veilig is als SSL. Het gaat om een systeem waarbij passwords enigszins veilig aan de andere kant van de lijn terecht komen. Natuurlijk is SSL prachtig enzo, maar het vereist ook het gebruik van certificates, en ik heb de admin niet zover kunnen krijgen daaraan te beginnen. Sterker nog; gezien zijn ervaring kan hij dat maar beter niet doen . Maar dat neemt niet weg dat ik zeer graag een stuk van zijn server wil gebruiken. Het is een hele ruimte aan server-apparatuur waar een relatief bekend netwerk van sites op gedraaid wordt. Er zit daar dus heel wat vermogen - dan maar geen SSL.

Zoals gezegd kun je ook zonder SSL een aardige beveiliging krijgen. Het verkeer na de validatie behoeft geen beveiliging. Het gaat juist om dat ene kritieke moment waarop de validatie plaatsvindt en de momenten waarop rechten geverifieerd worden.

[Christiaan]

ACM schreef op 31 december 2002 @ 19:42:
Voor iedereen, imho

Aangezien veel bugs in een webapplicatie ook direct de veiligheid in gevaar kunnen brengen. En als je ervaring met zoiets hebt kan je uiteraard de kennis/code van de vorige keer hergebruiken, dat neemt nog niet weg dat het nog steeds moeilijk blijft om om allerlei zaken (stateless/connectionless zijn bijv) van HTTP en (niet weten waar je verkeer langsgaat en dus de route niet kunnen vertrouwen) TCP/IP heen te werken, danwel af te vangen en/of te controleren..

Ik mag mezelf wat dat betreft troosten met de gedachte dat ik op dit moment rond de 5 jaar ervaring met ASP en webdevelopment heb. In de loop der tijd zijn de systemen die ik ontwikkeld heb steeds flexibeler en veiliger geworden. Het enige heikele punt was nog het beveiligingssysteem en dat wilde ik aanpakken.

Het probleem met goede beveiliging is volgens mij meer verscholen in de logica die achter een systeem schuilgaat. Je moet stap voor stap controleren of er echt geen manieren zijn om de validatie op zijn gat te krijgen. Dat is moeilijker dan de ontwikkeling op zichzelf. Het systeem zoals beschreven bouw ik wel in een halve week, maar het gaat juist om het ontwerp - dat moet goed zijn.

[djluc]

Sterker nog; gezien zijn ervaring kan hij dat maar beter niet doen .Maar dat neemt niet weg dat ik zeer graag een stuk van zijn server wil gebruiken. Het is een hele ruimte aan server-apparatuur waar een relatief bekend netwerk van sites op gedraaid wordt. Er zit daar dus heel wat vermogen - dan maar geen SSL.

Lekker met een admin die liever niet met SSL werkt omdat hij dat niet kan :-))

[ACM]

ChristiaanVerwijs schreef op 31 december 2002 @ 19:53:
Het probleem met goede beveiliging is volgens mij meer verscholen in de logica die achter een systeem schuilgaat. Je moet stap voor stap controleren of er echt geen manieren zijn om de validatie op zijn gat te krijgen. Dat is moeilijker dan de ontwikkeling op zichzelf. Het systeem zoals beschreven bouw ik wel in een halve week, maar het gaat juist om het ontwerp - dat moet goed zijn.

Dat lijkt mij ook wel

En hoe logischer/duidelijker je het geheel (voor jezelf iig) opzet, hoe beter het zal worden.

djluc schreef op 31 december 2002 @ 20:09:
Lekker met een admin die liever niet met SSL werkt omdat hij dat niet kan :-))

Maakt de uitdaging om het goed te doen alleen maar beter, SSL is voor veel gevallen overkill, terwijl je toch wel een veilige login procedure wilt.
Dat het niet compleet onkraakbaar is, is een risico dat je bijna altijd toch wel moet nemen (waar is een groter kans op, een gebruiker die zijn password per ongeluk vermeldt aan een derde of dat de boel gekraakt wordt op een andere manier??)

[Christiaan]

djluc schreef op 31 December 2002 @ 20:09:
Lekker met een admin die liever niet met SSL werkt omdat hij dat niet kan

Ach, op dit moment gebeurt het geregeld dat een bepaalde site de inetsrv service over zijn toeren brengt en in een infinite loop verzeild raakt waar ie alleen uit kan komen door een handmatige reset van de service. Belabberde ASP-code van die beste man. Zijn servers zijn ook al best vaak gehacked. Intussen is het allemaal een stuk beter gesteld met het geheel - maar daarvoor hebben we dan ook heel wat uren via de email zitten praten over hoe het beter kon.

En het is ook een leuke uitdaging om, zoals ACM ook zegt, zelf iets te maken dat toch veilig is.