Archief - [PROG]JAVA Programma beveiligen met paswoord

RipTor zei:

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.

Klik om te vergroten...

Weja, dat begrijp ik dus niet.

Kijk, alles staat lokaal op de pc, dus ook de data.
Als je de data zelf niet beveiligt, dan kan men toch aan de data ?
Men moet de data dus toch gaan encrypteren ?

Uiteindelijk draait een zelf gekozen passwoord eerder om het bewijs dat jij die user bent, dan om het beschermen van de data zelf.

Data moet je niet enkel kunnen encrypteren, maar natuurlijk ook decrypteren.
Je krijg dus twee algoritmes.
Een gewoon passwoord heeft niets te zien met die algoritmes.
Een sleutel kan daarentegen wel een onderdeel zijn van die algoritmes.

Dus stel je hebt een algoritme, die gebruikt maakt van een key (die een variabele is).
Als u key op uw hd staat, is dat toch kwetsbaar ?

Maar als je dat nu eens op een usb stick zet die key en je maakt in het programma een setup waar je de locatie kunt zetten van de key (dus de naam van de verwisselbare schijf) en dan steek je voor je het programma gebruikt uw usb stick in en wanneer je stopt terug de usb stick eruit halen.

Door de zware wiskunde die erachter zit (ontbinden in priemfactoren) is het onmogelijk om die key te vinden, zelfs met brute force.

Maar om op uw geval terug te keren. Alles wordt lokaal bewaard enkel het passwoord (dat de gebruiker uit zijn hoofd kent normaal gezien) niet.
Maar zoals ik al zei, die passwoorden hebben niets te maken met die algoritmes. Maw, alle info die de encrypteer en decrypteer algoritmes nodig hebben staan toch op de hd en dat is toch onveilig ?

Ik heb geen ervaring, dus ik kan zeker een fout maken in mijn redenering.

grtz

RipTor zei:

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

Klik om te vergroten...

ondertussen uw tweede post gelezen

Welja, ik denk niet dat mijn voorbeeld met usb stick (of bijhouden op papierke ofzo) te kraken is ? (indien sleutel lang genoeg)

Voor de data moet ge idd een encrypt/decrypt spul gebruiken (zoals blowfish). En dan moet ge idd een key opslaan ergens op een USB stick om veilig te zijn.

hellow iedereen, sorry voor de late reply. Tis nie dak topic vergeten was, ma was 2 dagen weg met de vriendin


Het is idd in eerste instantie mijn bedoeling om volledig lokaal te werken, hoewel ik het programma wel zo zal maken dat de deur daarvoor niet volledig dicht is...

De reden dat ik voor PostgreSQL opteerde was omdat dit door mijn prof aangegeven werd als een van de beste opensource db-systemen.

Feel free om dat te ontkrachten, want ik ken zelf niet veel db-systemen. Acces, MySQL en PostgreSQL, and that's about it Dus als jullie een beter systeem weten, please share


Het probleem met data encrypted opslaan is natuurlijk dat het wel zeer moeilijk wordt om query's uit te voeren daarop... Bestaat er een db systeem dat zelf die ecnryptie 'under the hood' voor zijn rekening neemt? Waardoor er dus bvb gedecrypteerd wordt vòòr het uitvoeren van query's.
Het zou de ideale oplossing zijn, zo'n systeem icm met een paswoord als sleutel of eventueel een usb stick... Maar het lijkt mij onwaarschijnlijk dat dit bestaat, het zou wss ongelooflijk traag gaan werken?? Het gaat wel maar over een database van 20.000-30.000 rijen maximum.


Greetz

Ik weet ook niets van die databases, maar je kunt toch crypteren en decrypteren in uw javaprogramma ?

bedoel je als je bv zoekt achter een bepaalde string (die geheim is), dat je deze niet kunt opzoeken omdat hij gedecrypteerd in de databank zit ?
Want dan decrypteer je eerst de string in uw programma en zoek je hem pas daarna.

(edit: efficientie gedeelte gewist aangezien et een vermoeden was. Over de efficientie als je al die rijen in één keer wilt ophalen heb ik geen idee.)

postgresql is een zeer goede keuze

.Acku. zei:

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.

Klik om te vergroten...

ff highlighten kwestie dat ik dit wel een ferm goeie raad vind

niet elke encryptie is te kraken hoor, das zever. Bij banken gebruiken ze ook encryptie. MD5 is ook geen goei oplossing als het lokaal is. Iedereen kan direct uw code decompileren en zien dat ge md5 gebruikt, zelf een programma schrijven en die op de db laten runnen, de md5 opvragen en dan de string laten berekenen, totaal niet veilig dus. Op de site van SUN staat er een boek over security. Ge kunt daar ook een framework downloaden speciaal voor uw probleem (JAAS).

http://java.sun.com/javase/technologies/security.jsp

Ma djeez, denkt iedereen echt dat een md5 string berekenen zo simpel is?
Heb je ooit al een md5 via brute-force proberen hacken, duurt een tijdje ze met een gewone thuispc.

En wel degelijk elke encryptie is te kraken, het moeilijkste is gewoon aan de key geraken.
edit: ik zeg niet dat md5 hier beste optie is ze (nu ek eindelijk doorheb wat bedoeling juist is ). Ma doe nu niet alsof md5 onmiddelijk te hacken is als je de geparsete waarde hebt, das dikke zever.

killgore zei:

Ma djeez, denkt iedereen echt dat een md5 string berekenen zo simpel is?
Heb je ooit al een md5 via brute-force proberen hacken, duurt een tijdje ze met een gewone thuispc.

En wel degelijk elke encryptie is te kraken, het moeilijkste is gewoon aan de key geraken.
edit: ik zeg niet dat md5 hier beste optie is ze (nu ek eindelijk doorheb wat bedoeling juist is ). Ma doe nu niet alsof md5 onmiddelijk te hacken is als je de geparsete waarde hebt, das dikke zever.

Klik om te vergroten...

Lol, een md5 bruteforcen op een gewoon pc'tje. Tenzij je op ingenieuze wijze een flaw hebt gevonden in het ontwerp van md5 waardoor je het aantal iteraties GRONDIG kunt beperken ben je voor eeuwig en altijd bezig met brute-forcen. Een andere MOGELIJKHEID, bij afwezigheid van een goeie salt, is kwetsbaarheid voor dictionary-attacks dmv rainbow-tables. Maar 'k zeg het: om een cryptografisch veilige one-way hash te kraken moet ge oftewel een genie zijn oftewel een botnet ter uwer beschikking hebben.

Case closed.

edit: Waarmee ik ook niet wil zeggen dat md5 the way to go is bij super top-secret government businesses, want het ontwerp bevat wel degelijk imperfecties. Maar voor een relatief kleinschalig programma met toekomstig publiek van een handvol is md5 (of zelfs een sha-derivaat) meer dan veilig genoeg.

Ter illustratie: Het distributed computingnetwerk van RC5 is al meer drie jaar bezig met het brute-force kraken van een 72bit (!) sleutel, tot dusver zijn ze nog maar aan 0,33% van alle mogelijke combinaties geraakt.

heel veilig ze manne :doh:, wie had het over kraken? Het nadeel aan MD5 is dat verschillende strings zelfde digest geven. Heb dat lang geleden al getest op een site waarin ge uw MD5 kon ingeven en die berekende dat dan in een cluster, minder dan een minuut later had ik een string die zelfde digest gaf als mijn paswoord.

http://nl.wikipedia.org/wiki/MD5

case closed


En ja ge kunt elke encryptie kraken, maar als ge assymetrische en symmetrische encryptie combineerd heeft een kraker maar een minimum van tijd voor een paswoord te vinden en kan dat dus NIET kraken, wel als hij meer tijd zou hebben maar das nu het geval niet.

jodeman zei:

Heb dat lang geleden al getest op een site waarin ge uw MD5 kon ingeven en die berekende dat dan in een cluster,

Klik om te vergroten...

Niks te berekenen, dat zijn rainbow tables (kheb het hier nog maar honderd keer gezegd ofzo). Ongelooflijk veel strings met bijhorende hash in een tabel duwen en dan da hash opzoeken en de string weergeven. Gebruik salt en geen last meer van.

En bij élk hash-algoritme zijn er collisions. Aangezien md5 een 128bit hash uitspuwt heb je gegarandeerd een collision na 2^64 keer proberen. Door een aantal imperfecties in het ontwerp valt dit terug te brengen naar 2^48 hashes [1]. Natuurlijk is er ook een heel kleine kans dat ge een collision hebt binnen veel minder tijd, maarja.

Wikipedia zei:

MD5 is widely used to store passwords. A number of MD5 reverse lookup databases exist, which make it easy to decrypt password hashed with plain MD5. To prevent such attacks you can add a salt to your passwords before hashing them. Also, it is a good idea to apply the hashing function (MD5 in this case) more than once—see key strengthening.
[2]

Klik om te vergroten...

Bovendien heb ik nooit gezegd dat md5 suuuuperveilig is, integendeel, ik sprak zelfs tegen dat het the way to go was bij super-beveiligde dingen (zoals bankgegevens). Maar voor deze toepassing is het VEILIG GENOEG. En bovendien wil ik u wel eens nen md5-hash geven, wedden dat ge nooit van uw leven gaat achterhalen wat het origineel was?

Jij doet alsof je over nacht wel eens een md5 hashke kan kraken, dream on.

Ja der gaan altijd oplossingen komen voor bepaalde problemen he, ik had het over gewoon MD5 wat over het algemeen het meetste gebruikt wordt.
En wie heeft het over het origineel? Een string met zelfde collision is al goed genoeg. Ik weet wat ik gezien heb en dacht ook dat het zever was maar ik had toch wel een string en veel te snel.
Nog een zwakheid van hashen is de sterkte van het paswoord. Hoe beter uw paswoord hoe moeilijker te vinden.