Archief - [PROG]JAVA Programma beveiligen met paswoord

Robain · 22 jun 2006

Messias. zei:
Wikipedia.

Aja kwist niet dat da een salt was, ma da was ik sowieso van plan

khad da eigenlijk zelf kunnen opzoeken, my bad

Krueger · 22 jun 2006

Robain zei:
- Hoe voorkom ik dat ze de code decompileren? Ik weet dat er voor php iets bestaat waarmee je je code kan beschermen. Is het zoiets waar jij op doelde Krueger?

Om je code te beschermen kan je het volgende doen: eerst obuscatie: Hierbij smijt je allemaal spaghetticode, extra functies die niets doen, recursieve functies die niets doen,... tussen je code. Daarna jaag je die geobfusceerde code door een andere soort vervormer, die alles zal hernoemen. Je variabelen noemen dan a1,a2,a3 etc en hetzelfde voor de functies, klassen,...
Deze combinatie maakt het zeer moeilijk om je code te lezen.
Voor beide soorten vervormingen bestaan er wel programma's.

Maar ik blijf er wel bij, als je die dingen lokaal gaat laten runnen, heeft het hashen volgens mij geen enkel nut.

RipTor · 22 jun 2006

Paswoorden moet je altijd ge-encrypteerd opslaan in je databank.

De gebruiker tikt zijn paswoord in. Je encrypteerd dat. En je vergelijkt dat met het geencrypteerde in de databank.

Dan moet je ook nog een goeie salt gebruiken.

Op volgende website vind ge de java versie van wat Unix gebruikt (crypt dus) om zijn paswoorden te decrypteren. Dit algoritme is al jaaaaaaren oud en nog nooit is dat gedecrypteerd geraakt.

Dat ze uw code kunnen decompileren maakt met crypt dus geen zak uit. Het is niet om te keren naar een decryptie algoritme.

Crypt is dus de algemene standaard kwa paswoord beveiliging.

(blowfish is om iets te encrypteren wat ook daadwerkelijk gedecrypteerd moet raken (bijvoorbeeld bestanden die over het internet over en weer moeten gaan en onderschept kunnen worden) en zeker niet geschikt voor paswoord encryptie).

In ieder geval is de gouden regel : Als er een methode bestaat om het paswoord te decrypteren dan is uw beveiliging zeer zwak.

RipTor · 22 jun 2006

Krueger zei:
Om je code te beschermen kan je het volgende doen: eerst obuscatie: Hierbij smijt je allemaal spaghetticode, extra functies die niets doen, recursieve functies die niets doen,... tussen je code. Daarna jaag je die geobfusceerde code door een andere soort vervormer, die alles zal hernoemen. Je variabelen noemen dan a1,a2,a3 etc en hetzelfde voor de functies, klassen,...
Deze combinatie maakt het zeer moeilijk om je code te lezen.
Voor beide soorten vervormingen bestaan er wel programma's.

Maar ik blijf er wel bij, als je die dingen lokaal gaat laten runnen, heeft het hashen volgens mij geen enkel nut.

Dit klopt allemaal. Maar ik wel erop wijzen dat dit hackers met ervaring echt niet lang tegenhoud hoor...

Die functies die niets doen enzo zijn er trouwens met tools automatisch terug uit te halen. Dat een obfuscatie programma alle strings enzo s1 enzo noemt en alle methods m1 enzoverder dat is enkel een tijdsvertraging.

Je mag er nooit van uitgaan dat mensen uw sourcecode niet zien. Zeker niet als je Java of .NET gebruikt.

Hoe je behoorlijk snel bijvoorbeeld aan het gedeelte source kan raken dat de encrypte verzorgt is de volgende:
Je decompileert de source (dat gaat altijd, ook met geobfusceerde source)
Je laat een tool niet gebruikte variablen, functies en classes opruimen
Je opent de geobfusceerde source in een IDE zoals Eclipse
Je zoekt naar de ActionListeners (deze naam is onmogelijk te obfusceren door een obfuscator) aangezien de paswoord controle wss toch getriggered wordt door een klik op een knop
Je zet daar breakpoints
Je runt je programma in debug mode en ziet op welk breakpoint je uitkomt na een klik op de inloggen knop

Dan zit ge al op het juiste spoor en dan is het slechts een kwestie van een maximaal enkele uurkes om er achter te komen waarvoor iedere variable eigenlijk dient

Robain · 22 jun 2006

RipTor zei:
Paswoorden moet je altijd ge-encrypteerd opslaan in je databank.

De gebruiker tikt zijn paswoord in. Je encrypteerd dat. En je vergelijkt dat met het geencrypteerde in de databank.

Dan moet je ook nog een goeie salt gebruiken.

Op volgende website vind ge de java versie van wat Unix gebruikt (crypt dus) om zijn paswoorden te decrypteren. Dit algoritme is al jaaaaaaren oud en nog nooit is dat gedecrypteerd geraakt.

Dat ze uw code kunnen decompileren maakt met crypt dus geen zak uit. Het is niet om te keren naar een decryptie algoritme.

Crypt is dus de algemene standaard kwa paswoord beveiliging.

(blowfish is om iets te encrypteren wat ook daadwerkelijk gedecrypteerd moet raken (bijvoorbeeld bestanden die over het internet over en weer moeten gaan en onderschept kunnen worden) en zeker niet geschikt voor paswoord encryptie).

In ieder geval is de gouden regel : Als er een methode bestaat om het paswoord te decrypteren dan is uw beveiliging zeer zwak.

crypt (of md5), icm met een random, lange salt zal dus idd een zo goed of onkraakbare manier geven om een paswoord op te slaan.

Maar, als je je encrypted paswoord opslaat is het toch niet zo moeilijk voor een hacker om gewoon het encrypted pasw in de db te vervangen door zijn eigen encrypted pasw. Als hij dan de salt vind door decompileren heeft hij toegang... In de db raken kan toch ook niet zo moeilijk zijn want ergens moet dat db systeem zijn paswoord opslaan waar hetzelfde kan toegepast worden...

Maar dit lijkt me nogal extreem, dus ik denk dat het idd zal voldoen zoals jullie voorstelden.

Volgende probleem, hoe makkellijk/moeilijk is het om de data gewoon rechtstreeks uit de db te weten te komen? Let wel, de database moet nog bruikbaar zijn, alles AES encrypted opslaan in de db is dus niet echt een optie...

Greetz, en vielen danksh fur de fielen antfwoorden (nee ik kan absoluut geen Duits

)

Vich · 23 jun 2006

Ivm dat decompileerprobleem:
Als je niet wil dat men je Java-code kan decompileren, dan kan je ook gewoon een Java compiler gebruiken die machinecodegenereert zoals een C/C++ compiler. Hiermee creëer je dus geen .jar package, maar een gewone executable met machinecode, net zoals C/C++.
Een voorbeeld van zo'n compiler:
http://nl.wikipedia.org/wiki/GNU_Compiler_Collection

En ok, dat is ook decompileerbaar, maar als je dat decompileert, dan krijg je machinecode te zijn. Dat is een ENORME uitdaging om te hacken.
Als je het dan toch nog meer wil beveiligen, dan kan je bijvoorbeeld software zoals "upx"(google) erop loslaten, zodat je executable wordt gestript, gepacked en geëncrypt.

Robain · 23 jun 2006

Vich, dat lijkt me een zeer goed idee

Zouden programma's die op die manier gecompileerd zijn dan ook niet een heel stuk sneller zijn dan programma's die gecompileerd worden met de Sun java-compiler??? Daar moet het immers eerst nog door virtual machine terwijl dit rechtstreeks zou zijn?

Dit lijkt me perfect, paar versies. Een versie die gemaakt is voor mensen die hoge beveiliging wensen maar cross-platform verliezen, en voor de rest de gewone cross-platform versie...

RipTor · 23 jun 2006

Robain zei:
crypt (of md5), icm met een random, lange salt zal dus idd een zo goed of onkraakbare manier geven om een paswoord op te slaan.

Maar, als je je encrypted paswoord opslaat is het toch niet zo moeilijk voor een hacker om gewoon het encrypted pasw in de db te vervangen door zijn eigen encrypted pasw. Als hij dan de salt vind door decompileren heeft hij toegang... In de db raken kan toch ook niet zo moeilijk zijn want ergens moet dat db systeem zijn paswoord opslaan waar hetzelfde kan toegepast worden...

Maar dit lijkt me nogal extreem, dus ik denk dat het idd zal voldoen zoals jullie voorstelden.

Volgende probleem, hoe makkellijk/moeilijk is het om de data gewoon rechtstreeks uit de db te weten te komen? Let wel, de database moet nog bruikbaar zijn, alles AES encrypted opslaan in de db is dus niet echt een optie...

Greetz, en vielen danksh fur de fielen antfwoorden (nee ik kan absoluut geen Duits )

In normale situaties staat die databank op een andere pc dan waar uw programma loopt (op ne servert toch).

Die server zou ergens moeten staan achter een ssh verbinding. Daarnaast zit daar ook weer die crypt protectie op (als ge bv postgres onder linux gebruikt). Dus dat zit dan wel veilig.

RipTor · 23 jun 2006

Robain zei:
Vich, dat lijkt me een zeer goed idee

Zouden programma's die op die manier gecompileerd zijn dan ook niet een heel stuk sneller zijn dan programma's die gecompileerd worden met de Sun java-compiler??? Daar moet het immers eerst nog door virtual machine terwijl dit rechtstreeks zou zijn?

Dat maakt maar zeer weinig uit.
Tijdens het uitvoeren van uw programma worden nu ook al heel grote delen code naar native code gecompileerd. Het opstarten zal sneller gaan maar voor de rest gaat ge er weinig van merken.

Dit lijkt me perfect, paar versies. Een versie die gemaakt is voor mensen die hoge beveiliging wensen maar cross-platform verliezen, en voor de rest de gewone cross-platform versie...

Ik wil er ook op wijzen dat GWJ niet alle functies van java ondersteund. Ik heb hier op mijn werk nog maar 1 project gevonden dat zowel werkt onder Sun als onder GCJ. Dat is dan een project van 8 jaar terug wat nog geen swing gebruikt. Ik heb enkel getest of de programma's opstarten. Het enige waar ik dus zeker van ben is dat dat programma opstart (en een 20-tal andere niet opstarten). Ik heb dus ook zeer grote twijfels over de stabiliteit van dat ene programma dat wel opstart.
Ik moet wel zeggen dat al die dingen gecompileerd zijn met een sun compiler. Mss als ik ze compileer met gjc dat ze wel werken.

Maar ik wil u toch nog eens hard op het hart drukken :
"Anything running on a computer can always be de-compiled/cracked, etc. It just depends on how hard the person wanting to see how your stuff works is willing to work."

Ge moet er echt vanuit gaan dat al heeft de hacker uw source-code dat hij het dan nog niet mag kunnen kraken. Er zijn echt wel mensen die nog met debug overweg kunnen hoor. Als ge uw paswoord in klaartekst in uw code zet is dat echt wel te vinden. Als uw paswoord in klaartekst over een lijn gaat is dat echt wel te onderscheppen.

Trouwens, als ne hacker het ding niet krijgt gecompileerd kan hij nog altijd inbreken op uw pc en daar de source vinden hé ?
En als ge 2 versies aanbied dan kan die hacker ook zonder probleem de gewone decompileerbare versie downloaden.

Denk eens na hoe snel de meeste games zijn gekraakt na release. En die gasten beschikken ook niet over de source-code van die games hoor.

.Acku. · 23 jun 2006

Robain zei:
Vich, dat lijkt me een zeer goed idee

Nee, dat lijkt me niet, sinds de helft van de API niet ondersteund wordt en je dus een pak tijd gaat verliezne met compabiliteitsproblemen die je niet eens verwacht. Het is wel een leuke gadget om te proberen.

Paswoord: MD5 hash naar database lijkt me voldoende
Encryptie data: Gebruik iets uit javax.crypto: http://javaalmanac.com/egs/javax.crypto/pkg.html#Encrypting and Decrypting

En PS: maak het niet TE moeilijk. De kans dat iemand met zoveel skill een onbekend programmaatje gaat hacken is klein, en je kan nooit 100% veiligheid garanderen sowieso. Verdoe uw tijd niet teveel, gebruik wat standaard wordt toegepast. Maak met die tijd een goede applicatie, uw klant zal dat meer apprecieren.

killgore · 23 jun 2006

Krueger zei:
Maar ik blijf er wel bij, als je die dingen lokaal gaat laten runnen, heeft het hashen volgens mij geen enkel nut.

Ksnap nog altijd waarom ge denkt dat dat geen nut heeft

.

RipTor · 23 jun 2006

killgore zei:
omdat je het paswoord rechtstreeks kan gebruiken .

kijk, als jij leest:
if(md5hash(pass)==myhashedcontroller))

met myhashedcontroller zo een mooie lange typische md5 string

Dan ben je niets verder, want zelfs al zou je die md5 string gebruiken als password, dan gaat hij die md5string weer opnieuw hashen en (gelukkig) de md5 hash van een md5 hash is een andere md5 hash .

Als je die code zo in je programma zet.
Dan kan iemand die de code krijgt gedecompileerd die code aanpassen zodat zijn ingegeven paswoord niet opnieuw wordt gehashed. En gewoon dus de hash ingeven als paswoord en hij is binnen.
Het paswoord moet zeker online van een db ingelezen worden.

Het voordeel van een hash tov encryptie: voor encryptiemethoden bestaan er altijd decrypties

Voor crypt bestaat er geen decryptie algoritme.
Je hebt 2 soorten encrypties:
Voor data transfer: die moet je aan de andere kant kunnen decrypteren dus dat is idd te decrypteren maar als je variable sleutels gebruikt allemaal niet evident
Voor paswoorden: niet decrypteerbare encryptie. Geencrypteerd paswoord opslaan in de db en de geencrypteerde versies met elkaar vergelijken.

MD5 hash lijkt me trouwens een zeer slecht idee want zoek maar eens op google naar 'md5 hash reverse'. Ik vond het al vreemd om iets (md5) wat helemaal niet voor dat doel (paswoord encryptie) is ontwikkeld te gebruiken daarvoor...

crypt is speciaal ontwikkeld meer dan 10 jaar geleden hiervoor en nooit gekraakt...

Dat is ineens een antwoord op killgore zijn vraag hierboven

Messias. · 23 jun 2006

RipTor zei:
Voor paswoorden: niet decrypteerbare encryptie. Geencrypteerd paswoord opslaan in de db en de geencrypteerde versies met elkaar vergelijken.

Dat noemt gewoon "hashen" in de volksmond, en is eigenlijk geen echte encryptie. Da's een onderdeel van de cryptografie, da's waar, maar om een paswoord op te slaan in een database maak je gebruik van een hashing-algoritme, niet van een encryptiealgoritme.

Dus SHA, MD5 of iets dergelijk. Niet AES of Blowfish.

RipTor zei:
'md5 hash reverse'

Ok, even wat ontkrachten. Die MD5 reverse is geen algoritme dat een hash kan ontcijferen, dat is een gigantische database vol woorden en zinnen met hun bijhorende hash. In die database wordt dan de hash opgezocht en bijhorende tekst wordt weergegeven. Dit fenomeen heet rainbow tables en doet in feite niets af aan de sterkte van hashing, zolang je een cryptografisch sterk paswoord gebruikt.

Vanuit een hash ZOU het onmogelijk moeten zijn om terug te keren naar het origineel. In sommige implementatie's zitten wel fouten waardoor het aantal iteraties bij een bruteforce sterk verminderd kan worden.

MilM · 23 jun 2006

killgore zei:
Ksnap nog altijd waarom ge denkt dat dat geen nut heeft .

Als alles lokaal staat, welk nut heeft het dan ?
Je gaat daar gaan hashen en decrypten terwijl men rechtreeks het opgeslagen passwoord en code kan veranderen.

Indien de data op een beveiligde server staat (en dus niet op de pc waar het programma gerund wordt), dan is dat wat anders natuurlijk.

Robain zei:
stel dat er iemand de pc in handen krijgt waarop de database staat (en dus wss ook het programma), is er dan een manier om te voorkomen dat deze persoon de de inhoud van de database te weten komt?

Dat is toch de kernvraag.
Je mag de communicatie tussen de databank en het programma dan zwaar beveiligen, maar het lijkt mij erop dat men hier rechtreeks aan de databank kan. (ik weet ook niet in welke mate een lokale databank te beveiligen is, maar ik veronderstel dat men dat ook nit echt zwaar kan beveiligen tegen personen die er fysieke toegang tot hebben?)

Uiteindelijk heeft men maar twee zaken nodig: de financiele data zelf die op de pc dan nog eens staat en het algoritme in de code van hoe de data gelezen wordt (decompileren van uw java bestanden). (want je zou bv bij elk teken +1 kunnen optellen bij het opslaan zodat een a bv een b wordt en dan bij het inlezen -1 doen)

Volgens mij wilt de topicstarter een toepassing maken dat totaal geen gebruik maakt van een netwerk. Dus een programma waar zowel de code, passwoord als financiele data op dezelfde pc staan. (eventueel met databank, maar dan één dat op dezelfde pc als het programma draait).

dJeez · 23 jun 2006

Als je lokaal gaat werken waarom zou je dan opteren voor PostgreSQL? Dan zijn er wel andere opties, en zou ik eerder iets als HSQLDB of SQLite aanraden.

Het grappige is dat heel jullie discussie ivm MD5 hashes eigenlijk totaal naast de kwestie is. Of de paswoorden nu leesbaar zijn of niet maakt geen zak uit als iemand rechtstreeks de gegevens in de database kan consulteren. En dat kan je dus zonder enig probleem doen (zelfs zonder paswoord) op een lokaal geïnstalleerde PostgreSQL database (ff de configuratie aanpassen en de toegang voor de gewenste gebruiker op trusted zetten) - en bij uitbreiding kan dat ook op zowat elk RDBMS dat ik ken (ik kan er toch niet direct eentje bedenken waar het niet het geval is).

Enkel indien de gegevens in de gevoelige kolommen daadwerkelijk geencrypteerd zijn kan je ervan uitgaan dat het zo goed als onmogelijk is om de inhoud ervan te achterhalen (tenzij je je encryption key zou laten rondslingeren).

MilM · 23 jun 2006

Van databanken weet ik niets, maar data encrypteren is idd wel een oplossing.

Bv door een publieke key en private key te genereren. De public key is dan de key gebruikt om gegevens te encrypteren en de private key (die ingegeven wordt als passwoord en niet opgeslagen wordt op de hd) om dan gegevens te decrypteren.

Is enkel een voorbeeld om het idee voor te stellen, want ik weet niet welke de beste mogelijkheden precies zijn.

Vond het enkel zoals krueger onlogisch om veel tijd te steken in passwoorden wanneer de data rechtreeks toegankelijk is (zoals djeez zei)

.Acku. · 23 jun 2006

Waarom zou een lokale database niet te beveiligen vallen? De login kan intern toch ook versleuteld zijn, en de data encrypted? Een database is toch niet anders dan een applicatie met een interface?

MilM · 23 jun 2006

.Acku. zei:
Waarom zou een lokale database niet te beveiligen vallen? De login kan intern toch ook versleuteld zijn, en de data encrypted? Een database is toch niet anders dan een applicatie met een interface?

Maar uiteindelijk moet je toch "iets" bijhouden dat niet op de pc staat ? (bv een key op een papierke)
Of hoe werkt zoiets dan ? (want indien je met een gewoon pass werkt, dan moet de key ergens op de hd staan en is ze dus te vinden toch)

Eerder een vraag uit interesse, want ik heb mij ooit al eens dezelfde vraag gesteld als de topicstarter (nooit antwoord op gezocht omdat ik het niet nodig heb en lui ben

)

RipTor · 23 jun 2006

MilM zei:
Maar uiteindelijk moet je toch "iets" bijhouden dat niet op de pc staat ? (bv een key op een papierke)
Of hoe werkt zoiets dan ? (want indien je met een gewoon pass werkt, dan moet de key ergens op de hd staan en is ze dus te vinden toch)

Eerder een vraag uit interesse, want ik heb mij ooit al eens dezelfde vraag gesteld als de topicstarter (nooit antwoord op gezocht omdat ik het niet nodig heb en lui ben )

Nee want ge wilt dat paswoord niet decrypteren...
Ge hebt voor zulke encrypties helemaal geen key nodig. Enkel een salt die ge genereerd afhankelijk van iets anders.

Ge vergelijkt gewoon het in de databank geencrypteerde paswoord met de geencrypteerde versie van het paswoord dat de gebruiker heeft ingetikt.

RipTor · 23 jun 2006

dJeez zei:
Als je lokaal gaat werken waarom zou je dan opteren voor PostgreSQL? Dan zijn er wel andere opties, en zou ik eerder iets als HSQLDB of SQLite aanraden.

Het grappige is dat heel jullie discussie ivm MD5 hashes eigenlijk totaal naast de kwestie is. Of de paswoorden nu leesbaar zijn of niet maakt geen zak uit als iemand rechtstreeks de gegevens in de database kan consulteren. En dat kan je dus zonder enig probleem doen (zelfs zonder paswoord) op een lokaal geïnstalleerde PostgreSQL database (ff de configuratie aanpassen en de toegang voor de gewenste gebruiker op trusted zetten) - en bij uitbreiding kan dat ook op zowat elk RDBMS dat ik ken (ik kan er toch niet direct eentje bedenken waar het niet het geval is).

Enkel indien de gegevens in de gevoelige kolommen daadwerkelijk geencrypteerd zijn kan je ervan uitgaan dat het zo goed als onmogelijk is om de inhoud ervan te achterhalen (tenzij je je encryption key zou laten rondslingeren).

Ik ben het daar min of meer mee eens. Als die pc goed is geconfigureerd kan men daar niet eens op inloggen, laat staan voldoende rechten krijgen om de config van postgres aan te passen.
Aan de andere kant, als ge de pc zelf hebt houdt niks u tegen om via ne floppy in single user mode linux te booten, dus in dat geval klopt dat wat djeez zegt inderdaad.

Eigenlijk kunt ge wel stellen dat als alles lokaal op 1 pc draait en de hacker komt fysich in het bezit van die pc dan is alles te kraken (decompileren, md5 of crypt ding uitschakelen in code, het gecrypte paswoord opzoeken in de db, gecrypte paswoord intikken en ge zijt binnen).

Maar zo is ook iedere Unix/Linux/BSD pc op enkele seconden volledig te kraken als ge er fysiek aankunt. En Unix staat toch wel bekend als veilig.

Archief - [PROG]JAVA Programma beveiligen met paswoord

Robain

Legacy Member

Krueger

Legacy Member

RipTor

Legacy Member

RipTor

Legacy Member

Robain

Legacy Member

Vich

Legacy Member

Robain

Legacy Member

RipTor

Legacy Member

RipTor

Legacy Member

.Acku.

Legacy Member

killgore

Legacy Member

RipTor

Legacy Member

Messias.

Legacy Member

MilM

Legacy Member

dJeez

Legacy Member

MilM

Legacy Member

.Acku.

Legacy Member

MilM

Legacy Member

RipTor

Legacy Member

RipTor

Legacy Member