Archief - [PROG]JAVA Programma beveiligen met paswoord

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
R

Robain

Legacy Member
Hallo,


Ik zou moeten een programma maken dat beveiligd is a.d.h.v. een login en een pasword. Meerdere gebruikers zou een mogelijkheid moeten zijn, alsook het aanpassen van wachtwoord en toevoegen van gebruikers...

Nu vraag ik me af hoe ik dit op een zo veilig mogelijke manier kan beveiligen? Het gaat namelijk over zeer gevoelige, financiele informatie...


Dit is wat ik in gedachten had :
- paswoord encrypted opslaan in een bestand m.b.v. JCE (wat is het beste encryption algoritm?? DES?? ).
- CRC checken van bestand om integriteit na te gaan.


Nu heb ik het gevoel dat dit geen zo'n goeie aanpak is. Heeft er iemand een beter idee?? Veiligheid is een absolute prioriteit!


Greetz
B

BuiZe

Legacy Member
DES is redelijk verouderd en vlot te kraken. AES, Triple DES, Blowfish zijn goeie keuzes, zolang de encryptiesleutel volgoende groot is.

Voor de rest is encryptie wel aangewezen, maar het grote probleem hierbij is dat gegevens met één sleutel geencrypteerd worden terwijl meerdere gebruikers met elk een eigen login noodzakelijk zijn.

Mijn eerste idee zou zijn om de (unieke) sleutel voor de gegevens te encrypteren voor elke gebruiker met als sleutel de login van deze gebruiker.
R

Robain

Legacy Member
BuiZe zei:
DES is redelijk verouderd en vlot te kraken. AES, Triple DES, Blowfish zijn goeie keuzes, zolang de encryptiesleutel volgoende groot is.

Voor de rest is encryptie wel aangewezen, maar het grote probleem hierbij is dat gegevens met één sleutel geencrypteerd worden terwijl meerdere gebruikers met elk een eigen login noodzakelijk zijn.
Klik om te vergroten...


Hmm het is mss ook een mogelijkheid zonder username te werken en met enkel 1 paswoord al ik op deze manier een veiliger programma kan maken...


Wat ik me nu ook afvroeg is of dit eigenlijk wel nut heeft omdat ik van plan was om data op te slaan in een postgreSQL database. Hoe veilig zit de data hier dan? Dit paswoord zou ik dan mss best hardcoden in het programma? Of niet? Of is een ander database systeem aangeraden voor gevoelige data?


Greetz
M

Messias.

Legacy Member
Ik heb trouwens overlaatst een interessant artikel gelezen over cache-timing aanvallen op AES.
V

Vich

Legacy Member
Sla geen wachtwoorden op! Ook niet geëncrypteerd!
Maak een MD5 hash van je wachtwoord en sla die op. Als je dan een wachtwoord vraagt dmv een dialog box, dan ga je daar de MD5 hash van berekenen en deze vergelijken met de reeds opgeslagen hash.

Een MD5 hash kan je creëren uit een reeks data(een wachtwoord, een file, etc). Het is zoiets als een CRC, maar dan een unieke sleutel. Een MD5 hash heeft ook altijd dezelfde grootte(kan alleen even niet herinneren hoe groot precies).
Je kan dus data naar MD5 omrekenen, maar niet terug. Dit is een soort van eenwegs-encryptie.

Je hebt dus iets nodig dat een MD5 sleutel kan berekenen.
Je zou ook bijvoorbeeld de MD5 sleutel van elk bestand kunnen berekenen om te zien of de inhoud veranderd is, maar ik weet niet hoe CPU-intensief dat is.
k

killgore

Legacy Member
Vich zei:
Je zou ook bijvoorbeeld de MD5 sleutel van elk bestand kunnen berekenen om te zien of de inhoud veranderd is, maar ik weet niet hoe CPU-intensief dat is.
Klik om te vergroten...
Valt goed mee. Wordt vaak gedaan om te controleren op corrupte downloads/isos/.... Alleen moet je het nu niet op immens grote bestanden gaan doen telkens als je programma opstart, zou nogal lomp zijn imho.

Voor de rest volg ik vich volledig in wat hier gezegd wordt.
Gebruik hashing ipv encryptie waar mogelijk.
K

Krueger

Legacy Member
killgore zei:
Valt goed mee. Wordt vaak gedaan om te controleren op corrupte downloads/isos/.... Alleen moet je het nu niet op immens grote bestanden gaan doen telkens als je programma opstart, zou nogal lomp zijn imho.

Voor de rest volg ik vich volledig in wat hier gezegd wordt.
Gebruik hashing ipv encryptie waar mogelijk.
Klik om te vergroten...
Hoe zie je dat dan concreet? Want zoiets als

if(MD5Hash(password) == eenBepaaldeString) then
Inorde
else
print("fout passwoord");

is ook niet bepaald veilig.
d

dJeez

Legacy Member
Als je een hoge mate van beveiliging wil kan je voor de communicatie met PostgreSQL best opteren voor een SSL verbinding (of connecteren via een SSH tunnel). Daarnaast kan je bepaalde kolommen in de DB ook via een functie library (vb. pgcrypto) gaan encrypteren. Nadeel van dat laatste is wel dat je kolommen dan BLOBs (BYTEA) moeten zijn, dus het is niet echt toepasbaar op kolommen waar je op wil zoeken of mee wil rekenen.

Verder gelden de algemene regels : geen makkelijk te raden username/paswoord combinaties gebruiken.
k

killgore

Legacy Member
Krueger zei:
Hoe zie je dat dan concreet? Want zoiets als

if(MD5Hash(password) == eenBepaaldeString) then
Inorde
else
print("fout passwoord");

is ook niet bepaald veilig.
Klik om te vergroten...
wat is daar onveilig aan?

Dat ze je string kunnen bruteforcen of zo?
K

Krueger

Legacy Member
killgore zei:
wat is daar onveilig aan?

Dat ze je string kunnen bruteforcen of zo?
Klik om te vergroten...
Dat niet, het passwoord kan je immers ook bruteforcen. Ik was eerder aan het denken in de richting van het decompileren van de java-code. Maar ofdat mogelijk is hangt natuurlijk af hoe het programma er uit komt te zien. (gedistribueerd/downloadbare class file met alles in/...)

Misschien moet de threadposter ook eens wat meer info geven hoe hij het juist ziet :)
k

killgore

Legacy Member
Zelfs al kan hij decompileren, dan heeft hij enkel nog maar de hash en moet hij die hash gaan bruteforcen voor hij het kan gebruiken...

Als je trouwens kan decompileren kan je evengoed je programmacode gaan herschrijven zonder die controle te gebruiken :p.
K

Krueger

Legacy Member
killgore zei:
Zelfs al kan hij decompileren, dan heeft hij enkel nog maar de hash en moet hij die hash gaan bruteforcen voor hij het kan gebruiken...

Als je trouwens kan decompileren kan je evengoed je programmacode gaan herschrijven zonder die controle te gebruiken :p.
Klik om te vergroten...
Programmacode herschrijven is niet altijd simpel. Zeker niet als deze door programma's vervormd is (kben de naam van die techniek ff kwijt)

Maar waarom nu juist een hash gebruiken, ipv het paswoord zelf?

In mijn ogen is bij gedistribueerde toepassingen het principe van publieke/private sleutel + een challenge redelijk veilig.
R

Robain

Legacy Member
Alrighty, eerst en vooral nen grote merci voor de vele nuttige replies! Kben ier weer volop aant bijleren :)


Eerst en vooral, hashing of encryptie, ik zou sowieso in het programma nog een lange, willekeurige string (20 tekens ofzo?) voor en na het paswoord plakken, en die string dan hashen of encrypten. Kwestie van dictionary attacks toch onmogelijk te maken.

Ik weet echter niet hoe gemakkellijk het is om een java class te decompilen?? Hoe kan ik dit tegengaan? (Bestaat er niet zoiets als javad ? )


@Krueger : Het programma zal niet echt widely verspreidt worden. Ik schat hooguit een tiental klanten, lokaal dan nog...

Om eerlijk te zijn is dit men eerste grote, "echte" programma dat ik ga maken...


@dJeez : SSL is veronderstel ik enkel voor als de database server op een andere pc draait zodat ze geen data via het netwerk zouden kunnen onderscheppen? Of sla ik hier de bal mis? In eerste instantie zou ik met een database werken die lokaal draait... Dit klinkt misschien een beetje paranoia, maar 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?


EDIT :
if(MD5Hash(password) == eenBepaaldeString) then
Inorde
else
print("fout passwoord");
Klik om te vergroten...
In dit geval zit tik toch weer met een hardcoded paswoord right??

Greetz
K

Krueger

Legacy Member
Java decompileren is zeer eenvoudig, met 1 klik kan je de broncode perfect lezen.
k

killgore

Legacy Member
Krueger zei:
Maar waarom nu juist een hash gebruiken, ipv het paswoord zelf?

In mijn ogen is bij gedistribueerde toepassingen het principe van publieke/private sleutel + een challenge redelijk veilig.
Klik om te vergroten...
omdat je het paswoord rechtstreeks kan gebruiken :s.

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 :p. Je kan dus in principe je hash zelfs public maken, aan te raden is het echter niet, net zoals je bij een public key encryptie je de key nu ook liefst binnenhoudt he :), je gaat het ze zeker niet makkelijker maken.


Bij:
if(pass == storedpass)
ben je onmiddelijk iets met storedpass.

Het voordeel van een hash tov encryptie: voor encryptiemethoden bestaan er altijd decrypties, zodra je de key weet (wat vaak niet te moeilijk is bij std methoden).
Een hash moet je dus bruteforcen (er zijn wel voor sommige hashes iets geadvanceerdere methodes die eigenlijk neerkomen door het inperken van je aantal af te lopen brute-force strings).

Zelfs al zou je kunnen zeggen dat een hash bruteforcen en een decryptiealgoritme zoeken in het slechtste geval even lang duren, met die bruteforce heb je meestal maar 1 pass, het decryptiealgoritme kan je overal toepassen.

edit: hardcoded pass heeft trouwens niets te maken met het systeem dat je gebruikt om dat pass te beveiligen!

edit2: @buize, wat bedoel je met financiële data? Als het te recupereren financiële data is kan je geen hashes gebruiken want die zijn niet omkeerbaar, zoals ik zei: "waar mogelijk".
B

BuiZe

Legacy Member
Ik heb inderdaad je "waar van toepassing" verkeerd geinterpreteerd denk ik :)
M

Messias.

Legacy Member
Als ge met hashes gaat werken zou ik toch nog een salt toevoegen. Challenge/response ftw. :)
R

Robain

Legacy Member
Okay, MD5 it is then :)


Maaar, nu zijn er nog steeds 2 grote vragen :
- Hoe sla ik die MD5-hash op zodat die nog aanpasbaar is maar niet gewoon kan vervangen worden door de hash van iemand die het programma wil kraken
- 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?

@ Messias : wat is een salt? :$


EDIT: na wat googlen heb ik een paar dingen gevonden om reverse engineering zo goed en zo kwaad mogelijk tegen te gaan. Zij bvb : http://www.javaworld.com/javaforums...r=20887&page=2&view=collapsed&sb=5&o=&fpart=1


Greetz
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan