[java] 'onleesbare' variable in een jar/class, hoe?

[Joove]

Op welke manier kan ik in een jar/class variable zetten die niemand er uit kan halen, op welke manier dan ook, behalve misschien brutt force?

Heb wel iets gelezen over een keytool kan het daar mee of niet?

Als voorbeeldje een classe die contect met een ftp server waarvan je het wachtwoord en eventueel inlognaam geheim wilt houden.
of bijvoorbeeld een key om gegevens gecodeerd in een bestand te zetten en die er ook weer te decoderen.

[Onno]

Joove schreef op 27 mei 2003 @ 22:35:
Als voorbeeldje een classe die contect met een ftp server waarvan je het wachtwoord en eventueel inlognaam geheim wilt houden.

En dan pakt iemand er gewoon een netwerk sniffer bij en draait het proggie. Wachtwoorden zijn altijd wel te achterhalen. Als je class het moet kunnen ontcijferen kan iemand anders dat ook.

[Joove]

en hoe zit het dan in het andere geval? van het coderen en decoderen van gegevens van en naar een bestand en een key?

[ACM]

Ook die is te achterhalen, maar al iets lastiger. Ondanks dat blijft gelden wat Onno zegt. Als de klasse het zelf kan ontcijferen kan een handige programmeur/kraker dat ook...

[Erkens]

vergeet ook niet dat java class files erg makkelijk te decompilen zijn
daarnaast lijkt het me niet handig om passwords mee te compilen, simpel weg omdat je dan steeds opnieuw moet compilen als je je password veranderd

[PommeFritz]

Je zou kunnen overwegen om niet het wachtwoord zelf maar de secure hash daarvan (MD5 of SHA-1) op te slaan. Het is uitgesloten dat men, als men die ziet, kan achterhalen wat het oorspronkelijke wachtwoord is geweest.

Maar inderdaad, java classes zijn uitstekend te decompilen en het is 1 minuut werk om zo'n check eruit te slopen, dus je wint er weinig mee...

[Erkens]

PommeFritz schreef op 28 mei 2003 @ 22:53:
Je zou kunnen overwegen om niet het wachtwoord zelf maar de secure hash daarvan (MD5 of SHA-1) op te slaan. Het is uitgesloten dat men, als men die ziet, kan achterhalen wat het oorspronkelijke wachtwoord is geweest.

md5 heb je in dit geval niets aan (SHA-1 ken ik niet) aangezien je die niet kan omkeren

[ACM]

SHA-1 is een andere hasher, eentje met wat langere hashkeys (160 bits).

[swampy]

Dat MD5 niet om te keren valt hoort erbij, de server moet namelijk de aangeboden HASH vergelijken met een HASH in een database.

Maar je werkt zeker met een FTP server ofzo...tja...sommige ondersteunen HASH wachtwoorden..nou ja..die kunnen clienten laten inloggen via de HASH

[Erkens]

ACM schreef op 28 mei 2003 @ 23:28:
SHA-1 is een andere hasher, eentje met wat langere hashkeys (160 bits).

dus ook niet om te draaien?

[ACM]

Das een van de basisprincipes achter zulke hashfunctie, erkens

[ Voor 15% gewijzigd door ACM op 28-05-2003 23:49 ]

[hobbit_be]

gewoon met een key werken - dit moet dan wel doorgegeven worden 'op een veilige manier' maar zo kun je zowel log/pass erin proppen (encoded , lets say 1024bit) zonder je al te veel zorgen te maken. Natuurlijk moet je wel zien dat de code dat l/p ook echt nodig heeft zodat een cracker niet gewoon een 'jmp' can doen...

[ACM]

't Probleem daarmee is dat als je klasse het niet kan decoderen jij dat ook niet hoeft te kunnen

De hash meesturen is net zo makkelijk als de inhoud die het had kunnen hebben.

[hobbit_be]

ACM schreef op 29 mei 2003 @ 01:53:
De hash meesturen is net zo makkelijk als de inhoud die het had kunnen hebben.

idd. maar ik had het niet over een hash maar een key. ie een 'decrypt' password dus. encrypt alles wat beveiligd moet worden met een key en dan moet je client side de decrypt key ingeven (ie dus full auto kan idd niet, maar dat weet iedereen)...

[Verwijderd]

en als je zou werken zoals POP3 authentificatie via cram-md5 ( Challenge-Response Authentication Mechanism-Message Digest 5 (CRAM-MD5). zoals mijn GMX account bijvoorbeeld)?
De server stuurt een string, en die gebruik je als salt voor je MD5 van je paswoord. De string van de server is random, en base64 encoded. Je stuurt die md5 ook base64 decoded naar de server. Daar wordt adhv het salt dat ze je gegeven hebben een controle uitgevoerd op je wachtwoord. Ik vind dit een uiterst veilige authenticatie voor POP3, maar m'n provider zelf doet het niet, en gratis GMX accountje wel

[Sjaaky]

Dat helpt natuurlijk ook niet. Je kan het zo ingewikkeld maken als je wilt, maar uiteindelijk kan de persoon achter de pc (als deze voldoende kennis/tijd/zin heeft) die hele procedure exact na doen.
Als je de java classen decompileert, hoef je alleen de methoden/classen op te zoeken die de authenticatie regelen (Wat zelfs als de java geobfuscate is niet moeilijk hoeft te zijn). Deze kan je vervolgens gebruiken voor eigen doeleinden.
Het verschil tussen POP3-auth en de situatie zoals de ts deze beschrijft is kennis van het password. Met pop3-auth kennen alleen jij en de provider het password (al dan niet in gehashte vorm). In het geval van de ts, beschikt alleen de ts over het password en het clientprogramma. Maar dat programma is in handen van de gebruiker, die er vanalles mee kan doen.
Ik weet niet of het ook echt bewezen is op een of andere manier, maar volgens mij is het theoretisch onmogelijk om het veilig te krijgen. Misschien dat palladium, een initiatief van Microsoft hier verandering in kan brengen. Het beperkt en controleert de toegang tot de computer voor de gebruiker.

@TS: uiteraard kan je het 'hackers' zo moeilijk mogelijk maken, maar ik zou de data die het programma nodig heeft van de server 'publiek' beschouwen. Dus de client alleen geven wat het nodig heeft en de client niet als betrouwbaar te behandelen.

[ Voor 2% gewijzigd door Sjaaky op 29-05-2003 20:00 . Reden: dubbele ontkenning weggehaald ]