Bescherming van je broncode tegen decompilatie

[Verwijderd]

2 de poging :):
(Hopelijk is dit het juiste forum, ik heb ze allemaal overlopen en ik vond dat het het best paste bij dit forum)
Mijn programma is net af (vb.net) en nu wil ik graag hetvolgende: Ik wil niet dat iemand de programmacode kan zien. Er bestaan kleine decompilers om je vb.net code van je exe bestand weer om te vormen tot de echte programmacode. Zo wordt mijn beveiliging zichtbaar en dat wil ik niet. Ik heb al even gegoogled maar het enige dat ik kon vinden zijn obfuscators. Die zorgen er blijkbaar voor dat de variables veranderen van naam en zo willigkeurige betekenis hebben en dat de code dus onleesbaar wordt. Met wat verder opzoekingswerk ben ik er dan ook weer achtergekomen dat men toch deels de werking zou kunnen begrijpen als men er lang genoeg ernaar zoekt... . Weet er iemand of er nog een andere mogelijkheid is om decompilatie tegen te gaan? En heeft er iemand ervaring met een obfuscator (ik heb er zo een 5 tal gevonden, maar die waren steeds te betalen, (prijs ging van 100 tot 2000 euro) dus weet er iemand een gratis obfuscator?

nahow1

[Marcj]

Een obfuscator maakt de code wel minder makkelijk te begrijpen, maar uiteindelijk is alle code te lezen omdat deze ook door een (virtuele) machine begrijpbaar moet zijn.

Daarnaast vraag ik me altijd af waarom je dit zouden willen?

Maar goed, Skater heeft een Light versie. Zelf geen ervaring mee...

[djexplo]

Wikipedia: Security through obscurity is vaak geen goed idee, je kan beter een goed algorithme gebruiken voor je sleutels...

[ Voor 28% gewijzigd door djexplo op 18-07-2009 16:11 ]

[Verwijderd]

Marcj schreef op zaterdag 18 juli 2009 @ 16:04:
Een obfuscator maakt de code wel minder makkelijk te begrijpen, maar uiteindelijk is alle code te lezen omdat deze ook door een (virtuele) machine begrijpbaar moet zijn.

Daarnaast vraag ik me altijd af waarom je dit zouden willen?

Maar goed, Skater heeft een Light versie. Zelf geen ervaring mee...

In mijn programma heb ik een kleine beveiliging ingewerkt, en dus als je de exe file kan decompileren, en de echte programma code zichtbaar wordt, kan je mijn beveiliging omzeilen en dat wil ik juist niet.

[ Voor 52% gewijzigd door Verwijderd op 18-07-2009 16:12 ]

[Macros]

Dan moet je een betere beveiliging bedenken....
Trouwens, de beveiliging van je huis is ook niet voldoende, want iedereen met een auto kan zo je huis binnen rijden, en dat wil je niet...
Het is maar hoeveel je wilt investeren in je beveiliging, uiteindelijk zal alles te breken zijn. Ligt er maar aan hoeveel jij en je tegenstanders ervoor over hebben.

[Verwijderd]

Macros schreef op zaterdag 18 juli 2009 @ 16:20:
Dan moet je een betere beveiliging bedenken....

Is dat niet onmogelijk zolang ze steeds de programmacode kunnen lezen?

[Verwijderd]

Verwijderd schreef op zaterdag 18 juli 2009 @ 16:24:
[...]
Is dat niet onmogelijk zolang ze steeds de programmacode kunnen lezen?

Alles wat beveiligd is kan gekraakt worden. Het niveau van de beveiliging bepaalt alleen de tijd dat het kost eer het gekraakt is, maar het is niks meer dan uitstel

[Verwijderd]

Ik wil toch graag hebben dat het niet onmiddellijk te kraken valt, dat is om problemen vragen...

[Skinkie]

Verwijderd schreef op zaterdag 18 juli 2009 @ 16:30:
Ik wil toch graag hebben dat het niet onmiddellijk te kraken valt, dat is om problemen vragen...

Dan heb je het in de verkeerde taal geschreven.

[Onbekend]

In een .exe zitten de programmainstructies op laag niveau zoals optellingen, bitbewerkingen, variables kopiëren en vergelijkingen. Dit is gewoon uit te lezen aangezien de processor dat moet uitvoeren. Nu is het uitlezen geen groot probleem, maar het begrijpen van de uitgelezen code is veel moeilijker.
Daarnaast raad ik je aan om de opties om jouw programma te debuggen uitzetten zodat er zo min mogelijk relevante informatie in de .exe komen te staan. Hoe minder informatie, des te moeilijker het te begrijpen is, en des te meer mensen afvallen met de poging om het programma te decoderen. Het voor 100% beveiligen tegen decoderen is (tot zover ik weet) niet mogelijk.

[Verwijderd]

Skinkie schreef op zaterdag 18 juli 2009 @ 16:34:
[...]

Dan heb je het in de verkeerde taal geschreven.

Is dat dan niet bij alle talen zo?
mss had ik toch beter c++ gekozen, maar daar heb je geen goede designer software... heb je heel veel werk voor een simpele form te maken.

[Zoijar]

Gebruiker een offset laten invoeren als password en daar rechtstreeks naartoe jumpen

Nodige delen van je code alleen naar je geheugen kopieren vanaf een internet server waar je op in moet loggen

(uiteraard ook allemaal kraakbaar; steam apps worden tenslotte ook gekraakt)

[ Voor 16% gewijzigd door Zoijar op 18-07-2009 16:45 ]

[Verwijderd]

Worden obfuscators eigenlijk vaak gebruikt?

[Marcks]

Verwijderd schreef op zaterdag 18 juli 2009 @ 16:24:
[...]


Is dat niet onmogelijk zolang ze steeds de programmacode kunnen lezen?

Dat ligt een beetje aan wat jouw beveiliging precies probeert te bereiken, maar het programma uitlezen kan men sowieso wel. Om een programma uit te voeren, moet de pc begrijpen wat er staat, en als dat kan, kan de gebruiker dat dus ook. Wat ik uit je posts opmaak is dat je beveiliging gebaseerd is op de aanname dat de gebruiker/aanvaller bepaalde informatie niet heeft, terwijl je voor het beoogde doel van je software die informatie wèl moet verstrekken.

Ik zou dan ook gaan uitzoeken hoe ik m'n beveiliging zo kon opzetten, dat iemand die weet hoe hij in elkaar steekt, hem alsnog niet kan omzeilen, in plaats van proberen te voorkomen dat men jouw software analyseert.

[Zoijar]

Je kan het ook misschien via een webserver draaien, als ASP.NET applicatie in VB. Dan kan er niemand bij je code.

[user109731]

Verwijderd schreef op zaterdag 18 juli 2009 @ 16:39:
mss had ik toch beter c++ gekozen, maar daar heb je geen goede designer software... heb je heel veel werk voor een simpele form te maken.

Qt heeft een prima designer

Zoals gezegd, een obfuscator kan helpen om script-kiddies te ontmoedigen, maar een beetje 'hacker' komt er toch wel uit. Kijk maar naar alle software waar cracks voor bestaan... Gaat het om bijv. een encryptie-algoritme dan mag de code daarvan natuurlijk wel openbaar zijn en zou ik m'n tijd in het algoritme steken.

[ Voor 8% gewijzigd door user109731 op 18-07-2009 16:55 ]

[djexplo]

Stel je hebt één of andere sleutel die de gebruiker moet invoeren, dan kan je die sleutel als md5 in je code zetten...

Je hebt alleen nog steeds niet vertelt wat je nou precies wilt beveiligen

[Verwijderd]

Qt designer heb ik al uitgetest, maar vond het niet zo goed..., het is enkel freeware voor non commerical edition

djexplo schreef op zaterdag 18 juli 2009 @ 16:57:
Stel je hebt één of andere sleutel die de gebruiker moet invoeren, dan kan je die sleutel als md5 in je code zetten...

Je hebt alleen nog steeds niet vertelt wat je nou precies wilt beveiligen

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

[ Voor 77% gewijzigd door Verwijderd op 18-07-2009 17:03 ]

[IStealYourGun]

Verwijderd schreef op zaterdag 18 juli 2009 @ 16:27:
[...]

Alles wat beveiligd is kan gekraakt worden. Het niveau van de beveiliging bepaalt alleen de tijd dat het kost eer het gekraakt is, maar het is niks meer dan uitstel

Tenzij je natuurlijk blijft investeren in beveiliging. :-)

[SKiLLa]

Commerciele kopieerbeveiligingen als b.v. ASProtect en Armadillo zijn anno 2009 nog steeds redelijk moeilijk te kraken (het houdt de gelegenheids hobbyisten buiten de deur), maar de meeste "gratis" oplossingen bieden vooral een wassenneus bescherming. Ook de wat oudere commerciele beveiligingen als (b.v.) ASPack, PECompact en PC-Guard zijn vrijwel allemaal automatisch uit te pakken met gratis downloadbare tools.

Voor .Net specifieke obfuscators zou je kunnen kijken naar commerciele oplossingen die van de .Net bytecode een echte native executable maken (die de dependencies naar het .Net framework vervangen door calls in hun eigen wrapper .exe). Daardoor is het decompileren van de (net-niet) IL code vrijwel onmogelijk en ook het debuggen van native- en managed-code in een debugger is vele malen moeilijker dan normaal.

Neem b.v. RemoteSoft .Net Protector of Xenocode (al zijn oude versies regelmatig gekraakt) of 9Rays/Spices.Net.

Sowieso is het zelf (uitdenken en) implementeren van een goede beveiliging moeilijker dan je denkt, als het puntje bij paaltje komt is het uiteindelijk vaak slechts een 0 door een 1 (of omgekeerd) vervangen. Waarom maak je niet gewoon een probeer-versie en een volledige-versie waarbij de probeer-versie simpelweg de "volledige-versie" code niet bevat ? Als de code ontbreekt, valt er immers niets te kraken ...

PS:

webshit schreef op zaterdag 18 juli 2009 @ 17:00:
[...]
Tenzij je natuurlijk blijft investeren in beveiliging. :-)

Dat lukt je toch nooit, als games als GTA 4 en Spore binnen 24 uur gekraakt worden (soms zelfs al voor de officiele release), terwijl dat nou juist extreem zwaar beveiligde games zijn, dan geeft het wel aan dat die strijd niet te winnen is. En neem een "revolutionaire" beveiliging als Starforce, toen die nieuw uitkwam werden de nieuwste games zeker 2~3 maanden niet direct gekraakt, maar daarna was het weer slechts een urenkwestie, ondanks de miljoenen die erin geinvesteerd zijn ...

[ Voor 19% gewijzigd door SKiLLa op 18-07-2009 17:20 ]

[Verwijderd]

Zal ik toch maar es verder zoeken naar een betere beveiliging...

Heeft er iemand ervaring met een obfuscator en of met de skater .net obfuscator (zie link bovenaan topic)

SKiLLa schreef op zaterdag 18 juli 2009 @ 17:15:

Sowieso is het zelf (uitdenken en) implementeren van een goede beveiliging moeilijker dan je denkt, als het puntje bij paaltje komt is het uiteindelijk vaak slechts een 0 door een 1 (of omgekeerd) vervangen. Waarom maak je niet gewoon een probeer-versie en een volledige-versie waarbij de probeer-versie simpelweg de "volledige-versie" code niet bevat ? Als de code ontbreekt, valt er immers niets te kraken ...

Wat bedoel je precies met probeer versie en volledige versie, want ik heb alle code nodig...( er is maar 1 versie)?
En er bestaat waarschijnlijk geeen gratis obfusctator die naar de native code gaat?

[ Voor 69% gewijzigd door Verwijderd op 18-07-2009 17:21 ]

[djexplo]

Verwijderd schreef op zaterdag 18 juli 2009 @ 16:59:
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

Als je de gebruikersnamen altijd een vast gedeelte te hebben b.v. pietje moet userpietje en klaas, userklaas in voeren.
Dan kan je letters gebruiken om een database wachtwoord te decoderen, die je ge-encode in je programma zet.

Voor het contact maken met je database zou je eigenlijk ook een beveiligde verbinding moeten gebruiken, waarbij je zeker weet dat dit de database is, en niet één of andere fake wachtwoord snif programma/server of man in de middle attack .

[donzz]

Verwijderd schreef op zaterdag 18 juli 2009 @ 16:59:
...
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

Kan je dan niet de key berekenen aan de hand van het wachtwoord? Dan mag de berekening wel openbaar woren, maar moet de hacker nog steeds het wachtwoord hebben.

[SKiLLa]

Ik bedoel inderdaad b.v. een probeer-versie waar je geen "save" functie hebt (omdat de code ontbreekt, niet omdat er ergens een vinkje IsRegistered() uitstaat). Als een dergelijke configuratie in jou toepassing niet mogelijk is, dan wordt het inderdaad moelijker.

Ik ken verder geen gratis obfuscator die "voldoet". Pak je echter oude tools als ASPack of PECompact of UPX + UPX Scrambler/SH!T/Mangler (= gemodificeerde UPX, zodat ie niet meer automatisch uit te pakken is) dan houd je mogelijk toch al wat "hackers" die geen assembly ervaring hebben buiten de deur; een direct decompile van de IL code is immers niet meer mogelijk. Voor de experts is het echter een lachertje, maar hoe groot is de kans dat je tool "slachtoffer" wordt van een serieuze hacker ... ?

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 (b.v. op de .Open) en de data uitlezen; hoe beveiligd je eigen app ook is). Heb die techniek zelf meerdere malen - legaal & legitiem - succesvol toegepast.

[ Voor 21% gewijzigd door SKiLLa op 18-07-2009 17:31 ]

[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.