Bescherming van je broncode tegen decompilatie

[Verwijderd]

Ok, bedankt voor de informatie, kzal nog es zoeken voor mijn beveiliging wat te verbeteren en es kijken of ik een obfucator ga gebruiken of niet...

Juist nog een vraagje, gebruiken veel mensen eigenlijk een obfuscator?

[ Voor 20% gewijzigd door Verwijderd op 18-07-2009 17:46 ]

[BCC]

SKiLLa schreef op zaterdag 18 juli 2009 @ 17:27:
PS: M.b.t. die beveiligde database-connectie; het is leuk als jou tool beveiligd is, maar in de database-driver zal uiteindelijk ergens je ConnectionString unencrypted moeten staan om een verbinding op te zetten; een hacker kan daar zo een breakpoint op zetten

Nog veel makkelijk: als er naar die database verbonden wordt, dan komt de connectie string plain text voorbij in netwerk pakketjes. Obfuscators voor .NET talen zijn trouwens erg zinloos. Alles wordt gerund als .net bytecode, wat erg eenvoudig te analyzeren is.

Obfuscators worden op dit moment vooral gebruikt in de game industrie en je weet zelf vast wel hoe succesvol dat is. Als je iets veilig wil maken, moet je echt iets anders gaan doen dan security by obscurity.

[ Voor 14% gewijzigd door BCC op 18-07-2009 18:10 ]

[VisionMaster]

Verwijderd schreef op zaterdag 18 juli 2009 @ 17:45:
Ok, bedankt voor de informatie, kzal nog es zoeken voor mijn beveiliging wat te verbeteren en es kijken of ik een obfucator ga gebruiken of niet...

Juist nog een vraagje, gebruiken veel mensen eigenlijk een obfuscator?

Het wordt gebruikt in games, maar ja... alles is al gecracked. Daar zitten hele goede obfuscators tussen, maar helaas. Verder worden obfuscators gebruikt in botnets om de botjes niet zomaar te kunnen reverse engineren. Niet dat het zelfde lot gegunt is aan de botjes als de spelletjes, maar er kijken wat minder mensen naar botjes dan spelletjes (denk ik zo).

Kort om... het is nutteloos. Ik vergelijk het graag met WEP encryptie voor de wireless. Het is niet gelijk open, maar een handige peer heeft je wireless wachtwoord ontfutseld in 5 minuten

Standaard is dat je geen debug build maakt, zodat je er direct een debugger aan kan hangen. In mijn werk omgeving is het juist wel de bedoeling om de code te kunnen debuggen. Ook de security code, om te zien of het wel goed zijn werk doet.

Wij gebruiken alleen open source oplossingen en onze beveiliging heeft de OpenSSL library als basis voor heel veel dingen (soms met wat toevoegingen), maar de basis is al jaren volledig open. En toch worden we niet gehackt door iedereen die een debugger of reverse engineering actie uitvoerd.

Het heeft allemaal te maken met wat voor type beveiliging je toepast en wat je doel is. Het hoeft allemaal niet zo moeilijk te zijn wat je zelf moet doen om het veiliger te maken. Ik zou vooral oppassen om niet zelf het wiel uit te willen vinden. Zoals eigen hash algoritmen te bedenken. Het beste is om iets te gebruiken wat al in .Net zelf kan worden gebruikt.

Ik mag aan nemen dat het bijvoorbeeld md5 of sha1 wel native aanbied als mooie hash algoritmen.

[ Voor 5% gewijzigd door VisionMaster op 18-07-2009 18:14 ]

[Verwijderd]

Heeft er iemand ervaring met een obfuscator? eventueel met de skator?( zie link begin topic)

[Frank.S]

Hallo nahow1,

Allereerst, geen enkel stuk software is niet te kraken. Aangezien jouw programma in .net is geschreven is het inderdaad relatief eenvoudig om de software te reverse-engineeren. Alle instructies moeten namelijk door een soort van virtual machine met een intermediate language. Hiervoor zijn bijvoorbeeld tools geschreven die deze code gewoon weer terug zetten naar leesbare .net code. Een goed voorbeeld hiervan is: Redgate’s .net Reflector.

Obfuscators zijn een van de simpelste stappen om je code te beschermen. Echter is niet elke obfuscator het zelfde, de simpelste versie (gratis versie zit in visual studio) doet alleen maar function names en variables onzinnig/leesbaar maken. De wat geavanceerdere versies gebruiken encryptie algorithms die net voor de JIT weer decrypted worden. Misschien kan deze site je hierbij helpen: http://howtoselectguides....cators/1st#sc_obfuscators
Maar een obfuscator is niet heilig, uiteindelijk kan je de .net of MSIL code weer naar voren toveren.
Java heeft naar mijn weten het zelfde probleem, uiteindelijk is het makkelijker te dissambelen dan native code voor het doel platform.

Een alternatief zijn launchers en packers. Dit zijn kleine programma’s/stukken code die jouw originele applicatie encapsuleren. Deze applicaties laten jouwn applicatie bijvoorbeeld draaien in een stukje encrypted memory en zijn daardoor moeilijker te disassemble. Deze packers/launchers zijn meestal geschreven in bijvoorbeeld: C/C++/ASM. Hierdoor is de applicatie niet meer door Red Gates .net Reflector te halen. ( er zit namelijk geen .net spul meer omheen). Echter uiteindelijk is dit ook weer te kraken.
Overstappen naar C++ kan je doen, echter dit is ook niet heilig. Als jij niets doet aan beveiliging voor de gecompileerde code kan het net zo makkelijk reversed/gekraakt worden. De drempel om het te doen is misschien wat hoger, maar het kan relatief eenvoudig. Bijvoorbeeld als jij een schermpje hebt waar de gebruiker een wachtwoord moet invullen, en je terug geeft het wachtwoord goed was of niet. Dan kan men 7/10 keer de letterlijke string van jouw bericht terug vinden in een disassembler. Hier kan je dan een breakpoint neer zetten, en langzaam maar zeker terug “jumpen” naar je beveiligingscode. Hiervoor wordt vaak OllyDBG of Syser Debugger gebruikt. Het is allemaal assembly wat eruit komt, maar goed te begrijpen. IDA Pro is ook een professionele tool om zoiets voor elkaar te krijgen. Dit is ook te kraken, alleen moeilijker.

Een laatste methode is Code Virtualization. Hiervoor zijn tools zoals Themida of Code Virtualizer van Oreans Software (http://www.oreans.com/products.php) voor in het leven gebruiken. Ook Xenocode (http://www.xenocode.com/) heeft heel leuke tool die Code Virtualization toepassen. Bijvoorbeeld Xenocode genereerd een minivirtual machine die jouw applicatie encapsuleerd. Jouw code wordt samen met alle dependencies mee gecompileerd in een enkele executable. Deze executable is dan de mini virtual machine en de code calls van die machine worden gesnapt door je host OS. Voor betere uitleg zou ik de sites van Oreans en Xenocode eens doorlezen. Echter zijn deze tools ook te kraken: http://www.codebreakers-journal.com/content/view/290/97/

Al de bovengenoemde tools zijn meestal niet gratis en zeker niet goedkoop. Het is maar net hoe sterk jij de beveiliging wil hebben. Alles is uiteindelijk kraakbaar, je kan het alleen wat langer laten duren. Je kan je ook afvragen of je de beveiliging wel nodig hebt. Als het mogelijk is om de applicatie in een client-server architectuur te gieten dan kan je erover denken om essentiële functionaliteit aan de server kant te leggen. Zo zijn de gebruikers afhankelijk van de service/server die jij alleen in bezit hebt. Dit kan men weer langzaam emuleren e.d. maar het maakt het minder aantrekkelijk. Jij hoeft je dan niet meer druk te maken dat ze je code reversen, je kroon juweel zit dan nog steeds op je server.

Een goed algoritme of data te beveiliging is bijvoorbeeld public/private keypairs als je applicatie veel communicatie heeft of voor licensing mechanismen. Gebruik ook bewezen algorithms, ga vooral niet het wiel opnieuw uitvinden.

Hopelijk heb ik je niet weg gejaagd door de vele tekst en heb ik je enigszins kunnen helpen. Ik wens je veel succes met de keuzes die je gaat maken. En als er iets niet klopt in mijn verhaal hoor ik het graag!
Nog een link met interessante link met leesvoer:
.net Protection and Reversing: http://www.codebreakers-journal.com/content/view/123/97/

[BCC]

Geld uitgeven aan een obfuscator is imho weggegooid geld. Zeker als het om een taal gaat met een bytecode tussenlaag (java / .net)

[Verwijderd]

Frank.S schreef op zaterdag 18 juli 2009 @ 18:22:
Hallo nahow1,

Allereerst, geen enkel stuk software is niet te kraken. Aangezien jouw programma in .net is geschreven is het inderdaad relatief eenvoudig om de software te reverse-engineeren. Alle instructies moeten namelijk door een soort van virtual machine met een intermediate language. Hiervoor zijn bijvoorbeeld tools geschreven die deze code gewoon weer terug zetten naar leesbare .net code. Een goed voorbeeld hiervan is: Redgate’s .net Reflector.

Obfuscators zijn een van de simpelste stappen om je code te beschermen. Echter is niet elke obfuscator het zelfde, de simpelste versie (gratis versie zit in visual studio) doet alleen maar function names en variables onzinnig/leesbaar maken. De wat geavanceerdere versies gebruiken encryptie algorithms die net voor de JIT weer decrypted worden. Misschien kan deze site je hierbij helpen: http://howtoselectguides....cators/1st#sc_obfuscators
Maar een obfuscator is niet heilig, uiteindelijk kan je de .net of MSIL code weer naar voren toveren.
Java heeft naar mijn weten het zelfde probleem, uiteindelijk is het makkelijker te dissambelen dan native code voor het doel platform.

Een alternatief zijn launchers en packers. Dit zijn kleine programma’s/stukken code die jouw originele applicatie encapsuleren. Deze applicaties laten jouwn applicatie bijvoorbeeld draaien in een stukje encrypted memory en zijn daardoor moeilijker te disassemble. Deze packers/launchers zijn meestal geschreven in bijvoorbeeld: C/C++/ASM. Hierdoor is de applicatie niet meer door Red Gates .net Reflector te halen. ( er zit namelijk geen .net spul meer omheen). Echter uiteindelijk is dit ook weer te kraken.
Overstappen naar C++ kan je doen, echter dit is ook niet heilig. Als jij niets doet aan beveiliging voor de gecompileerde code kan het net zo makkelijk reversed/gekraakt worden. De drempel om het te doen is misschien wat hoger, maar het kan relatief eenvoudig. Bijvoorbeeld als jij een schermpje hebt waar de gebruiker een wachtwoord moet invullen, en je terug geeft het wachtwoord goed was of niet. Dan kan men 7/10 keer de letterlijke string van jouw bericht terug vinden in een disassembler. Hier kan je dan een breakpoint neer zetten, en langzaam maar zeker terug “jumpen” naar je beveiligingscode. Hiervoor wordt vaak OllyDBG of Syser Debugger gebruikt. Het is allemaal assembly wat eruit komt, maar goed te begrijpen. IDA Pro is ook een professionele tool om zoiets voor elkaar te krijgen. Dit is ook te kraken, alleen moeilijker.

Een laatste methode is Code Virtualization. Hiervoor zijn tools zoals Themida of Code Virtualizer van Oreans Software (http://www.oreans.com/products.php) voor in het leven gebruiken. Ook Xenocode (http://www.xenocode.com/) heeft heel leuke tool die Code Virtualization toepassen. Bijvoorbeeld Xenocode genereerd een minivirtual machine die jouw applicatie encapsuleerd. Jouw code wordt samen met alle dependencies mee gecompileerd in een enkele executable. Deze executable is dan de mini virtual machine en de code calls van die machine worden gesnapt door je host OS. Voor betere uitleg zou ik de sites van Oreans en Xenocode eens doorlezen. Echter zijn deze tools ook te kraken: http://www.codebreakers-journal.com/content/view/290/97/

Al de bovengenoemde tools zijn meestal niet gratis en zeker niet goedkoop. Het is maar net hoe sterk jij de beveiliging wil hebben. Alles is uiteindelijk kraakbaar, je kan het alleen wat langer laten duren. Je kan je ook afvragen of je de beveiliging wel nodig hebt. Als het mogelijk is om de applicatie in een client-server architectuur te gieten dan kan je erover denken om essentiële functionaliteit aan de server kant te leggen. Zo zijn de gebruikers afhankelijk van de service/server die jij alleen in bezit hebt. Dit kan men weer langzaam emuleren e.d. maar het maakt het minder aantrekkelijk. Jij hoeft je dan niet meer druk te maken dat ze je code reversen, je kroon juweel zit dan nog steeds op je server.

Een goed algoritme of data te beveiliging is bijvoorbeeld public/private keypairs als je applicatie veel communicatie heeft of voor licensing mechanismen. Gebruik ook bewezen algorithms, ga vooral niet het wiel opnieuw uitvinden.

Hopelijk heb ik je niet weg gejaagd door de vele tekst en heb ik je enigszins kunnen helpen. Ik wens je veel succes met de keuzes die je gaat maken. En als er iets niet klopt in mijn verhaal hoor ik het graag!
Nog een link met interessante link met leesvoer:
.net Protection and Reversing: http://www.codebreakers-journal.com/content/view/123/97/

Bedankt voor de informatie. Zal nog wat opzoekkings werk doen, en eventueel een van die oplossingen gebruiken

[Confusion]

djexplo schreef op zaterdag 18 juli 2009 @ 16:09:
Wikipedia: Security through obscurity is vaak geen goed idee, je kan beter een goed algorithme gebruiken voor je sleutels...

Deze reactie slaat als een tang op een varken. Dat security through obscurity geen goed idee is, is hier niet van toepassing, omdat echte security onmogelijk is. De enige manier om broncode te beschermen is door obscurity. Je broncode moet per definitie omgezet worden in een vorm die de CPU begrijpt (tenzij er van een special purpose systeem sprake is, met hardware decryptie. En zelfs dan kan je vaak de instructies nog te pakken krijgen door de machine fysiek te hacken). In dat proces is altijd in een bepaalde stadium in te breken, waardoor een reverse engineer de code minimaal in machinecode, meestal in assembly en vaak in een tussenliggende bytecode beschikbaar heeft. Daar gaat geen encryptie van de broncode aan helpen.

[djexplo]

Confusion schreef op zaterdag 18 juli 2009 @ 18:52:
[...]

Deze reactie slaat als een tang op een varken. Dat security through obscurity geen goed idee is, is hier niet van toepassing, omdat echte security onmogelijk is. De enige manier om broncode te beschermen....

Het ging hier dan ook niet om het beschermen van zijn broncode, maar om een database wachtwoord in zijn code ...

[Confusion]

djexplo schreef op zaterdag 18 juli 2009 @ 19:26:
[...]
Het ging hier dan ook niet om het beschermen van zijn broncode, maar om een database wachtwoord in zijn code ...

Of je nu een plaintext of een gehashed wachtwoord in je code opneemt maakt niets uit: iemand kan met het wachtwoord dat in de code is opgenomen inloggen. Dat heeft niets met security-through-obscurity of gebruik van goede algoritmes te maken. Als iemand de broncode van een applicatie in handen heeft, inclusief de, al dan niet in de code opgenomen, configuratie, dan is alles in principe verloren.

Overigens ben je natuurlijk volkomen verkeerd bezig als je voor de veiligheid van een wachtwoord vertrouwt op het opnemen van het wachtwoord, en het vervolgens obfuscaten daarvan, in je code. Een database wachtwoord hoort gewoon plaintext in een configuratiebestand te staan.

[BCC]

Eh Confusion, volgens mij moet je het topic ff helemaal doorlezen.

[chime]

Verwijderd schreef op zaterdag 18 juli 2009 @ 16:59:
Qt designer heb ik al uitgetest, maar vond het niet zo goed..., het is enkel freeware voor non commerical edition

[...]


Wel, ik gebruik al hash encryptie voor mijn password:
Eventjes duidelijker zijn wat mijn programma precies doet:
De gebruiker moet inloggen met een username en password. Dan maakt het programma connectie met een database waarbij de key die meegezonden wordt moet kloppen anders is er een 'hack poging', soort beveiliging van de connectie, dus als je nu de programma kunt decompilen kun je zo ook die key vinden, en zo een succesvolle 'hackpoging' doen omdat de key klopt

Dus als ik het goed begrijp:
- gebruiker logt in met username en password
- pas daarna gaat het programma connectie maken met de database en een code meesturen

Is de volgende optie niet iets beter:
- gebruiker geeft username en password in
- programma doet met een beperkte database user, met alleen lees-rechten op user-pwd tabel een check en verifieert dat het gebruiker zijn wachtwoord klopt (opgeslagen hash - vergelijken met gegenereerde)
- indien ok: connectie leggen met database met de correcte gebruiker

[BCC]

Nog mooier: een webservice voor de DB die alles afhandelt.

[Confusion]

BCC schreef op zaterdag 18 juli 2009 @ 21:14:
Eh Confusion, volgens mij moet je het topic ff helemaal doorlezen.

De reactie waar ik op reageerde was de derde reactie. Dan kan het dus onmogelijk nodig zijn de rest van het topic te lezen om die reactie te begrijpen. Los daarvan heb ik het topic gelezen en begrijp ik niet waar je op doelt.

Verderop heeft djexplo het nog over de mogelijkheid de md5 hash ergens van in je code op te nemen. Dat is levert dezelfde discussie op als wanneer weer eens iemand verzint dat het veiliger is om in javascript de md5 van een wachtwoord te nemen en dat te versturen: dat is niet zo, omdat het enige dat van belang is hetgene is dat over het lijntje gaat.

[H004]

Confusion schreef op zaterdag 18 juli 2009 @ 23:50:
[...]
Verderop heeft djexplo het nog over de mogelijkheid de md5 hash ergens van in je code op te nemen. Dat is levert dezelfde discussie op als wanneer weer eens iemand verzint dat het veiliger is om in javascript de md5 van een wachtwoord te nemen en dat te versturen: dat is niet zo, omdat het enige dat van belang is hetgene is dat over het lijntje gaat.

Hoezo is dat niet veiliger? Uiteraard is een md5'ed password nog steeds prima te onderscheppen en met rainbowtables etc te achterhalen, maar het vormt toch weer een extra barrière bovenop de beveiliging? Of doel je op het feit dat bv. sha1 een betere bescherming biedt, omdat het vinden van een collision (momenteel nog) lastiger is?

[Verwijderd]

sha1 en md5 zijn eigenlijk al makkelijk te kraken, beter om een mengelin van de 2 te nemen en mss sha2 + nog een random key, dat maakt het al heel veel moeilijker te kraken...

Iemand ervaring met een obfuscator?

[blaataaps]

H004 schreef op zondag 19 juli 2009 @ 01:03:
[...]

Hoezo is dat niet veiliger?

Hoezo is dat wel veiliger?

Verwijderd schreef op zondag 19 juli 2009 @ 10:34:
sha1 en md5 zijn eigenlijk al makkelijk te kraken, beter om een mengelin van de 2 te nemen

Hoe zie je die mengeling precies voor je, en hoe precies is dat veiliger?

[Confusion]

H004 schreef op zondag 19 juli 2009 @ 01:03:
Hoezo is dat niet veiliger? Uiteraard is een md5'ed password nog steeds prima te onderscheppen en met rainbowtables etc te achterhalen, maar het vormt toch weer een extra barrière bovenop de beveiliging? Of doel je op het feit dat bv. sha1 een betere bescherming biedt, omdat het vinden van een collision (momenteel nog) lastiger is?

Het idee achter het gebruik van gehashte wachtwoorden in je database, is dat als iemand de database te pakken krijgt, hij niet in kan loggen. Een gebruiker zou 'password123' invoeren, de code die dat ontvangt maakt daar '7576f3a00f6de47b0c72c5baf2d505b0'^[1] van en vergelijkt dat met wat er in de database staat. Degene die de database te pakken heeft, kan alleen '7576f3a00f6de47b0c72c5baf2d505b0' invoeren. De applicatie maakt daar '0d65c1187700c09a20c3c145d16821c6'^[2] van en dat levert geen match op.

Voert de gebruiker 'password123' en en hash je dat in javascript, dan gaat er '7576f3a00f6de47b0c72c5baf2d505b0' over het lijntje. Als je het verprutst, dan is dat ook wat er in de database staat. In dat geval kan een aanvaller die de database te pakken krijgt inloggen met het wachtwoord '7576f3a00f6de47b0c72c5baf2d505b0' dat in de database staat. Dat kan hij gewoon insturen, door dat vanuit zijn eigen HTML pagina te sturen of javascript in de jouwe uit te schakelen. De hashing uit de javascript halen is ook bepaald niet moeilijk. Als je het niet verprutst, dan maakt de applicatie er '0d65c1187700c09a20c3c145d16821c6' van en staat dat ook in de database. In dat geval kan de aanvaller die de database te pakken krijgt niet met de hash inloggen. In dat geval biedt het echter ook geen enkele extra bescherming om het wachtwoord al in javascript te hashen. '7576f3a00f6de47b0c72c5baf2d505b0' is, voor wat betreft sniffing, net zo veilig als 'password123'. Als we het over bruteforcing gaan hebben biedt het ook geen enkele toevoeging, omdat een aanvaller ziet dat je de wachtwoorden in javascript hashed en dus gewoon gehashte wachtwoorden in gaat sturen. Een van de gebreken van md5 is dat het snel is en dat je dus gemakkelijk al die hashes kunt genereren. Crypt() in unix is opzettelijk traag.

^[1]md5('password123')
^[2]md5(md5('password123'))

Verwijderd schreef op zondag 19 juli 2009 @ 10:34:
sha1 en md5 zijn eigenlijk al makkelijk te kraken, beter om een mengelin van de 2 te nemen en mss sha2 + nog een random key, dat maakt het al heel veel moeilijker te kraken...

Iemand ervaring met een obfuscator?

SHA1 en MD5 zijn helemaal niet 'makkelijk te kraken'. Een combinatie van SHA1 en MD5 is bovendien net zo veilig als de beste van de twee, niet veiliger. SHA256/SHA512 is sowieso beter dan SHA1 of MD5. Random keys hebben al helemaal niets met hashing te maken, tenzij je het over de salt hebt.

Iemand ervaring met een obfuscator?

In plaats van blind naar obfuscators te vragen, back to the drawingboard: wat heb je echt nodig? Waarom wil je dat mensen de programmacode niet kunnen lezen? Als het is om te voorkomen dat ze het programma kunnen kopieren, dan moet je naar kopieerbeveiligingen en licenseringsoplossingen kijken, niet naar obfuscators. Als jij 10000 potentiele klanten hebt, dan gaat niemand de moeite nemen om de code te decompileren en de beveiliging te kraken. De beveiliging hoeft dan ook slechts minimaal te zijn. Als je klanten bedrijven zijn, dan hoef je er al helemaal niet bang voor te zijn: een bedrijf legt liever $500 neer, dan de tijd en moeite te nemen om je programma illegaal te pakken te krijgen, met alle mogelijke gevolgen van dien.

[ Voor 22% gewijzigd door Confusion op 19-07-2009 11:12 ]

[Verwijderd]

Ja ik bedoelde dus een salt, die je aan het passwoord toevoegd/ of random key dat je aan het passwoord toevoegd, er bestaan al verschillende brute force programmatjes voor md5 encrypties te kraken, kan zelfs al binnen het uur als het een eenvoudig passwoord is, bv enkel letters en zonder hoofdletters

Als je eerst md5 encryptie doet, dan eeen sha1 en sh2 is dat al heel veel moeilijker om brute force te achterhalen, omdat het meer dan 1 soort encryptie is + het wachtwoord is langer geworden en er staan al cijfers in indien dit niet het geval was bij je passwoord

[Confusion]

md5 is geen encryptie en je kraakt een hashcode als md5 niet door een rainbow table uit te rekenen. Sorry, maar je weet niet genoeg van de materie om er een onderbouwde mening over te hebben. Je opmerking over de lengte van het wachtwoord illustreert dat: de lengte van een wachtwoord is niet van belang, enkel de oorspronkelijke hoeveelheid entropie. De sha1 van de sha2 van de md5 van een wachtwoord bevat niet meer entropie dan het oorspronkelijke wachtwoord en is niet veiliger.

Voorbeeld:
Stel dat je een wachtwoord van 1 teken neemt en je staat 36 mogelijke tekens toe. Dan zijn er 36 mogelijke hashes. Ook de sha1 van de sha2 van de md5 levert maar 36 mogelijkheden op. Die heb je binnen 1 milliseconde uitgerekend en binnen een seconde geprobeerd. Dat is dus niet veiliger. QED.

[ Voor 13% gewijzigd door Confusion op 19-07-2009 11:12 ]

[Verwijderd]

Zeker? dus als je nu 5 keer md5 na elkaar toepast of 1 keer komt het dan op hetzelfde neer?

[Zoijar]

Verwijderd schreef op zondag 19 juli 2009 @ 11:14:
Zeker? dus als je nu 5 keer md5 na elkaar toepast of 1 keer komt het dan op hetzelfde neer?

iha wordt het juist minder veilig daardoor.

[H004]

Confusion schreef op zondag 19 juli 2009 @ 10:45:
[...]
De hashing uit de javascript halen is ook bepaald niet moeilijk. Als je het niet verprutst, dan maakt de applicatie er '0d65c1187700c09a20c3c145d16821c6' van en staat dat ook in de database. In dat geval kan de aanvaller die de database te pakken krijgt niet met de hash inloggen. In dat geval biedt het echter ook geen enkele extra bescherming om het wachtwoord al in javascript te hashen. '7576f3a00f6de47b0c72c5baf2d505b0' is, voor wat betreft sniffing, net zo veilig als 'password123'. Als we het over bruteforcing gaan hebben biedt het ook geen enkele toevoeging, omdat een aanvaller ziet dat je de wachtwoorden in javascript hashed en dus gewoon gehashte wachtwoorden in gaat sturen.

Mwaoh, ik snap de strekking van je verhaal wel, maar in feite zeg je, dat je net zo goed plain-text passwords over het lijntje kan versturen, want de hash valt te "dehashen" met rainbow tables etc. En dat ben ik toch echt niet met je eens! Elke extra antihack-barrière is er weer een, uitgaande van het feit (lees: hoop) dat de maker van de applicatie het niet heeft "verprutst".

blaataaps schreef op zondag 19 juli 2009 @ 10:44:
Hoezo is dat wel veiliger?

Omdat het dehashen werkt met rainbowtables en collisions: niet elk password is opgenomen in zo'n tabel. En zolang men sterke passwords kiest is de kans dat het in een rainbowtable staat (hopelijk nog) klein en zal de hacker toch aan de slag moeten gaan met bruteforcen om een collision te vinden. Een extra antihack-barrière dus! Waarom zou je het hackers makkelijker maken dan het al is/schijnt te zijn?

(Uiteraard biedt alléén javascript-hashen van passwords geen enkele veiligheid, maar we bevinden ons hier op GoT, niet op Phpfreakz, hè )

[Voutloos]

H004 schreef op zondag 19 juli 2009 @ 12:12:
[...]

Mwaoh, ik snap de strekking van je verhaal wel, maar in feite zeg je, dat je net zo goed plain-text passwords over het lijntje kan versturen, want de hash valt te "dehashen" met rainbow tables etc. En dat ben ik toch echt niet met je eens! Elke extra antihack-barrière is er weer een, uitgaande van het feit (lees: hoop) dat de maker van de applicatie het niet heeft "verprutst".

Dat is het hele punt dus niet. Laatste poging: De input die de server krijgt zorgt voor de authenticatie. Of die input de letterlijk ingevoerde tekst is, of een hash daarvan maakt niet uit: Het herhalen van de input volstaat.

[Verwijderd]

Hashing algoritmes zorgen voor geen enkele beveiliging voor je eigen applicatie. Het enige wat je daarmee wilt bereiken is dat het oorspronkelijke wachtwoord niet op straat komt te liggen waardoor een kwaadwillend persoon daarmee een andere applicatie kan misbruiken.

Wachtwoorden hashen is eenvoudig en je bewijst de eigenaar van een wachtwoord een grote dienst door het gewoon te doen, geen vragen. Meestal kun je het best gewoon de (uiteraard unieke) loginnaam van de eigenaar als salt gebruiken, je bereikt daarmee dat -naast het feit dat rainbow tables niet zoveel zin meer hebben- een kwaadwillend persoon informatie krijgt over de wachtwoorden. Als je namelijk dezelfde hash gebruikt voor alle wachtwoorden, krijgen twee mensen met hetzelfde wachtwoord exact dezelfde hash. Dat wil je niet. De aanvaller kan heel makkelijk dubbele hashes eruit pikken en die bruteforcen. Als er twee mensen hetzelfde wachtwoord hebben is het meestal een makkelijk wachtwoord. Een aanname de aanvaller die heel veel tijd kan besparen.

Overigens, als je langer dan 7 seconden moet nadenken over het hashen van wachtwoorden, heb je al tijd verspild. Je kunt gerust hashfunctie (loginnaam + wachtwoord) gebruiken, met uiteraard de sterkste functie die je hebt. In de regel mag je hashing algoritmes nooit combineren.

Voutloos schreef op zondag 19 juli 2009 @ 12:20:

Dat is het hele punt dus niet. Laatste poging: De input die de server krijgt zorgt voor de authenticatie. Of die input de letterlijk ingevoerde tekst is, of een hash daarvan maakt niet uit: Het herhalen van de input volstaat.

Dit is een heel ander verhaal, en dit is wél van belang voor de eigen applicatie.

Voor de TS (niet voor Voutloos want die weet dat wel):
Voor het vergelijken van wachtwoorden kun je het best nog een challenge/response gebruiken. Als iemand een inlogpoging moet doen, stuur je een challenge mee, een compleet willekeurig iets. De inloggende gebruiker hasht zijn wachtwoord(hash) met die challenge, en stuurt het resultaat (de response) en de challenge terug. Zo kan iemand geen replay attack uitvoeren met de hash, hij zal het originele wachtwoord moeten bezitten.

[ Voor 25% gewijzigd door Verwijderd op 19-07-2009 12:43 ]

[rapture]

Confusion schreef op zaterdag 18 juli 2009 @ 18:52:
Deze reactie slaat als een tang op een varken. Dat security through obscurity geen goed idee is, is hier niet van toepassing, omdat echte security onmogelijk is.

Die reactie was gericht op iemand die denkt "Als ik de code maar goed genoeg verstop, dan gaan ze de beveiliging niet zien.". Alleen is het code verstoppen niet gemakkelijk en de bytecode/executable moet nog ergens op kunnen draaien. Het verstoppen faalt dan grandioos en principe van Kerckhoff blijft van toepassing.

Je reageert tegen een uitvoeringsprobleem, terwijl het algemeen ontwerp al niet deugt. Er moet maar een ettercap met ARP poisoning in je buurt zitten en snuffelen aan de plaintext-pakketjes.

---

Terug naar de tekentafel is inderdaad nodig. Hij begint eerst helemaal bovenaan met de opdracht te bekijken, voordat hij naar lagere lagen (uitvoeringsproblemen en andere details) afdaalt. "Beveiliging" kan van alles en nog wat zijn. Gaat het om het inloggen in een database en datauitwisseling? Dan richting client-server kijken en pak een cursus over hashing, encryptie, sleutelbeheer,... erbij.

Zonder de opdracht te snappen, kan deze topic niet verder uitgewerkt worden. We zitten nu ongeveer de kleur van de verf van tanks uit te kiezen, maar we weten nog eens niet wat de doctrine van de president is, hoe we naar een bepaalde werelddeel kijken, waar het potentiële oorlogszone ligt, welk mandaat dat we krijgen,...

Uiteraard gaan we dan bij de topicstarter klagen dat het geen goede idee is, hij krijgt zijn uitvoer-orders niet aan ons verkocht. Breng eerst een goed plan en overtuig ons, dan gaan we wel verder kijken naar de uitvoeringsdetails.

Over welke risico's (oa in geld per incident uitgedrukt, faillissement van het bedrijf,...) spreken we en op welk niveau moet er beveiligd worden.

Het zal wel leuk worden als de klanten aan de hand van een aankoopprijslijst weten dat je met bv +40% marge bij de klanten een poot probeert uit te draaien. Dan eisen ze korting, want 20% is ook wel een royale marge en groothandelaars zijn al blij met 10%. Zolang de klanten het niet weten, dan heb je dit probleem niet. Als aankoper kan je verkopers in de grond boren, als je de markt goed kent en weet wanneer ze te dikke marge hebben. Als verkoper wil je je koopwaar nog kwijt geraken en je gaat moeten toegeven. Denk dus niet te licht over de gevolgen en je tegenstanders (iedereen behalve jezelf) proberen allemaal aan jouw marge te knabbelen.

Verwijderd schreef op zondag 19 juli 2009 @ 11:14:
Zeker? dus als je nu 5 keer md5 na elkaar toepast of 1 keer komt het dan op hetzelfde neer?

Als je met 36 mogelijkheden start en je weet dat elke mogelijkheid slechts 1 hash heeft, dan heb je ook slechts 36 hashes. 36 mogelijke hashes nog een keer laten hashen en je weet dat een input door een hashingfunctie slechts 1 output levert, dan heb je weeral 36 mogelijke hashes. Dan mag je het nog meer proberen en hetzelfde verhaaltje. Dan kan je de 36 mogelijkheden door een hoop hashingfuncties jagen en input/output in een tabel neerzetten.

[Zoijar]

rapture schreef op zondag 19 juli 2009 @ 12:53:
Als je met 36 mogelijkheden start en je weet dat elke mogelijkheid slechts 1 hash heeft, dan heb je ook slechts 36 hashes. 36 mogelijke hashes nog een keer laten hashen en je weet dat een input door een hashingfunctie slechts 1 output levert, dan heb je weeral 36 mogelijke hashes. Dan mag je het nog meer proberen en hetzelfde verhaaltje. Dan kan je de 36 mogelijkheden door een hoop hashingfuncties jagen en input/output in een tabel neerzetten.

Behalve dat je vaak start met een groot domein en dat hashed naar een relatief klein bereik (256 bits oid); dat kleine bereik gebruik je bij je 2e keer hashen als domein en de mogelijkheid bestaat dat dat een nog veel kleiner bereik oplevert. Je kan door meerdere keren hashen mogelijk dus je hash bereik verkleinen en zo aanvallen makkelijker maken.

Leuke discussie trouwens, maar weet iemand nou wat de TS precies wil? Ik snap het namelijk niet helemaal, en dat is toch wel een vereisde als je een beveiliging wilt maken. Welk wachtwoord is bij wie bekend, wordt waar ingetikt, gaat waar naar toe, waarom, en wie kan waar bij of zou dat niet mogen?

[H004]

Voutloos schreef op zondag 19 juli 2009 @ 12:20:
[...]
Dat is het hele punt dus niet. Laatste poging: De input die de server krijgt zorgt voor de authenticatie. Of die input de letterlijk ingevoerde tekst is, of een hash daarvan maakt niet uit: Het herhalen van de input volstaat.

Dat was vanaf moment 1 al duidelijk. Ik denk dat de nuance in de eerste post van Confusion in deze subdiscussie niet wordt gezien:

Confusion schreef op zaterdag 18 juli 2009 @ 23:50:
Dat is levert dezelfde discussie op als wanneer weer eens iemand verzint dat het veiliger is om in javascript de md5 van een wachtwoord te nemen en dat te versturen: dat is niet zo, omdat het enige dat van belang is hetgene is dat over het lijntje gaat.

Als je een password open en bloot verstuurt weet de hacker, na sniffen, gebruikersnaam en password en kan bij elke applicatie voortaan inloggen met die set...

Edit: Precies wat Cheatah zegt dus!

[ Voor 6% gewijzigd door H004 op 19-07-2009 13:07 . Reden: Kleine wijziging ]

[Gerco]

Om even op het probleem van de TS terug te komen... volgens mij is er het volgende aan de hand:

[ul]
• Gebruiker vult user/password in in de applicatie
• Applicatie gebruikt eigen credentials om met de database te verbinden.


De kern van het probleem is dus niet dat je je broncode wilt verbergen, maar dat je het database password wilt verbergen. Dit kun je niet doen wanneer je dat wachtwoord op welke manier dan ook beschikbaar stelt aan de gebruiker (in je app zetten, hoe encrypted ook, is beschikbaar stellen). Hierop kan ik twee oplossingen bedenken, niet allebei even handig...

[ul]
• Gebruik de username en password van de *gebruiker* om op de database in te loggen en deel rechten uit aan die gebruiker zodat hij/zij geen vervelende dingen kan uithalen.
• Verbind niet direct aan de database maar aan een tussenlaag. Deze geef je alleen de credentials van de gebruiker mee en niet het database password. Die tussenlaag kan best zijn eigen credentials gebruiken om de database te contacteren, mits deze natuurlijk *niet* op een machine draait waar de gebruiker toegang toe heeft.

[ Voor 20% gewijzigd door Gerco op 19-07-2009 13:41 ]

[Janoz]

H004 schreef op zondag 19 juli 2009 @ 12:12:
[...]

Mwaoh, ik snap de strekking van je verhaal wel, maar in feite zeg je, dat je net zo goed plain-text passwords over het lijntje kan versturen, want de hash valt te "dehashen" met rainbow tables etc.

Nee, dat zegt hij niet. Het hele punt ging over het verplaatsen van de actie van het hashen van de server naar de client. Hij geeft aan dat je, wanneer je enkel het hash proces naar de client verplaats, het net zo onveilig is als gewoon maar met alles met plaintext te werken.

En dat ben ik toch echt niet met je eens! Elke extra antihack-barrière is er weer een, uitgaande van het feit (lees: hoop) dat de maker van de applicatie het niet heeft "verprutst".

Omdat het dehashen werkt met rainbowtables en collisions: niet elk password is opgenomen in zo'n tabel. En zolang men sterke passwords kiest is de kans dat het in een rainbowtable staat (hopelijk nog) klein en zal de hacker toch aan de slag moeten gaan met bruteforcen om een collision te vinden. Een extra antihack-barrière dus! Waarom zou je het hackers makkelijker maken dan het al is/schijnt te zijn?

Soms zorgt het stapelen van hack pogingen er juist alleen maar voor dat het makkelijker wordt. Een MD5 hash is (wat ze in de wiskunde noemen) injectief. Dat betekend dat een groot bereik op een kleiner bereik afgebeeld wordt en dat er dus meerdere inputs zijn die dezelfde output opleveren. Door nogmaals een MD5 over het resultaat te halen gebruik je een input met een beperkt bereik en zal deze dus afgebeeld worden op een nog kleiner bereik. Hoe vaker je MD5 over je string gooit, hoe makkelijker het wordt om een collission te vinden aangezien het uiteindelijke bereik steeds kleiner wordt.

(Uiteraard biedt alléén javascript-hashen van passwords geen enkele veiligheid, maar we bevinden ons hier op GoT, niet op Phpfreakz, hè )

Daar ging het hier juist wel om , en jij was degene die het liep te verdedigen .

[SKiLLa]

Games gebruiken geen "obfuscators" maar fully-fledged protection wrappers met meerdere lage encryptie, integriteit-checks, anti-debug opties en meestal polymorphing-code; een wereld van verschil met "het mangelen van strings en variabele-/member-namen" wat de meeste Java/.Net obfuscators doen ...

Daarnaast zijn veel database connecties tegenwoordig zelf wel braaf versleuteld met b.v. SSL, dan heb je veel meer aan een debugger of tracelogs dan aan een netwerk-sniffer ....

MD5 hashing is trouwens niet bedoeld voor cryptografische-toepassingen, maar voor data integrity checks (ala CRC controle); gebruik dus gewoon SHA . Of dit SHA-1 of SHA-2 is, maakt voor jou toepassing niet echt uit, we hebben het uiteindelijk niet over de het root-wachtwoord van de Nederlands Bank SHA-2 is wel stukken meer "future proof", maar de ketting is zo sterk als de zwakste schakel en die zwakste schakel zal SHA waarschijnlijk niet zijn ....

Houd het KISS, maar volg wel braaf de cryptografie-guidelines zoals hashing met salt & pepper en eventueel met anti-replay attacks (timestamps, challenge-response, etc.), anders is het bij voorbaat al verspilde moeite.

PS: Als je SHA gebruikt waar MD5 afdoende was, is het geen probleem, maar omgekeerd, als je een keer "per ongeluk" MD5 gebruikt waar het SHA had moeten zijn, dan heb je wel een lek ... Dus als je niet heel precies weet wat je doet, gewoon altijd de veilige optie kiezen

[ Voor 10% gewijzigd door SKiLLa op 19-07-2009 16:14 ]

[Zoijar]

SKiLLa schreef op zondag 19 juli 2009 @ 16:09:
MD5 hashing is trouwens niet bedoeld voor cryptografische-toepassingen, maar voor data integrity checks (ala CRC controle);

Dat is niet waar. Uit de RFC (1321):

It is conjectured that it is computationally infeasible to produce
two messages having the same message digest, or to produce any
message having a given prespecified target message digest. The MD5
algorithm is intended for digital signature applications, where a
large file must be "compressed" in a secure manner before being
encrypted with a private (secret) key under a public-key cryptosystem
such as RSA.

i.e. MD5 is een cryptographic, "secure" hash function, daar een CRC totaal niet secure is.

[ Voor 6% gewijzigd door Zoijar op 19-07-2009 16:17 ]

[Alex)]

De makkelijkste oplossing voor dit probleem is, zoals eerder al aangehaald, een webservice.

I.p.v. dat een client-app rechtstreeks met een database verbindt (iets waar ik sowieso al m'n twijfels bij heb als het bijvoorbeeld over internet moet gaan) verbindt het met een tussenlaag die authenticatie en security checks uitvoert. De tussenlaag voert daarna de acties uit in de database (die niet van buitenaf toegankelijk is) en geeft de resultaten in een formaat naar keuze terug (bijvoorbeeld XML).

De webservice zelf kun je natuurlijk op een SSL-secured host laten draaien, dat maakt het risico voor password-sniffing ook een stuk kleiner.

Client-app -> https://www.mijn-web-si.te/webservice.asmx -> Database
Client-app <- https://www.mijn-web-si.te/webservice.asmx <- Database

Dat is vele malen veiliger dan het databasepassword encrypted meesturen in je applicatie - dat moet toch eerst gedecrypt worden voor het gebruikt kan worden en juist dan is het al uit te lezen.

[SKiLLa]

Zoijar schreef op zondag 19 juli 2009 @ 16:14:
[...]
Dat is niet waar. Uit de RFC (1321):
[...]

i.e. MD5 is een cryptographic, "secure" hash function, daar een CRC totaal niet secure is.

De tekst heeft het over "integriteitscontrole" met MD5 en pas later over "encryptie" met RSA
M.a.w, verkeerde interpretatie van de tekst; MD5 is helemaal geen "secure" hash function; verschillende input kan tot dezelfde hash waarde leiden. En ook het "computationally infeasible" is allang achterhaalt; zie hier het tegendeel bewezen: Vervalst CA certificaat middels MD5 collisons.

Verder zeg ik dat MD5 toepasbaar is waar CRC toepasbaar is, niet dat CRC cryptografisch verantwoord is ...

[Zoijar]

SKiLLa schreef op zondag 19 juli 2009 @ 16:48:
De tekst heeft het over "integriteitscontrole" met MD5 en pas later over "encryptie" met RSA
M.a.w, verkeerde interpretatie van de tekst; MD5 is helemaal geen "secure" hash function; verschillende input kan tot dezelfde hash waarde leiden.

Sorry, maar MD5 is ontworpen als secure hash function. Dat betekent dat het moeilijk is om gegeven een hash output een input te construeren die dezelfde output levert. Verschillende input kan altijd tot dezelfde hash output leiden; dat volgt uit het laatjes principe en het feit dat de input ruimte groter is dan de output ruimte.

En ook het "computationally infeasible" is allang achterhaalt; zie hier het tegendeel bewezen: Vervalst CA certificaat middels MD5 collisons.

Vandaar dat ik secure tussen aanhalingstekens schreef; dat soort uitlatingen is waar die dingen voor zijn

(Ik werk bij het CWI, uiteraard ken ik dat artikel )

Verder zeg ik dat MD5 toepasbaar is waar CRC toepasbaar is, niet dat CRC cryptografisch verantwoord is ...

CRC en MD5 zijn ontworpen met verschillende doelen. MD5 moet een hash opleveren die moeilijk na te maken is met andere input, CRC streeft dat doel helemaal niet na. CRC is een error detecting code en is juist ontworpen om error detectie te maximaliseren, maar niet om het moeilijk te maken om hash collisions moedwillig te construeren.

[SKiLLa]

Gelukkig, dan zijn we het "eens"
Dat MD5 als "secure" hash function ontworpen is, wil ik niet ontkennen, maar het is wel ingehaald door de tijd.

[Zoijar]

SKiLLa schreef op zondag 19 juli 2009 @ 17:31:
Gelukkig, dan zijn we het "eens"
Dat MD5 als "secure" hash function ontworpen is, wil ik niet ontkennen, maar het is wel ingehaald door de tijd.

Het ging erom dat jouw uitspraak:

SKiLLa schreef op zondag 19 juli 2009 @ 16:09:
MD5 hashing is trouwens niet bedoeld voor cryptografische-toepassingen, maar voor data integrity checks (ala CRC controle);

niet waar is MD5 is daar wel degelijk voor bedoeld en juist helemaal niet voor data integrity tests ala CRC, i.e. als error detecting code.

[Confusion]

H004 schreef op zondag 19 juli 2009 @ 13:02:
Als je een password open en bloot verstuurt weet de hacker, na sniffen, gebruikersnaam en password en kan bij elke applicatie voortaan inloggen met die set...

En als elke site het wachtwoord in javascript hashed, dan kan je nog steeds overal inloggen, met gebruikersnaam + die gesnifte hash. Dat wachtwoord moet gewoon plaintext over een SSL lijn.

[Verwijderd]

Ok, we zijn eventjes uitgelopen van het feitelijke onderwerp:
Nog even voor alle duidelijkheid: Ik heb een key dat meegezonden wordt met username en password, waar bij de server controleert of de key hetzelfde is als van de client, zo ja, geen probleem, zo nee, hack poging.
Wat ik dus eigenlijk wou, is dat je verhinderd dat decompilatie mogelijk is, maar dat is dus niet mogelijk (afgeleid uit dit topic). Wil dit dan zeggen, als ik er niets aan doet, dat de gebruiker door decompilatie opnieuw een build kan maken terwijl hij de code nog wat aanpast?


En ja, de hash voor het passwoord van de user is enkel terbeveiliging als iemand de database hackt, of dat hij de verbinden naar de database aftapt en zoe de verzende variables kan zien..., zo is het password toch deels beschermd...

[ Voor 17% gewijzigd door Verwijderd op 19-07-2009 19:19 ]

[Gerco]

Verwijderd schreef op zondag 19 juli 2009 @ 19:18:
Wil dit dan zeggen, als ik er niets aan doet, dat de gebruiker door decompilatie opnieuw een build kan maken terwijl hij de code nog wat aanpast?

Ja. Als je er wel wat aan doet overigens ook, het is niet mogelijk om het de gebruiker *on* mogelijk te maken die key te achterhalen. De enige manier om hier 100% zeker van te zijn is zo'n key niet gebruiken.

Oftewel, meld de gebruiker aan bij je tussenlaag met zijn eigen username/password en laat die tussenlaag de db aanspreken. Niet de gebruiker direct in de db laten, maar alles via je tussenlaag laten lopen. Dan maakt het ook niet meer uit of de gebruiker jouw app gebruikt of niet, want de beveiliging zit daar niet in.

Zelfs als ze een eigen app schrijven om je systeem te misbruiken dan kan dat niet, want je tussenlaag zal de beveiliging nog steeds hetzelfde uitvoeren als wanneer je eigen app eraan connect.

[ Voor 3% gewijzigd door Gerco op 19-07-2009 19:38 ]

[Verwijderd]

Dan heb ik helemaal geen beveiliging meer...
Kga dan toch proberen om het opnieuw maken van een build met eigen aanpassingen te verhinderen...

[Gerco]

Verwijderd schreef op zondag 19 juli 2009 @ 19:39:
Dan heb ik helemaal geen beveiliging meer...

Als je beveiliging enkel afhangt van het niet kunnen decompilen van je executable had je om te beginnen al geen beveiliging die de naam waard is.

Kga dan toch proberen om het opnieuw maken van een build met eigen aanpassingen te verhinderen...

Als je je beveiliging client side implementeert kun je beter je tijd ergens anders aan gaan besteden. Lastig maken kan, onmogelijk maken niet.

Je kan bijvoorbeeld die key encrypten (xor) met een key die je op compile time kiest (of laat afhangen van de PE header van je .exe ofzo). Dan maak je het lastig voor de casual cracker. Iemand met meer dan 10 minuten geduld prikt er zo doorheen natuurlijk.

[ Voor 19% gewijzigd door Gerco op 19-07-2009 19:45 ]

[BCC]

Zoals Gerco net zegt: dat is niet mogelijk en dat verhindert een gebruiker nog steeds niet om jouw database aan te spreken met een eigen gebouwd programma.

Maar je hebt ook nog steeds niet uitgelegd wat je precies wilt doen.
Ik denk dat je een app hebt die verbinding maakt met een database.

Als je echt direct gebruik wilt maken van een online database, maak dan gebruik van de gebruikers rechten/rollen/mogelijkheden die die database engine je biedt.
Op elke database kun je een username/password aanmaken met beperkte rechten welke je netjes naar je gebruikern kan sturen. Deze gegevens voert de gebruiker de eerste keer in de applicatie in en tada: verbinding.

[FTL]

Mocht je nog een gratis, goed functionerende obfuscator zoeken voor .NET kan ik je EazFuscator aanraden.
Deze kan je debugging en andere stacktrace informatie ook versleuteld laten opslaan in je assembly zodat wanneer je debug info krijgt je deze nog kan decoden voor je betere debugging werk.

http://www.foss.kharkov.u...cator/dotnet/Default.aspx

[Confusion]

Verwijderd schreef op zondag 19 juli 2009 @ 19:39:
Kga dan toch proberen om het opnieuw maken van een build met eigen aanpassingen te verhinderen...

Voor wie ben je eigenlijk bang? Wie denk je dat de moeite gaat nemen om jouw applicatie te hacken? En waarom is het zo erg als iemand probeert in te loggen? Op alle servers in de wereld zijn iedere dag duizenden inlogpogingen met ongeldige credentials. Daar ligt niemand van wakker.

[Verwijderd]

Nee, dat niet, maar ik sla bepaalde data op, en zo zouden ze kunnen veranderen...

http://www.foss.kharkov.u...cator/dotnet/Default.aspx
Iemand ervaring met dit programma of met 'skator' (obfuscator in het begin van dit topic)
http://rustemsoft.com/SkaterLight.htm

Welkeen zou jij nemen en waarom?

[ Voor 66% gewijzigd door Verwijderd op 19-07-2009 20:15 ]

[BCC]

Verwijderd schreef op zondag 19 juli 2009 @ 20:07:
Nee, dat niet, maar ik sla bepaalde data op, en zo zouden ze kunnen veranderen...

Dan heb je dus een heel groot probleem in het originele design wat je moet oplossen.

[Verwijderd]

Ik denk dat dat onmogelijk is..., hoe zou je anders data kunnen opslaan die veranderen in het programma?
Stel: Je wilt opslaan hoeveel keer op een knop wordt gedrukt, dus je telt dat op de form. Dan bij form closing verstuur je het naar de database, dan is er toch niets dat je kunt veranderen zodat men het niet kan veranderen? of wel?

[Janoz]

ZOu je eens iets meer kunnen vertellen over de architectuur van je huidige ontwerp? Ik heb namelijk een beetje het idee dat het erg lijkt op het volgende:

+---------+  +---------+
| CLIENT  |  | SERVER  |
+---------+  +---------+
|         |  |         |
| +-----+ |  | +----+  |
| | APP |-+--+-| DB |  |
| +-----+ |  | +----+  |
|         |  |         |
+---------+  +---------+

Je applicatie op de client verbind dus rechtstreeks met de database op de server. Hoe komt die verbinding tot stand? Heb je blijkbaar database credentials ergens in je applicatie verstopt zodat je kunt verbinden?

In dat geval is elke milliseconde die je ook maar besteed aan clientside security verspilde moeite en zonde van die milliseconde. Hoeveel obfuscators je ook los laat, je database wachtwoord is altijd wel te achterhalen (al laat je een debugger meelopen). Vervolgens start ik mijn database frontend op (toad, squirel of wat dan ook) en zet ik netjes mijn eigen tellertje weer op nul (among other things...)

[Verwijderd]

voorlopig wel, maar ben al bezig met een tussenstap aan het uitdokteren, mss een server side app dat runnt, en de bevelen ontvangt en die dan connectie maakt op de database...

dat is dan al beter...., nu wil ik juist nog beschermen dat ze (zie vorig voorbeeld met de button) hun button clicks niet hoger kunnen plaatsten door decompilatie, dan command toevoegen net voor de verbinding en opnieuw bulden zodat er bv 100 clicks meer worden toegevoed en verzonden

[rapture]

code:

+---------+  +---------+  +----------+
| CLIENT  |  | SERVER  |  | DATABASE |
+---------+  +---------+  +----------+
|         |  |         |  |          |
| +-----+ |  | +-----+ |  | +----+   |
| | APP |-+--+-| SRV |-+--+-| DB |   |
| +-----+ |  | +-----+ |  | +----+   |
|         |  |         |  |          |
+---------+  +---------+  +----------+

Je laat de serverapplicatie alles uitvoeren en je client is slechts een doorgeefluik.

Als je een button in de client indrukt, dan gaat een bevel naar de server. De server voert van alles en nog wat uit, daarna een integer in de database met +1 verhogen om de buttonclick te onthouden.

Een andere client zou dan eerst gebruikersnaam/wachtwoord moeten kennen. De server wijsmaken om de andere client te vertrouwen. Als de andere client kan inloggen, dan wordt nog altijd een bevel geven en de server verhoogt een integer in de database met +1. Er is geen directe toegang tot de integer in de database.

[Verwijderd]

Je kan dan wel een lus maken op de client app, zodat hij constant het signaal doorstuurt bij de serverapp om +1 te doen

[BCC]

Ja, maar ik kan ook een tooltje schrijven dat elke seconde op pixel x,y van het scherm "klikt", waar toevallig jouw knop staat.

Daarnaast ben je in elke bovengenoemde situatie vatbaar voor een reply-attack.

[ Voor 24% gewijzigd door BCC op 19-07-2009 21:11 ]

[Verwijderd]

Het is ook maar een voorbeeld...

[rapture]

Je neemt aan dat je gebruikers/klanten het boeltje probeert te belazeren door bv 100 buttonclicks toe te voegen? Wat is het doel van de clicks bij te houden? Blijkbaar is dat klikken lucratief.

Zonder een lus kunnen ze even goed een hardwarematige oplossing verzinnen of ze zetten wat gold farming Chinezen aan het werk. In de server kan je allerlei beperkingen inbouwen zoals we niet meerdere keren op dezelfde poll kunnen stemmen.

[ Voor 3% gewijzigd door rapture op 19-07-2009 21:13 ]

[Verwijderd]

zoals ik het al zij is het klikken op een knop maar een voorbeeld,

ok, dus dat server app bouwen is blijkbaar de oplossing, behalve dat ik dan heeel min programma moet herschrijven om dat de meeste dingen clientside gebeuren...
En daar heb ik dus ook geen zin in...

[rapture]

Daarom wordt je in bv HBO-opleidingen met projectdossiers en andere papierwerk doodgeslagen voordat je aan de code begint. Anders heb je dagen/weken gecodeerd en iemand komt langs om al jouw werk met een pennentrek te vernietigen.

[Verwijderd]

...

Dus is een obfuscator toch handig om de niewschierigen te omzeilen...


Dus welkeen van de 2?

[ Voor 15% gewijzigd door Verwijderd op 19-07-2009 21:23 ]

[Alex)]

De beste aanpak (lijkt mij) is om alle logica op je server te laten gebeuren (waar ook je database is) zodat je een "domme" client-app hebt (met offline data wellicht?). Je zou de dingen in je client-app kunnen obfuscaten zodat de "logica" die je daar hebt (niet veel, als je het goed aanpakt) enigszins beschermd wordt.

Validaties e.d. zul je moeten leggen waar de data wordt aangesproken. Rechtstreeks vanuit de client, dan valideer je op de client. Is er een tussenlaag (webservice bijvoorbeeld) dan leg je daar de validaties.

[rapture]

Zijn zoektocht naar een obfuscator is ontstaan door een verkeerd ontwerp. Overstap naar een geschikter ontwerp zorgt ervoor dat je huidige code weg kan gooien en een obfuscator is niet meer nodig.

Dan heb je een voorbeeld van een ontwerpeis "Wat als ze de buttonclicks ophogen? Hoe gaan we onze klanten die netjes ingelogd zijn, tegenhouden om massaal buttonclicks op te drijven?". Daarvoor ga je een niveau hoger moeten kijken, de business dat het project moet representeren. Als je klanten 10 eurocent per klik krijgen, dan willen ze wel wat meer clicks maken voor geld. Als de overeenkomst tussen het bedrijf en de klanten zegt dat er maximaal 1 klik per dag geregistreerd wordt, dan beginnen ze niet eens aan het klikken. De server legt een beperking op de registratie van het klikken.

Veel zaken kan je in hogere niveau's opvangen. Begin bovenaan en daal rustig af richting klassen/protocol opstellen en het coderen.

[BCC]

Nou heb ik geen glazen bol, maar per gebruiker een database user aanmaken met zeer beperkte rechten lost je probleem niet op?

[Soultaker]

Confusion schreef op zondag 19 juli 2009 @ 19:17:
En als elke site het wachtwoord in javascript hashed, dan kan je nog steeds overal inloggen, met gebruikersnaam + die gesnifte hash. Dat wachtwoord moet gewoon plaintext over een SSL lijn.

SSL is goed, natuurlijk, maar je kunt ook voor een challenge/response protocol kiezen, bijvoorbeeld:
• de server kiest voor elke gebruiker een random salt, en slaat hash(salt+pass) op
• bij inloggen presenteert de server een pagina met daarbij de gebruikerspecifieke salt en een random nonce
• om in te loggen stuurt de client hash(hash(salt+pass)+nonce) naar de server.
De server kan nu verifiëren dat de client inderdaad over het oorspronkelijke wachtwoord beschikt, maar dat wachtwoord wordt niet verstuurd en ook nergens (plain-text) opgeslagen. Deze uitwisseling kan desgewenst over een onbeveiligde verbinding plaatsvinden.

SSL is trouwens nog steeds wel een goed idee, omdat je met onbeveiligde HTTP (en TCP) verbindingen nog het probleem hebt dat ná je authenticatie je sessie nog steeds niet beveiligt is tegen sniffing/spoofing, maar het is aanzienlijk beter dan niets.

Overigens gaat op Tweakers.net de login gewoon over HTTP, maar er is wel een optie om het wachtwoord te versleutelen bij het inloggen... iemand enig idee hoe die optie werkt?

[SKiLLa]

Zoijar schreef op zondag 19 juli 2009 @ 17:35:
[...]
MD5 is daar wel degelijk voor bedoeld en juist helemaal niet voor data integrity tests ala CRC, i.e. als error detecting code.

Hoe kun je in hemelsnaam zeggen dat een message digest (= hash) niet bedoeld is voor integriteits validatie ?
Je quote zelf het RFC fragment waar het in staat. De meerwaarde van MD5 t.o.v. CRC (error detecting only) was nou juist die integriteits-controle (bescherming tegen moedwillige manipulatie; "tampering"). Daarom wordt/werd het zo vaak voor message-/file-validatie of als digital-signature gebruikt. En juist die toepassing is niet "veilig" meer.

[Confusion]

Soultaker schreef op zondag 19 juli 2009 @ 22:27:
SSL is goed, natuurlijk, maar je kunt ook voor een challenge/response protocol kiezen, bijvoorbeeld:
• de server kiest voor elke gebruiker een random salt, en slaat hash(salt+pass) op
• bij inloggen presenteert de server een pagina met daarbij de gebruikerspecifieke salt en een random nonce
• om in te loggen stuurt de client hash(hash(salt+pass)+nonce) naar de server.
De server kan nu verifiëren dat de client inderdaad over het oorspronkelijke wachtwoord beschikt, maar dat wachtwoord wordt niet verstuurd en ook nergens (plain-text) opgeslagen. Deze uitwisseling kan desgewenst over een onbeveiligde verbinding plaatsvinden.

In principe: +1, omdat je op die manier zorgt dat wat over het lijntje gaat slechts eenmalig werkt en niet 'het' wachtwoord weggeeft, maar het probleem met deze aanpak is: kan je er op vertrouwen dat het goed geimplementeerd wordt? Er zijn veel manieren om er een fout in te maken, door gebrek aan begrip of door gewoon een bug in je code. Dan staat de security weer op het spel. Daarom liever SSL dan dit en als je SSL gebruikt, voegt dit niets meer toe.

Of je na een SSL inlogpagina overschakelt op gewone HTTP hangt af van de applicatie. Hoe groot is de kans op een session hijack en hoe ernstig zijn de gevolgen? Ik denk dat dat vaak wel meevalt. Bovendien is de overhead van SSL vaak veel kleiner dan mensen denken. Processorkracht is er genoeg.

[ Voor 3% gewijzigd door Confusion op 20-07-2009 07:26 ]

[mphilipp]

Dus jij maakt hede ten dage een closed source programma? Dat mag toch helemaal niet meer?

[Confusion]

SKiLLa schreef op zondag 19 juli 2009 @ 23:49:
[...]
Hoe kun je in hemelsnaam zeggen dat een message digest (= hash) niet bedoeld is voor integriteits validatie ?

Omdat jullie langs elkaar heenpraten. CRC is helemaal geen message digest, dus dat heeft de discussie vanaf het begin vertroebeld. Zoijar denkt waarschijnlijk aan een HMAC en dat is MD5 op zichzelf niet.

[AtleX]

mphilipp schreef op maandag 20 juli 2009 @ 07:31:
Dus jij maakt hede ten dage een closed source programma? Dat mag toch helemaal niet meer?

Leg eens uit

[Voutloos]

Is je sarcasme-meter stuk?

[AtleX]

Ik weet dat er geen 'verbod' is als je dat bedoelt, maar ik vraag me af waar zijn reactie op slaat.

[VisionMaster]

Verwijderd schreef op zondag 19 juli 2009 @ 21:22:
...

Dus is een obfuscator toch handig om de niewschierigen te omzeilen...


Dus welkeen van de 2?

Is het kwartje nog niet gevallen dat de vraag om een obfuscator doelloos is en de plank misslaat? Je design zit niet goed in elkaar. Niet alle randvoorwaarden zijn uitgedacht, maar het halve programma is er al...

Trouwens, ik snap een ander punt ook niet dat was langs gekomen. De client-side integriteitscontroles zijn even goed handig om in een server te implementeren. Dus de routines zullen allemaal behouden moeten blijven. Dus wat dat betreft heb je al een halve server voor handen.

[chime]

Zoals VisionMaster zegt: de beveiliging afhandelen aan de kant van de client is geen goed idee.

Zelfs al zou je die nog zodaning kunnen obfuscaten, dan nog is het geen 100% veilige oplossing.
Want als een hacker een connectie kan monitoren en zien welke key naar de server wordt gestuurd, kan hij alsnog op die manier toegang tot de database krijgen. (Ik geef toe, het is al wat moeilijk, maar perfect doenbaar)

Anderzijds, beveiliging op de client => brute force hacken wordt zo ook veel gemakkelijker (gewoon paswoorden genereren en door de client jagen)
Bij afhandeling aan de server kant kan je na x-pogingen de gebruiker gewoon uitschakelen.

[Verwijderd]

Ja heb ik ondertussen ook door, maar het probleem is dat ik de tijd niet heb om heel mijn programma te herprogrogrammeren ... zodat alles server side verwerkt wordt... + nog de server app te programmeren ook...

[Zoijar]

SKiLLa schreef op zondag 19 juli 2009 @ 23:49:
Hoe kun je in hemelsnaam zeggen dat een message digest (= hash) niet bedoeld is voor integriteits validatie ?
Je quote zelf het RFC fragment waar het in staat. De meerwaarde van MD5 t.o.v. CRC (error detecting only) was nou juist die integriteits-controle (bescherming tegen moedwillige manipulatie; "tampering"). Daarom wordt/werd het zo vaak voor message-/file-validatie of als digital-signature gebruikt. En juist die toepassing is niet "veilig" meer.

We praten idd een beetje langs elkaar heen. Ik reageer alleen op twee dingen die jij stelde:
- MD5 is niet bedoeld voor cryptografische toepassingen
- MD5 is wel bedoeld voor data integrity checks ala CRC

Ik ga ervan uit dat data integrity checks ala CRC error detecting codes zijn, want dat is wat een CRC is. Aan de andere kant heb je cryptographic hashes, wat MD5 is -- kraakbaar of niet, dat is waar het voor ontworpen en bedoeld is.

error detecting codes (CRC):
- lage overhead aan checksum bits
- goed in het ontdekken van random fouten
- error model en aantoonbare eigenschappen mbt het ontdekken van typen random fouten
- Niet veilig voor tampering

cryptographic hash (MD5):
- hoge overhead aan extra bits
- omdat je zoveel bits gebruikt detect je de meeste random errors wel, hopelijk.
- geen error model, en voor zover ik weet geen algemeen bekende eigenschappen mbt error detection.
- "veilig" voor tampering, althans dat was het oorspronkelijke doel

Ik zie niet hoe je kan zeggen dat een cryptographic hash niet bedoeld is voor cryptografische toepassingen, en verder is MD5 suboptimaal als pure error detection voor random errors; je kan het er voor gebruiken, maar het is er niet voor bedoeld.

Ik snap overigens wel wat je zegt: omdat MD5 nu kraakbaar is kan je het eigenlijk alleen nog voor error detection gebruiken, want het is geen cryptographic hash meer.
(Ik zal wel aan het zeuren zijn, maar ik had niet verwacht dat hier zo'n discussie over zou ontstaan.)

[ Voor 6% gewijzigd door Zoijar op 20-07-2009 11:54 ]

[Janoz]

Verwijderd schreef op maandag 20 juli 2009 @ 11:32:
Ja heb ik ondertussen ook door, maar het probleem is dat ik de tijd niet heb om heel mijn programma te herprogrogrammeren ... zodat alles server side verwerkt wordt... + nog de server app te programmeren ook...

Tja, doe dan maar een korte risico analyse. Hoeveel kost het je wanneer je security faalt en vergelijk dat met hoeveel het je kost om de architectuur fouten uit je software te halen.

Neem bij die risico analyse trouwens wel mee dat het op dit moment technisch mogelijk is om vanaf de gehele wereld in te loggen op je database met een gebruiker die ook rechten heeft om data aan te passen, nog los van hoever je dat verstopt in je client applicatie.

[ Voor 21% gewijzigd door Janoz op 20-07-2009 11:46 ]

[igmar]

Verwijderd schreef op zaterdag 18 juli 2009 @ 16:59:

Wel, ik gebruik al hash encryptie voor mijn password:
Eventjes duidelijker zijn wat mijn programma precies doet:
De gebruiker moet inloggen met een username en password. Dan maakt het programma connectie met een database waarbij de key die meegezonden wordt moet kloppen anders is er een 'hack poging', soort beveiliging van de connectie, dus als je nu de programma kunt decompilen kun je zo ook die key vinden, en zo een succesvolle 'hackpoging' doen omdat de key klopt

En wat verhinderd mij om zoiets als tcpdump te gaan gebruiken ? Met alle respect, dit soort 'beveiligingen' werken gewoonweg niet.

[Pathogen]

Verwijderd schreef op zaterdag 18 juli 2009 @ 16:59:
Qt designer heb ik al uitgetest, maar vond het niet zo goed..., het is enkel freeware voor non commerical edition

[...]


Wel, ik gebruik al hash encryptie voor mijn password:
Eventjes duidelijker zijn wat mijn programma precies doet:
De gebruiker moet inloggen met een username en password. Dan maakt het programma connectie met een database waarbij de key die meegezonden wordt moet kloppen anders is er een 'hack poging', soort beveiliging van de connectie, dus als je nu de programma kunt decompilen kun je zo ook die key vinden, en zo een succesvolle 'hackpoging' doen omdat de key klopt

Waarom leg je de security niet op DB niveau?

Programma vraagt om username en password, probeert daarmee een connectie naar de DB te maken.
DB kent user en password klopt? Niks aan het handje.
DB kent user/pass combinatie niet? Dag dag verbinding!

Bijkomend voordeel is dat je de user/password combinaties zelf in de DB kan beheren.

[Janoz]

Thrackan schreef op maandag 20 juli 2009 @ 13:41:
[...]


Waarom leg je de security niet op DB niveau?

Programma vraagt om username en password, probeert daarmee een connectie naar de DB te maken.
DB kent user en password klopt? Niks aan het handje.
DB kent user/pass combinatie niet? Dag dag verbinding!

Bijkomend voordeel is dat je de user/password combinaties zelf in de DB kan beheren.

Nadeel is dat je dan enkel de toegang beveiligd hebt. Welke actie de gebruiker vervolgens in de database uit kan halen is vervolgens gelijk aan wat de clientside applicatie kan, zonder de in de applicatie ingebouwde restricties. Heb je update rechten op de click tabel dan kun je daar keurig een update clicktabel set clicks = clicks + MAX-INT van maken.

[Pathogen]

Janoz schreef op maandag 20 juli 2009 @ 13:46:
[...]

Nadeel is dat je dan enkel de toegang beveiligd hebt. Welke actie de gebruiker vervolgens in de database uit kan halen is vervolgens gelijk aan wat de clientside applicatie kan, zonder de in de applicatie ingebouwde restricties. Heb je update rechten op de click tabel dan kun je daar keurig een update clicktabel set clicks = clicks + MAX-INT van maken.

Ook dat is best in te perken op DB niveau.

Geen idee of het een "goede" oplossing is, maar wij maken hier gebruik van programma/modulerechten in de database, plus nog enkele menu items en windows die alleen bruikbaar zijn als ze aan worden gezet in de tabel met securities, per user.
Het inperken van ongewenste acties ligt wat mij betreft dan weer aan de applicatiekant. Als je gezellig een invoervakje hebt waar je SQL in kan inserten ben je als applicatiedevver niet slim bezig.

Maar goed, ik ben niet al te paranoide op dit gebied aangezien alles hier intern draait. In openbare applicaties zal het een stuk nuttiger zijn om alles dicht te timmeren, hier staan de verbindingsgegevens voor de database gewoon in een .ini file (niet de credentials uiteraard, die worden via Domain en databaseservers geregeld).

[Janoz]

Thrackan schreef op maandag 20 juli 2009 @ 14:04:
[...]


Ook dat is best in te perken op DB niveau.

Geen idee of het een "goede" oplossing is, maar wij maken hier gebruik van programma/modulerechten in de database, plus nog enkele menu items en windows die alleen bruikbaar zijn als ze aan worden gezet in de tabel met securities, per user.

Maar jullie werken waarschijnlijk met trusted clients. Clients waarop de gebruiker geen administrator is en jullie wel. Dat is hier niet het geval.

Het inperken van ongewenste acties ligt wat mij betreft dan weer aan de applicatiekant. Als je gezellig een invoervakje hebt waar je SQL in kan inserten ben je als applicatiedevver niet slim bezig.

Het hele issue hier is dat de applicatie in een untrusted omgeving draait. In de applicatie geimplementeerde beperkingen zijn een wassen neus. Je hoeft helemaal geen invoervakje voor SQL in je applicatie in te bouwen. Je levert middels de applicatie eigenlijk alle gegevens aan de gebruiker om gewoon zelf een applicatie met SQL invoervakje te maken.

[chime]

Thrackan schreef op maandag 20 juli 2009 @ 14:04:
[...]
Het inperken van ongewenste acties ligt wat mij betreft dan weer aan de applicatiekant. Als je gezellig een invoervakje hebt waar je SQL in kan inserten ben je als applicatiedevver niet slim bezig.

Elke beperking aan applicatiekant (client dus) kan omzeild worden.
De server gaat daar altijd nog op moeten controleren.

Beperkingen aan de applicatiekant doe je omwille van de volgende redenen:
- gebruiksgemak
- performantie
Het is namenlijk niet gebruiksvriendelijk/efficiënt om de gebruiker zomaar wat te laten ingeven dat dan door de server gevalideerd moet worden (request - response neemt veel tijd in beslag)

Want iemand met slechte bedoelingen kan zich altijd gaan voordoen als "client"

[ Voor 5% gewijzigd door chime op 20-07-2009 15:44 ]

[Verwijderd]

Hoe dan ook ga ik het beveiligen met een obfuscator en deels mijn programma code herschrijven tot dat het een beetje veilig is...

Welke van de 2 zou ik dan het best kunnen gebruiken?

[RobIII]

Verwijderd schreef op maandag 20 juli 2009 @ 18:12:
Welke van de 2 zou ik dan het best kunnen gebruiken?

Dit is volgens mij al de vierde keer ofzo dat je dat vraagt. Waarom kijk je niet eens naar beiden en neem je zelf een besluit op basis van de voor jou belangrijke eisen en wensen die je hebt
Als je een puntenlijstje met voors- en tegens hebt en die naast mekaar zet moet je volgens mij prima zelf kunnen besluiten welke van de 2 (of 30+) je wil gebruiken. Mochten ze op (min-of-meer) voor jou belangrijke punten allemaal hetzelfde zijn dan kun je alsnog (en veel gerichter) vragen welke van de 2 voor jou het best is als je erbij vermeldt welke van die punten dan voor jou belangrijk zijn en waarom je dan twijfelt tussen de x-aantal kandidaten. Daar kunnen we dan veel meer zinnigs op zeggen.

Zoals je de vraag nu stelt krijg je straks 15 man die "A" roepen en 17 man die "B" roepen zonder verdere onderbouwing. En dat terwijl A misschien wel beter voor je is of de "verborgen" optie "C" die niemand noemt. Allen hebben hun voors en tegens; zonder onderbouwingen en er inhoudelijk op in te gaan krijg je dan gewoon "AJAX!! " "Nee PSV! " "Nee Feyenoord " gejoel terwijl het allemaal om 't even is

[ Voor 67% gewijzigd door RobIII op 20-07-2009 18:24 ]

[Verwijderd]

ok, ok sorry, kga dat onmiddellijk doen!!

Bedankt voor de tip, en bedankt voor alle informatie!!!

[mphilipp]

AtleX schreef op maandag 20 juli 2009 @ 10:31:
[...]
Leg eens uit

Nou...elke keer als er een actie van Brein is, moeten we aanhoren hoe zinloos copyright is en dat we tóch wel krijgen wat we willen. Ik verbaas me er dan ook steeds over dat 'dezelfde' mensen die dit soort reacties plaatsen (even gechargeerd, ik weet natuurlijk dat TS een modelburger is die nooit iets download) naarstig proberen hun eigen materiaal wél te beschermen tegen copyright schendingen. Dus ze proberen te voorkomen dat hun foto's worden gesnatched, of hun code wordt gedecompileerd.

Ik beschuldig niemand, maar ik probeer in dat soort situaties de advocaat van de duivel te spelen door mensen een spiegel voor te houden. Ik vind de argumenten altijd nogal eenzijdig: de kant van de consument op namelijk.

Ik realiseer me dat dit een schaamteloze topic-hijack is, maar misschien negeert iedereen het wel. Just as good. Misschien gaan er toch een paar mensen nadenken. De rest mag gewoon in blissfull ignorance verder leven...

btw: ik download ook, ik doe er alleen niet moeilijk over: ik ben een dief!

[Soultaker]

RobIII schreef op maandag 20 juli 2009 @ 18:15:
Als je een puntenlijstje met voors- en tegens hebt en die naast mekaar zet moet je volgens mij prima zelf kunnen besluiten welke van de 2 (of 30+) je wil gebruiken.

Of je gooit ze er allebei overheen; het zal er niet minder obfuscated door worden, toch?

mphilipp schreef op maandag 20 juli 2009 @ 18:49:
Nou...elke keer als er een actie van Brein is, moeten we aanhoren hoe zinloos copyright is en dat we tóch wel krijgen wat we willen. Ik verbaas me er dan ook steeds over dat 'dezelfde' mensen die dit soort reacties plaatsen [..] naarstig proberen hun eigen materiaal wél te beschermen tegen copyright schendingen.

De ironie is nog groter als je bedenkt dat populaire (proprietary) obfuscators als Dotfuscator ook massaal illegaal gekopieerd worden, terwijl daar nota bene ook gratis versies van zijn. Hetzelfde geldt trouwens voor Microsoft's development tools. Ik ben benieuwd hoeveel halfbakken DRM schemes er wel niet met illegaal verkregen tools ontwikkeld zijn.

[ Voor 47% gewijzigd door Soultaker op 20-07-2009 23:32 ]

[tonyisgaaf]

mphilipp schreef op maandag 20 juli 2009 @ 18:49:
[...]
Ik verbaas me er dan ook steeds over dat 'dezelfde' mensen die dit soort reacties plaatsen (even gechargeerd, ik weet natuurlijk dat TS een modelburger is die nooit iets download) naarstig proberen hun eigen materiaal wél te beschermen tegen copyright schendingen. Dus ze proberen te voorkomen dat hun foto's worden gesnatched, of hun code wordt gedecompileerd.
[...]

't Is maar net wat je wilt lezen hè? Uit de (summiere) informatie die de TS heeft gegeven maak ik op dat het om een security issue gaat, niet om de software zelf. De software geeft toegang tot een stuk informatie en de beveiligingsmethode die de TS voor ogen had (obfuscation van de code) om een "geheime" key voor ieder ander te verbergen heeft weinig te maken met bescherming tegen kopiëren.

*weg*

[ Voor 4% gewijzigd door een moderator op 20-07-2009 23:27 ]

[Zoijar]

tonyisgaaf schreef op maandag 20 juli 2009 @ 21:44:
*weg*

Behalve dat hij gewoon gelijk heeft Ik wilde al eerder een soortgelijk iets posten maar dacht toen "ach, laat ook eigenlijk maar". Ook is vaak de code die het meest beveiligd is het minst de moeite waard...

[ Voor 10% gewijzigd door een moderator op 20-07-2009 23:27 ]

[mphilipp]

tonyisgaaf schreef op maandag 20 juli 2009 @ 21:44:
[...]
't Is maar net wat je wilt lezen hè? Uit de (summiere) informatie die de TS heeft gegeven maak ik op dat het om een security issue gaat, niet om de software zelf.

Oh...dán is het heel erg zinvol... Je weet wel erg veel, hè?
Misschien moet je maar even koekelen op die tamtam rondom de OV chip. Alle twieker wijsneuzen wisten toen ook te vertellen dat open source beter was, speciaal voor security.
*weg*

[ Voor 11% gewijzigd door een moderator op 20-07-2009 23:27 ]

[RobIII]

Zo; en nu is 't welletjes geweest. De volgende die ik zie katten krijgt een mail.

offtopic:
Toen ik vroeger samen met mijn broertje in een stapelbed sliep (those were the days...) en hij lag (nou ja...wij lagen ) te klieren stond ons pa altijd even onder aan de trap alles aan te horen. En dan hoorde je opeens "BAM BAM BAM" pa de trap op stormen, "WENG" de deur open en "*Beng* *Beng*" en RobIII en BenIII zagen allebei sterretjes. Er werd niet gevraagd wie er begonnen was of wie zat te klieren. Waar er 2 ruzie hebben hebben er 2 schuld was de redenatie. En zo doe ik het hier nu ook. Basta

[ Voor 81% gewijzigd door RobIII op 21-07-2009 00:09 ]

[H!GHGuY]

Ik denk dat de TS het veel simpeler iets veiliger kan maken.

Sign je assemblies en gebruik die public key om je pass/user/timestamp te encrypten.
Aan de server kant heb je de private key en kun je mooi user/pass/timestamp decrypten en verifieren.
Is de assembly niet (of fout) gesigned, dan krijg je aan de andere kant ook rommel.
Schrijven ze nieuwe software die die public key gebruikt om user/pass/timestamp te encrypten en alsnog in te loggen, who cares. Ze hebben een valide user/pass/timestamp combinatie dus zijn ze een authorized user.

Je probeert je eigen systeem te beveiligen tegen je eigen users. Focus maar eerst op het beveiligen tegen unauthorized users, daar kom je al een heel eind verder mee.

[Remus]

H!GHGuY schreef op maandag 10 augustus 2009 @ 08:16:
Ik denk dat de TS het veel simpeler iets veiliger kan maken.

Sign je assemblies en gebruik die public key om je pass/user/timestamp te encrypten.
Aan de server kant heb je de private key en kun je mooi user/pass/timestamp decrypten en verifieren.
Is de assembly niet (of fout) gesigned, dan krijg je aan de andere kant ook rommel.
Schrijven ze nieuwe software die die public key gebruikt om user/pass/timestamp te encrypten en alsnog in te loggen, who cares. Ze hebben een valide user/pass/timestamp combinatie dus zijn ze een authorized user.

Je probeert je eigen systeem te beveiligen tegen je eigen users. Focus maar eerst op het beveiligen tegen unauthorized users, daar kom je al een heel eind verder mee.

Allereerst zou ik de assembly signen met mijn private key, anders kan iedere gebruiker die mijn public key heeft als nog een valide signature maken.
Maar zelfs met zo'n signatue: pas het programma aan zodat de oorspronkelijke informatie terug gestuurd wordt, tada, beveiliging ook doorgeprikt. Die beveiliging is dus net zo lek. De enige manier om je code te beschermen is door het niet aan de gebruiker ter beschikking te stellen. Maar als webapplicatie/saas oid.

[H!GHGuY]

Remus schreef op maandag 10 augustus 2009 @ 10:09:
[...]

Allereerst zou ik de assembly signen met mijn private key, anders kan iedere gebruiker die mijn public key heeft als nog een valide signature maken.
Maar zelfs met zo'n signatue: pas het programma aan zodat de oorspronkelijke informatie terug gestuurd wordt, tada, beveiliging ook doorgeprikt. Die beveiliging is dus net zo lek. De enige manier om je code te beschermen is door het niet aan de gebruiker ter beschikking te stellen. Maar als webapplicatie/saas oid.

Eerst en vooral, bij signing komt de public key in de assembly te staan, die gebruik je uiteindelijk.
Daarnaast: niet waar. de server verwacht public_key(user, pass, timestamp) en kan met de private key de boel terug decrypten en paswoord verifieren. Elke programmeur kan idd een tool maken die datzelfde berekent.
Bottom-line is dat je nog steeds een geldige user/pass combo nodig hebt om in te loggen.

Beter een goed opgebouwde transparante beveiliging dan een slechte obfuscated beveiliging.

[ Voor 4% gewijzigd door H!GHGuY op 10-08-2009 10:21 ]

[VisionMaster]

H!GHGuY schreef op maandag 10 augustus 2009 @ 10:20:
[...]


Eerst en vooral, bij signing komt de public key in de assembly te staan, die gebruik je uiteindelijk.
Daarnaast: niet waar. de server verwacht public_key(user, pass, timestamp) en kan met de private key de boel terug decrypten en paswoord verifieren. Elke programmeur kan idd een tool maken die datzelfde berekent.
Bottom-line is dat je nog steeds een geldige user/pass combo nodig hebt om in te loggen.

Beter een goed opgebouwde transparante beveiliging dan een slechte obfuscated beveiliging.

Je methode zal niet werken. Als ik de applicatie heb en kan decompilen wat je signing methode is, en de public key heb ik gekregen in de applicatie, dan maak ik mijn eigen private key, wijzig ik wat dingen in de applicatie en sign ik het met mijn eigen key die ik dan weer even goed embed in de applicatie.

Of nog mooier, ik haal de routines uit de applicatie die de signature controleren en in mijn nieuwe versie van de applicatie heeft de signature controle routine altijd een positief en prettig antwoord terug gegeven.

Ergo: "That's cute, but it's wrong"

[H!GHGuY]

VisionMaster schreef op maandag 10 augustus 2009 @ 14:07:
[...]

Je methode zal niet werken. Als ik de applicatie heb en kan decompilen wat je signing methode is, en de public key heb ik gekregen in de applicatie, dan maak ik mijn eigen private key, wijzig ik wat dingen in de applicatie en sign ik het met mijn eigen key die ik dan weer even goed embed in de applicatie.

Of nog mooier, ik haal de routines uit de applicatie die de signature controleren en in mijn nieuwe versie van de applicatie heeft de signature controle routine altijd een positief en prettig antwoord terug gegeven.

Ergo: "That's cute, but it's wrong"

Bedankt om aan te geven dat je het niet snapt.
Ergo:


De private key wordt server-side gehouden en ook daar wordt gecontroleerd of de login valid is.
Veel success met het signen van de recompiled app met je eigen key

[ Voor 9% gewijzigd door H!GHGuY op 10-08-2009 14:31 ]

[Gerco]

H!GHGuY schreef op maandag 10 augustus 2009 @ 14:29:
De private key wordt server-side gehouden en ook daar wordt gecontroleerd of de login valid is.
Veel success met het signen van de recompiled app met je eigen key

Je kan dan als aanvaller natuurlijk altijd de app signen met je eigen key, maar de login doen met de originele public key. Als je de app kan aanpassen kun je dat natuurlijk ook gewoon doen Je kunt alleen niet verbergen dat je het gedaan hebt omdat je de binary niet kunt re-signen met originele key.

[H!GHGuY]

Gerco schreef op maandag 10 augustus 2009 @ 14:40:
[...]

Je kan dan als aanvaller natuurlijk altijd de app signen met je eigen key, maar de login doen met de originele public key. Als je de app kan aanpassen kun je dat natuurlijk ook gewoon doen Je kunt alleen niet verbergen dat je het gedaan hebt omdat je de binary niet kunt re-signen met originele key.

Sure, maar aangezien je een geldige user/pass combinatie hebt, ben je een klant/gekende user.
Anders kom je alsnog niet binnen op de server. Dat is nu mijn hele punt. Maak een transparante maar veilige inlogprocedure en steek dan ook alle belangrijke operaties op de server.

Het enige wat je bereikt is dat je mensen verbiedt om hun eigen software te maken of jouw software aan te passen naar hun noden. Is dat het dan echt waard?

[Remus]

H!GHGuY schreef op maandag 10 augustus 2009 @ 14:29:
[...]

Bedankt om aan te geven dat je het niet snapt.
Ergo:
[afbeelding]

De private key wordt server-side gehouden en ook daar wordt gecontroleerd of de login valid is.
Veel success met het signen van de recompiled app met je eigen key

Dus, probleem bestaat nog steeds: als ik als kraker de public key heb, en die heb ik uit jouw originele programma, dan kan ik nog steeds alles naar hartelust signen met dezelfde informatie zoals in het oorspronkelijke protocol van het onaangepast programma, ook al heb ik de rest van het programma volledig verneukt.

[H!GHGuY]

Remus schreef op maandag 10 augustus 2009 @ 20:15:
Dus, probleem bestaat nog steeds: als ik als kraker de public key heb, en die heb ik uit jouw originele programma, dan kan ik nog steeds alles naar hartelust signen met dezelfde informatie zoals in het oorspronkelijke protocol van het onaangepast programma, ook al heb ik de rest van het programma volledig verneukt.

H!GHGuY schreef op maandag 10 augustus 2009 @ 16:00:
Het enige wat je bereikt is dat je mensen verbiedt om hun eigen software te maken of jouw software aan te passen naar hun noden. Is dat het dan echt waard?

Eindelijk. De euro is gevallen.

Dat is nu wat ik al de hele tijd vertel. Who cares dat iemand een andere client schrijft of jouw client aanpast.
Zolang je je logic op de server implementeert en een goeie interface exposed op de server inclusief beveiliging
is er niets aan het handje. Clients hebben hoe dan ook een geldige user/pass nodig om ingelogd te raken. Gebruiken ze nu client X of Y en is die client buggy of niet, who cares zolang jij de server maar controleert met een goeie interface die je kan beveiligen.

[Remus]

H!GHGuY schreef op dinsdag 11 augustus 2009 @ 08:08:
[...]


[...]


Eindelijk. De euro is gevallen.

Dat is nu wat ik al de hele tijd vertel. Who cares dat iemand een andere client schrijft of jouw client aanpast.
Zolang je je logic op de server implementeert en een goeie interface exposed op de server inclusief beveiliging
is er niets aan het handje. Clients hebben hoe dan ook een geldige user/pass nodig om ingelogd te raken. Gebruiken ze nu client X of Y en is die client buggy of niet, who cares zolang jij de server maar controleert met een goeie interface die je kan beveiligen.

De TS is bang dat mensen zijn programmatuur 'stelen' of aanpassen, maar is tegelijkertijd onwillig om de business logica op de server te gaan doen. Zolang de business logic in de client plaatsvind, zal jouw oplossing dan niet zoveel helpen.

Maar ik moet toegeven, ik heb je posts van gisteren misschien verkeerd gelezen, en hebben we het eigenlijk over hetzelfde.

[H!GHGuY]

Dan kunnen we denk ik gezamenlijk concluderen dat de TS zijn architectuur fout is en dat hij die beter eerst fixt.
In tussentijd kan hij misschien wel een release doen met een obfuscator als .NET reactor (meeste disassembly tools zien niet eens een CLR header), maar op de lange baan fixt hij beter zijn architectuur.