Heeft RC4 uberhaupt wel zin..!?

[Verwijderd]

Ik ben bezig met de data in mijn db encrypted op te slaan (rc4 keys...)

maar voor het encrypten heb je een key nodig... en mijn asp pagina's moeten daarbij kunnen... dus al een hacker bij de db wil moet hij het systeem hacken, en heeft hij dus ook toegang tot die key, dan heeft het niet zo heel veel zin om het te encrypten toch..!?

of moet ik het op een andere manier aanpakken..?!

[ACM]

Niet elke encryptie is bedoeld voor permanente opslag en het is natuurlijk helemaal niet de bedoeling dat je je key's _bij_ je data opslaat...

Als je die key "niet" kan opslaan of iig ergens anders zou dat al een hoop schelen, waarom moet je data trouwens encrypted in je database??

[Glimi]

wat wil je encrypten in je db dan? Is dat niet gewoon te hashen? Als het niet te hashen is, omdat je het nog terug wilt kijgen later, maar het is te privacy gevoelig om plain te laten staan (bijv een creditcard nummer) dan kun je er ook voor kiezen het NIET op te slaan!

Bedenk trouwens wel dat om onbedoelde geheime gegevens uit de db te toveren men niet uw systeem hoeft te hacken. Dat kan net zo goed door jouw ASP pagina's malformed variabels mee te geven (bijv ; in een var die direct in de sql query gaat)

[Verwijderd]

Glimi schreef op 15 augustus 2002 @ 12:54:
wat wil je encrypten in je db dan? Is dat niet gewoon te hashen? Als het niet te hashen is, omdat je het nog terug wilt kijgen later, maar het is te privacy gevoelig om plain te laten staan (bijv een creditcard nummer) dan kun je er ook voor kiezen het NIET op te slaan!

Bedenk trouwens wel dat om onbedoelde geheime gegevens uit de db te toveren men niet uw systeem hoeft te hacken. Dat kan net zo goed door jouw ASP pagina's malformed variabels mee te geven (bijv ; in een var die direct in de sql query gaat)

ja daar heb ik al aangedacht, dat is allemaal superdicht beveiligd...

HTMLEnocde + isNaN voorkomt iig al dat de id's worden verkracht, voor de rest geen cross site scripting

maar het gaat om data die in een afgelsoten omgeving (intranet bv) te zien moet zijn, geheim is, maar toch op een internetserver staat..

deze situatie kan onmogelijk anders, dus dan maar zo goed mogelijk beveiligen...

maar als een hacker root toegang heeft dan wil ik dat ie niet meteen in de DB zit... dus encrypten, maar hoe decrypten, als hij toch roottoegang heeft kan hij net zogeod de key gewoon uit de aspcode halen....

en ja je moet er van uitgaan dat een hacker root toegang krijgt tot de server...

ik herinner me dat et met tweakers ook al n keer is gebeurd.. dus bij mij moet et ook kunnen, helaas....

[Glimi]

Welke db draai je? Want als iemand root heeft, is er ECHT geen houden meer aan imho

edit:

MySQL server en dan secure data? Uhm ik kan toch gewoon de db files kopieëren (in /var/lib/mysql/ ) en die naar mijn eigen MySQL server gooien en daar als root inloggen? of zie ik dat nou verkeerd?

[Verwijderd]

mag ik zelf nog kiezen, denk dat ik gewoon voor mysql -- postgre ga of zoiets, nog niet echt in verdiept, werkt nu in een tijdelijke test omgevening met access maar dat zal geen productieserver worden, maar die is nog niet beschikbaar...

[Erik Jan]

mabit:
maar het gaat om data die in een afgelsoten omgeving (intranet bv) te zien moet zijn, geheim is, maar toch op een internetserver staat..

In zo'n geval plaats je de key niet op de server (die gehackt kan worden), maar je plaatst de key op de computers van de clients (in jouw geval dus een proggie waar de key ingebakken zit dat contact opneemt met de server en de binnengehaalde data decrypt).

De kans dat een hacker het systeem van een client opspoort en hackt is kleiner (SSL, dynamisch IP etc.). Let er wel op dat je werknemers goed omgaan met de decrypt-applicatie, en het dus niet per ongeluk delen met KaZaA ofzo

[Verwijderd]

nee dat is geen optie, want ik heb geen controle over de clients... ik weet niet wie heet precies zijn... iedereen die in een netwerk zit moet er bij kunnen....

[xshredx]

Bestaat er iets gelijkaardigs als de Zend Encoder voor asp?
Voor zover ik op de hoogte ben is het niet mogelijk om uit ge-encode php files de oorspronkelijke code te halen. Zou het dan geen goed idee zijn om bv. de key in een ge-encodeerde file te stoppen? De key kan niet meer teruggehaald worden uit de file die op je server staat, maar die ge-encodeerde file kan wel gewoon uitgevoerd worden.
Dit alles natuurlijk in de veronderstelling dat er zo'n Encoder programmas bestaan voor asp.

[Verwijderd]

xshredx schreef op 15 augustus 2002 @ 17:35:
Bestaat er iets gelijkaardigs als de Zend Encoder voor asp?
Voor zover ik op de hoogte ben is het niet mogelijk om uit ge-encode php files de oorspronkelijke code te halen. Zou het dan geen goed idee zijn om bv. de key in een ge-encodeerde file te stoppen? De key kan niet meer teruggehaald worden uit de file die op je server staat, maar die ge-encodeerde file kan wel gewoon uitgevoerd worden.
Dit alles natuurlijk in de veronderstelling dat er zo'n Encoder programmas bestaan voor asp.

ik zal t eens opzoeken, iig bedankt voor de tip... alleen is de vraag hoe goed die beveiliging is...

[Verwijderd]

dat heeft dus ook al niet echt heel veel zin, aangezien *hacker* dan zelf een script kan schrijven met behulp van de code... het komt er op neer denk ik dat het nooit uitgesloten is dat een hacker toegang krijgt...

als een asp pagina de gegevens kan encrypten, en een hacker kan bij die asp pagina's, dan kan een hacker de gegevens ook encrypten...

dan maar linux zo goed mogelijk beveiligen...

is die how to van linux.org een beetje betrouwbaar..?!

[Sponge]

Even een beetje offtopic, de RC4 key was toch gekraakt met Distributed DC? Betekend dat nou dat ze een alles kunnen decrypten nu (met die key), of niet? Ik twijfel daar over nu ik de topic titel lees..

[ACM]

Nee, je moet elke key apart kraken...
Wat dnetc deed was zelfs erg zinloos wat dat betreft, aangezien ze gewoon alle keys die er zijn probeerden en daardoor eigenlijk een hoop werk voor niks gedaan hebben, zonder dat ze nou ineens de volgende keer een stuk data sneller kunnen kraken.

[Verwijderd]

Als jij een manier waarop GEEN ÉÉN hacker bij je gegevens kan komen dan ga je daar best wel wat centjes mee verdienen hoor ...

[Sponge]

ACM schreef op 15 augustus 2002 @ 19:28:
Nee, je moet elke key apart kraken...
Wat dnetc deed was zelfs erg zinloos wat dat betreft, aangezien ze gewoon alle keys die er zijn probeerden en daardoor eigenlijk een hoop werk voor niks gedaan hebben, zonder dat ze nou ineens de volgende keer een stuk data sneller kunnen kraken.

Bedankt . Ik had net zo m'n twijfels daarover of het nog wel veilig was om het te gebruiken.


_{Humm, dan is RC5 ook nutteloos (ze zitten nou over 80% van alle mogelijkheden), kunnen ze beter met folden bezig gaan. Vaag waarom er dan zoveel interesse is, omdat het dus geen enkele nut heeft.}

[ACM]

41.6C.6D.61.72 schreef op 15 augustus 2002 @ 19:44:

_{Humm, dan is RC5 ook nutteloos (ze zitten nou over 80% van alle mogelijkheden), kunnen ze beter met folden bezig gaan. Vaag waarom er dan zoveel interesse is, omdat het dus geen enkele nut heeft.}

Klopt, en zelfs dan nog....

Na 2 jaar ofzo is allang bewezen dat RC5 voorlopig nog wel veilig genoeg is
Als heel de dnetc-ploeg er al zolang over doet (en een meer wetenschappelijke oplossing kostte ook nog dik 3 maanden).

[MSalters]

Verwijderd schreef op 15 augustus 2002 @ 19:38:
Als jij een manier waarop GEEN ÉÉN hacker bij je gegevens kan komen dan ga je daar best wel wat centjes mee verdienen hoor ...

Server in kluis, deur dicht. Sim-pel.

Het probleem van servers is nou juist dat er gebruikers op willen, en die zijn zoals bekend de grootste lekken. Het is voor een PC gewoon lastig om gebruikers te onderscheiden. Je kunt het doen op basis van wat iemand weet, heeft of is: respectievelijk bv password, keycard of biometrie.

Terug on topic: als je een softwarematige client wil identificeren, dan moet dat dus op basis van wat deze client weet. Als je dan ook nog eens aanneemt dat een hacker na een aanval op zo'n client alles weet, dan ben je dus zuur, dan heb je geen identificatie mogelijkheden.

Als je daarentegen aanneemt dat de server aangevallen wordt, maar dat de clients (waar de kennis beschikbaar is) veilig zijn, dan moet je public/private crypto gebruiken met de public key op de server. Versleutel alle data met de client's private key en je bent klaar.