-
23-06-2006, 15:59 #31Member
- Registered
- 12/10/02
- Location
- mars
- Posts
- 14,319
- iTrader
- 2 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 0/0
no votes
-
-
23-06-2006, 17:04 #32
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.
Voor crypt bestaat er geen decryptie algoritme.Het voordeel van een hash tov encryptie: voor encryptiemethoden bestaan er altijd decrypties
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 hierbovenLast edited by RipTor; 23-06-2006 at 17:10.
no votes
-
23-06-2006, 18:33 #33Member
- Registered
- 06/04/06
- Location
- BXL
- Posts
- 4,415
- iTrader
- 1 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 2/40
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.
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.Last edited by Messias.; 23-06-2006 at 18:39.
I caught a glimpse and now it haunts me.no votes
-
23-06-2006, 18:37 #34Member
- Registered
- 20/09/04
- Location
- Kortrijk / Gent
- Posts
- 7,177
- iTrader
- 1 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 3/43
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.
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).Last edited by MilM; 23-06-2006 at 19:26.
no votes
-
23-06-2006, 19:47 #35Member
- Registered
- 17/07/02
- Location
- Sol System
- Posts
- 10,064
- iTrader
- 1 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 27/78
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).PSN: dJeezBE - Delicious bookmarks
Disclaimer: I am currently suffering from severe CSD (Compulsive Sarcasm Disorder). - L'onion fait la farce - Facile largire de alienoPastafarian by choiceno votes
-
23-06-2006, 20:08 #36Member
- Registered
- 20/09/04
- Location
- Kortrijk / Gent
- Posts
- 7,177
- iTrader
- 1 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 3/43
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)no votes
-
23-06-2006, 21:58 #37
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?
no votes
-
23-06-2006, 22:28 #38Member
- Registered
- 20/09/04
- Location
- Kortrijk / Gent
- Posts
- 7,177
- iTrader
- 1 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 3/43
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
)
no votes
-
23-06-2006, 23:15 #39
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.no votes
-
23-06-2006, 23:20 #40
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.no votes
-
23-06-2006, 23:25 #41Member
- Registered
- 20/09/04
- Location
- Kortrijk / Gent
- Posts
- 7,177
- iTrader
- 1 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 3/43
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.
grtzno votes
-
23-06-2006, 23:28 #42Member
- Registered
- 20/09/04
- Location
- Kortrijk / Gent
- Posts
- 7,177
- iTrader
- 1 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 3/43
no votes
-
24-06-2006, 10:07 #43
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.
no votes
-
25-06-2006, 14:49 #44Member
- Registered
- 03/03/04
- Location
- Blankenberge/Gent
- Posts
- 1,105
- iTrader
- 7 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 0/0
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.
Greetzno votes
-
25-06-2006, 15:05 #45Member
- Registered
- 20/09/04
- Location
- Kortrijk / Gent
- Posts
- 7,177
- iTrader
- 1 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 3/43
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.)Last edited by MilM; 25-06-2006 at 15:24.
no votes
.
