[php] Encryptie/decryptie

[Anoniem: 32412]

Voor een website met financiële gegevens moet ik de database coderen. De website draaid op php, de database mysql (onbelangrijk). Ik heb de volgende functies gemaakt om een string te encrypten, maar het werkt niet goed, ik krijg namelijk steeds iets anderes terug als ik een geencryote string decrypt.

Hoe kan ik het het beste aanpakken? Thanks!

PHP:

<?php

function encrypt($data) {

    // Open the cipher */
    $td = mcrypt_module_open('rijndael-256', '', 'ofb', '');
    // Create the IV and determine the keysize length, used MCRYPT_RAND 
    $iv = mcrypt_create_iv(mcrypt_enc_get_iv_size($td), MCRYPT_DEV_RANDOM);
    $ks = mcrypt_enc_get_key_size($td);
    //the key
    $key = substr(md5('mkcgxpqfy8'), 0, $ks);

    /* Intialize encryption */
    mcrypt_generic_init($td, $key, $iv);
    
    /* Encrypt data */
    $encrypted = mcrypt_generic($td, $data);
    
    /* Terminate encryption handler */
    mcrypt_generic_deinit($td); 
    mcrypt_module_close($td);
    
    return $encrypted;
}

function decrypt($data) {
// Open the cipher */
    $td = mcrypt_module_open('rijndael-256', '', 'ofb', '');
    // Create the IV and determine the keysize length, used MCRYPT_RAND 
    $iv = mcrypt_create_iv(mcrypt_enc_get_iv_size($td), MCRYPT_DEV_RANDOM);
    $ks = mcrypt_enc_get_key_size($td);
    //the key
    $key = substr(md5('mkcgxpqfy8'), 0, $ks);

    /* Initialize encryption module for decryption */
    mcrypt_generic_init($td, $key, $iv);
    
    /* Decrypt encrypted string */
    $decrypted = mdecrypt_generic($td, $data);
    
    /* Terminate decryption handle and close module */
    mcrypt_generic_deinit($td);
    mcrypt_module_close($td);
    
    return $decrypted;
}
?> 

[HunterPro]

waarom de database encoden? Zou je niet beter iets aan security van je systeem doen? Of bijv in het geval van een windows server, de directory met de SQL datafiles als encrypted flaggen?

[ Voor 38% gewijzigd door HunterPro op 14-08-2004 15:09 ]

[Twilight Burn]

Als ik de code zo zie wordt er bij het encrypten en decrypten steeds een random "IV" gegenereert. Voor zover ik het weet moet je bij het decrypten de zelfde "IV" waarde gebruiken als bij het encrypten.

[simon]

HunterPro schreef op 14 augustus 2004 @ 15:08:
waarom de database encoden? Zou je niet beter iets aan security van je systeem doen? Of bijv in het geval van een windows server, de directory met de SQL datafiles als encrypted flaggen?

Inderdaad, nu vertraag je je systeem als de ***. Je moe gewoon je connecties/systeem veilig houden, en zorgen dat er geen lekken onstaan.

Data van het crewforum hier wordt ook niet versleutelt, en reken maar dat je daar echt niet zomaar bijkomt (tenzij je een of andere mod een gulle gift geeft...)

[HunterPro]

Twilight Burn schreef op 14 augustus 2004 @ 15:11:
Als ik de code zo zie wordt er bij het encrypten en decrypten steeds een random "IV" gegenereert. Voor zover ik het weet moet je bij het decrypten de zelfde "IV" waarde gebruiken als bij het encrypten.

met andere woorden als je het script hebt, waarop je dikke kans hebt op het moment dat je bij de datafiles van SQL kan, is je beveiliging gebroken. Lijkt me niet echt the way to go

[HunterPro]

Simon schreef op 14 augustus 2004 @ 15:14:
[...]


Inderdaad, nu vertraag je je systeem als de ***. Je moe gewoon je connecties/systeem veilig houden, en zorgen dat er geen lekken onstaan.

Data van het crewforum hier wordt ook niet versleutelt, en reken maar dat je daar echt niet zomaar bijkomt (tenzij je een of andere mod een gulle gift geeft...)

denk zelfs dat banksystemen geen encrypted grappen hebben; is het allemaal veel te log en groot voor. Je komt echter nooit via ruwe SQL bij de gegevens waardoor je altijd alleen maar mag zien wat jou door je meerdere is toebedeeld

[simon]

HunterPro schreef op 14 augustus 2004 @ 15:14:
[...]

met andere woorden als je het script hebt, waarop je dikke kans hebt op het moment dat je bij de datafiles van SQL kan, is je beveiliging gebroken. Lijkt me niet echt the way to go

Of als de source uitlekt. Dan weten ze hoe ze 't moeten decrypten. Dan heeft het helemaal geen nut meer.

[Anoniem: 32412]

De sql server staat niet in mijn beheer, noch de verbinding met de webserver. Naast dat ik het script heb geencodeerd met zend bedenk ik nog wel een leuk trucje dat een password vereist dmv inloggegevens en wachtwoorden ed, zodat de sleutel niet letterlijk in het script staat. En er zijn meer mensen die toegang hebben tot de sql server, dat kan ik niet veranderen.

[Anoniem: 74706]

base64_encode en base64_decode?

en die string dan ook nog eens omkeren met strrev()

is een simpele, niet de meest veilige oplossing, maar het is tenminste wat

[ripexx]

Anoniem: 74706 schreef op 14 augustus 2004 @ 15:42:
base64_encode en base64_decode?

en die string dan ook nog eens omkeren met strrev()

is een simpele, niet de meest veilige oplossing, maar het is tenminste wat

Even een reactie: Liever geen beveiliging dan een vals gevoel van beveiliging (die dus niet werkt).

1) Waarom je database encrypten
2) Beveiling is niet het zelfde als encryptie

Anoniem: 32412 schreef op 14 augustus 2004 @ 15:23:
De sql server staat niet in mijn beheer, noch de verbinding met de webserver. Naast dat ik het script heb geencodeerd met zend bedenk ik nog wel een leuk trucje dat een password vereist dmv inloggegevens en wachtwoorden ed, zodat de sleutel niet letterlijk in het script staat. En er zijn meer mensen die toegang hebben tot de sql server, dat kan ik niet veranderen.

Als jij de verbinding tussen de database en de webserver al niet kan garranderen en ook niet over het beheer van de servers gaat ben je niet echt slim bezig. Dit soort workarounds hebben dan toch geen nut.

Sorry maar dit klink als ik wil beveiliging en het moet goed maar het mag niets kosten en we hebben daar nog wel wat ruimte op ene hosting accountje. Beveiling begint gewoonbij de basis (OS, filesystem, netwerk etc) en niet bij dataencryptie.

[ Voor 52% gewijzigd door ripexx op 14-08-2004 17:02 ]

[HunterPro]

Anoniem: 32412 schreef op 14 augustus 2004 @ 15:23:
De sql server staat niet in mijn beheer, noch de verbinding met de webserver. Naast dat ik het script heb geencodeerd met zend bedenk ik nog wel een leuk trucje dat een password vereist dmv inloggegevens en wachtwoorden ed, zodat de sleutel niet letterlijk in het script staat. En er zijn meer mensen die toegang hebben tot de sql server, dat kan ik niet veranderen.

als jij dit script zend lees ik zonder problemen al je keys uit en decodeer ik alles met liefde voor je.

[Anoniem: 32412]

waarom is het wel normaal dat je passwords hashed in de database, maar wat vertrouwelijke gegevens niet? En of het nou wel of niet handig is, dat is helemaal niet mijn vraag. Ik wil alleen maar weten wat een handige manier is om een string te encrypten.

HunterPro schreef op 15 augustus 2004 @ 01:32:
[...]

als jij dit script zend lees ik zonder problemen al je keys uit en decodeer ik alles met liefde voor je.

gelul. Maar ik wil wel een gokje wagen: Decompile deze maar eens:

http://www.xs4all.nl/~gebral/index.php.txt

succes!

[pierre-oord]

Anoniem: 32412 schreef op 15 augustus 2004 @ 11:46:
waarom is het wel normaal dat je passwords hashed in de database, maar wat vertrouwelijke gegevens niet? En of het nou wel of niet handig is, dat is helemaal niet mijn vraag. Ik wil alleen maar weten wat een handige manier is om een string te encrypten.


[...]


gelul. Maar ik wil wel een gokje wagen: Decompile deze maar eens:

http://www.xs4all.nl/~gebral/index.php.txt

succes!

Je passwords in een database zetten gaat eigenlijk altijd met MD5 afaik? En MD5 gaat maar 1 kant op, vraag me niet hoe het werkt, maar je kunt van password > MD5 passwd, dus van password input > MD5 passwd en die 2 dan vergelijken, maar je kunt nooit van MD5 passwd > passwd.
Voor een site met database is dit niet erg handig wat je kunt alles wat je erin stopt dus nooit meer eruit halen.

Overigens denk ik dat de topicstarter wel een aardig idee heeft. Het blijft zo dat als het script uitlekt het mis loopt, je moet dus eigenlijk je website niet op een server zetten van een 3e partij, maar op je eigen machine, of iig het gedeelte wat de database uit gaat lezen. Als je dan alles gecodeerd in een database stopt, kan niemand er nog wat mee, lijkt me.

edit:
Zoals de persoon hierboven aangeeft is trouwens het encoden van je script met zend ook een leuk plan, dan kan die wel op je webhosters locatie staan, zorg dan gewoon enkel dat je eigen pc niet wordt gehacked.

Zend is niet gratis, ik weet niet of er nog gratis tools bestaan?

[ Voor 11% gewijzigd door pierre-oord op 15-08-2004 12:11 ]

[crisp]

HunterPro schreef op 14 augustus 2004 @ 15:15:
[...]

denk zelfs dat banksystemen geen encrypted grappen hebben; is het allemaal veel te log en groot voor. Je komt echter nooit via ruwe SQL bij de gegevens waardoor je altijd alleen maar mag zien wat jou door je meerdere is toebedeeld

Inderdaad, uit ervaring kan ik mededelen dat de uiteindelijke klant-, transactie- en andere gegevens bij banken unencrypted zijn opgeslagen (muv eventuele wachtwoorden); echter is daar wel alle communicatie van en naar externe systemen encrypted, meestal met SSL maar vaak is ook de inhoud van bepaalde gegevens nog op een andere manier geencrypt en worden er check-hashes gegenereerd en meegestuurd.
Regel nummer 1 is fysieke afscheiding van backend databases, business logic en frontend mbv DMZ's en firewalls.

[Zoijar]

Begrijp ik nou goed dat het punt is dat de SQL server en webserver van 3en is, en je niet wilt dat die de data kunnen lezen? Dus met encryptie wil je dit scenario implementeren:

(gebruiker slaat gevoelige data op, credit card nummer oid)
client form -> internet lijn -> webserver -> php encrypt -> lan lijn(e) -> sql server(e)

Alles voor php encrypt kan hier zonder moeite credit card nummers uitlezen. False sense of security dus. Aangezien alleen de administrator waarschijnlijk op de sql server jouw tabellen kan lezen (user roles en permissions etc) kan hij ook waarschijnlijk wel die lijn uitlezen.

(gebruiker ontvangt gevoelige data)
sql server(e) -> lan lijn(e) -> webserver(e) -> phpdecrypt -> internet lijn -> client

Nu kan iedereen op de route van server naar client de data ook lezen.

Toegegeven dat encryptie het wel iets moelijker maakt, maar dus niet veiliger.

(Als gebruikers alleen hun eigen data kunnen lezen/opslaan, dan kan je met rsa encryptie en javascript het wel veilig maken. Ter hoogte van de client computer in ieder geval)

[ Voor 12% gewijzigd door Zoijar op 15-08-2004 14:59 ]

[Anoniem: 15252]

pierre-oord schreef op 15 augustus 2004 @ 11:59:
[...]
Je passwords in een database zetten gaat eigenlijk altijd met MD5 afaik? En MD5 gaat maar 1 kant op, vraag me niet hoe het werkt, maar je kunt van password > MD5 passwd, dus van password input > MD5 passwd en die 2 dan vergelijken, maar je kunt nooit van MD5 passwd > passwd.

een kleine complicatie is dat MD% hashes natuurlijk wel terug te *rekenen* zijn. Tegenwoordig zijn er al sites waar een database aanhangt met een hele reekst berekende hashwaardes. Kijk es op passcracking.com Volgens mij hebben ze daar alle hashes tot aan pw's met 8 characters voor letters/getallen staan. Voer een hash in, en je krijgt het wachtwoord
Dit probleem valt grotendeels te ondervangen door een zogeheten salt toe te voegen aan het pw, VOORDAT je de hash berekent. Je zet je salt en het gehashte pw+salt i je db, en terugrekenen wordt een stuk lastiger (las van de week iets opmsdn, maar heb even geen link voorhanden; sorry)

[Zoijar]

Anoniem: 15252 schreef op 15 augustus 2004 @ 16:47:
een kleine complicatie is dat MD% hashes natuurlijk wel terug te *rekenen* zijn. Tegenwoordig zijn er al sites waar een database aanhangt met een hele reekst berekende hashwaardes. Kijk es op passcracking.com Volgens mij hebben ze daar alle hashes tot aan pw's met 8 characters voor letters/getallen staan. Voer een hash in, en je krijgt het wachtwoord
Dit probleem valt grotendeels te ondervangen door een zogeheten salt toe te voegen aan het pw, VOORDAT je de hash berekent. Je zet je salt en het gehashte pw+salt i je db, en terugrekenen wordt een stuk lastiger (las van de week iets opmsdn, maar heb even geen link voorhanden; sorry)

Dat is geen zwakheid van md5, dat is brute force password cracken. En dan kan je idd op die manier doen als je de md5 hashes van alle wachtwoorden hebt. Als je er dan een groot aantal woordenboeken en combinaties overheen gooit vind je vanzelf wel een user met een slecht password. Daarom wordt op unix systemen de /etc/password file ook geshadowed tegenwoordig. En de salt is om die rede ook toegevoegd om het langer te laten duren.
Maar je kan nog steeds geen md5 omkeren, omdat dat uberhaupt niet mogelijk is. Je kan misschien met veel moeite wel een passphrase vinden die naar dezelfde key hashed, maar dat hoeft alsnog niet je originele password te zijn. (maar werkt wel, iedereen heeft ook meerdere passwords die werken)

[Anoniem: 26306]

Anoniem: 15252 schreef op 15 augustus 2004 @ 16:47:
[...]

een kleine complicatie is dat MD% hashes natuurlijk wel terug te *rekenen* zijn. Tegenwoordig zijn er al sites waar een database aanhangt met een hele reekst berekende hashwaardes. Kijk es op passcracking.com Volgens mij hebben ze daar alle hashes tot aan pw's met 8 characters voor letters/getallen staan. Voer een hash in, en je krijgt het wachtwoord
Dit probleem valt grotendeels te ondervangen door een zogeheten salt toe te voegen aan het pw, VOORDAT je de hash berekent. Je zet je salt en het gehashte pw+salt i je db, en terugrekenen wordt een stuk lastiger (las van de week iets opmsdn, maar heb even geen link voorhanden; sorry)

Reken mee.
Laten we even stellen dat een character in 1 byte wordt opgeslagen, dus 8 bits. Er zijn dus 64 bits nodig om een wachtwoord op te slaan, en nog eens 128 bits voor de md5 hash. Dus 192 bits per password/hash combinatie. Er zijn 256⁸ combinaties mogelijk. Vermenigvuldig dat met 192, en je hebt dus 3541774862152233910272 bits nodig om alle combinaties op te slaan. Dat is 442721857769029238784 bytes = 442.7 EiB nodig om het spul kwijt te kunnen. Ik gok dat zij dat niet in een database hebben staan. Ok, in de praktijk zul je iets lager zitten omdat niet alle tekens worden gebruikt in wachtwoorden, maar vergis je niet in de schaal van het aantal mogelijkheden.

[Zoijar]

Anoniem: 26306 schreef op 15 augustus 2004 @ 17:14:
...

Je moet wel ook nog rekening houden met 'het verjaardags probleem', effectief geeft dat je in verwachting maar de wortel van het aantal mogelijkheden. Maar dat is idd alsnog astronomisch.

[Anoniem: 15252]

ik begrijp heel goed dat het bij een hash om precomputed computation gaat ==> vantevoren neem je 'password1', berekent de hash, '7c6a180b36896a0a8c02787eeafb0e4c'. Kom je ooit deze hash tegen, dan weet je dat het om 'password1' gaat, of om een collision. Het maakt voor de cracker natuurlijk niet uit, als het maar werkt.

Ben maar eens even naar die site gegaan die ik hierboven noemde. De techniek erachter (zie http://www.antsight.com/zsl/rainbowcrack/rcracktutorial.htm) is wel degelijk gebaseerd op zogenaamde Rainbow tables waarin vantevoren berekende combinaties van passes en hashes. Er hangt een tabel van 47.6 GB achter voor alle combinaties van kleine letters en cijfers (=36 mogelijke chars). Dat zijn 36^8 + 36^7 +....+36^1 combinaties. Ik kom dan op ruim 2 TB aan combinaties uit, dus dat correspondeert niet helemaal met die database. Maar het is dus niet letterlijk zo dat alle combi's rechtstreeks in die tables staan, maar dat daar allerlei optimalisaties achter zitten.

[mrBussy]

Voor de TS: MD5 Encryptie is een One-Way-Encryption. Dit houdt in dat het alleen maar geencrypt kan worden. Dit is bijvoorbeeld handig bij het opslaan van wachtwoorden. Deze zijn dan niet meer te achterhalen.

Voor de mogelijkheid om gegevens weer terug te halen dien je dus te kijken naar een Two-Way-Encryption. Denk hierbij bijvoorbeeld aan RSA encryptie. Deze kan gebruikt worden om gegevens te encrypten en decrypten. Ook DES of Tripple-DES behoord dan tot de mogelijkheden.

Voor alle andere reacties. De TS had niet de vraag of het de juiste methode is. Er zijn waarschijnlijk veel slimmere en betere oplossingen te bedenken, maar als hij dat wilde weten had hij er wel om gevraagd.

----------------------------
Oeps... mrBussy was a bit sleepy .... Er wordt gebruik gemaakt van 'rijndael-256' en niet van MD5... Foutje...

[ Voor 10% gewijzigd door mrBussy op 16-08-2004 09:19 . Reden: Sleeping ]

[Anoniem: 32412]

erg leuke discussie over one-way. Maareuh mag ik misschien voorzichtig aankaartten dat op mijn probleem, een string encrypten - decrypten met php, nog steeds niet is ingegaan?

edit:

Oh C1000, ik waht met spanning af

[ Voor 12% gewijzigd door Anoniem: 32412 op 16-08-2004 11:00 ]

[Zoijar]

Anoniem: 32412 schreef op 16 augustus 2004 @ 10:59:
erg leuke discussie over one-way. Maareuh mag ik misschien voorzichtig aankaartten dat op mijn probleem, een string encrypten - decrypten met php, nog steeds niet is ingegaan?

Je hebt al gekeken naar die salt die je twee keer random maakt? (zoals boven iemand al opmerkte) ($iv)

[hobbit_be]

One-Time-Pad encryptie is al sinds de eerste dag quasi (if at all) [edit:] ON breekbaar. Je zult dan op een of andere manier wel de keys moeten doorgeven (wat dan weer kan met de laatste message in je comm). Dan mogen je luisteraars nog alles kunnen lezen, als je values deftig random zijn kunnen ze der toch nooit iets mee aanvangen. De allereerste transfer van variable kun je het beste in person doen .

Snap zelf niet waarom het niet meer gebruikt word.

edit:
hmm heeft natuurlijk weinig te maken met het eigenlijke probleem maar wel het het veilig doorsturen van info naar je server

[ Voor 16% gewijzigd door hobbit_be op 16-08-2004 12:10 ]

[Zoijar]

hobbit_be schreef op 16 augustus 2004 @ 12:08:
Snap zelf niet waarom het niet meer gebruikt word.

Omdat het maar een keer (goed) werkt...en het is niet zo fijn om steeds in persoon data naar irak te brengen.

[Twilight Burn]

Twilight Burn schreef op 14 augustus 2004 @ 15:11:
Als ik de code zo zie wordt er bij het encrypten en decrypten steeds een random "IV" gegenereert. Voor zover ik het weet moet je bij het decrypten de zelfde "IV" waarde gebruiken als bij het encrypten.

Ik weet niet of je dat ^^ al geprobeerd hebt?

Misschien is het slimmer (veiliger) om gebruik te maken van een a-symmetrisch algoritme (zoals RSA) en dan de decryptie-sleutel niet expliciet in de source te zetten.

[edit/toevoeging]
One-Time-Pads (OTP) vereisen (voor goede veiligheid) dat de sleutel (pad) over een "veilig kanaal" naar de andere partij wordt gebracht. Hierna kan er over een "onveilig kanaal" (bv internet) gebruik worden gemaakt van deze sleutel. Echter in de meeste situaties kun je dan net zo goed het bericht over dat "veilige kanaal" doorgeven, en heb je geen encryptie nodig.
Een ander nadeel van een OTP is dat de sleutel net zo lang, of langer moet zijn dan het te versturen bericht.
Quantum-encryptie is trouwens wel gebaseerd op het OTP.

[ Voor 36% gewijzigd door Twilight Burn op 16-08-2004 12:36 ]

[hobbit_be]

offtopic:
[quote]Twilight Burn schreef op 16 augustus 2004 @ 12:31:
[...]

Een ander nadeel van een OTP is dat de sleutel net zo lang, of langer moet zijn dan het te versturen bericht.
[/quote]

Dit laatste was mij onbekend (tot nu) wat het doorgeven van de nieuwe key idd onmogelijk maakt om de getallen (de key) door te geven (aangezien alle data dan nodig zou zijn voor het doorgeven van de key) en er dus niets overblijft voor eigenlijke data.

Bedenk ik dat als je twee kanalen gebruikt dit echter wel zou kunnen. 1 puur voor overdracht van de keys (af en toe aangevult door de data van de andere) en de andere voor pure data. Of een combo natuurlijk - of maak ik hier een logica fout?.

Nou ja tis en blijft het veiligst (en aangezien hij toch met bankgegevens bezig is...). Al dan niet onpractsch. Een mens leert elke dag bij...

[Twilight Burn]

hobbit_be schreef op 16 augustus 2004 @ 12:56:

offtopic:
[quote]Twilight Burn schreef op 16 augustus 2004 @ 12:31:
[...]

Een ander nadeel van een OTP is dat de sleutel net zo lang, of langer moet zijn dan het te versturen bericht.
[/quote]

Dit laatste was mij onbekend (tot nu) wat het doorgeven van de nieuwe key idd onmogelijk maakt om de getallen (de key) door te geven (aangezien alle data dan nodig zou zijn voor het doorgeven van de key) en er dus niets overblijft voor eigenlijke data.

Bedenk ik dat als je twee kanalen gebruikt dit echter wel zou kunnen. 1 puur voor overdracht van de keys (af en toe aangevult door de data van de andere) en de andere voor pure data. Of een combo natuurlijk - of maak ik hier een logica fout?.

Nou ja tis en blijft het veiligst (en aangezien hij toch met bankgegevens bezig is...). Al dan niet onpractsch. Een mens leert elke dag bij...

offtopic:
Je key moet tenminste zo lang zijn als je bericht, omdat je anders je sleutel moet gaan herhalen, en dan heb je geen one-time-pad (one-time betekend hier dat je hem maar 1x gebruikt) meer, en hoe vaker je het herhaalt hoe onveiliger het wordt. Nou zal het met een redelijk lange sleutel niet veel uitmaken qua veiligheid als je hem een paar keer gebruikt, mits je niet iedere keer op dezelfde plek in de sleutel begint.

Met 2 kanalen blijf je met het probleem zitten dat tenminste 1 kanaal van die 2 veilig moet zijn, want als ze allebei af te luisteren zijn, is je encryptie nog zo gebroken, en als er een kanaal veilig is kun je in dit geval er net zo goed de data ongeencrypt overheen sturen.

[Zoijar]

offtopic:
[quote]Twilight Burn schreef op 16 augustus 2004 @ 12:31:
Quantum-encryptie is trouwens wel gebaseerd op het OTP.[/quote]
Met het voordeel dat het onmogelijk is om het kanaal af te luisteren, en/omdat dit gedetecteerd kan worden. Bovendien hoef je de otp key niet eerst over een ander secure channel te sturen. Je kan namelijk samen je one time pad key bepalen, en kijken of je allebei dezelfde hebt. Als er iets wordt afgeluisterd (het kanaal dus niet secure is) dan merk je dat meteen omdat je niet meer allebei hetzelfde resultaat verkrijgt. Dat komt omdat de operatie 'lezen' mutable is. Het is dus subtiel anders dan het klassieke one time pad bit xor systeem, waar beide partijen eerst elkaar een cd met dezelfde random bits moeten sturen.

[frickY]

Twilight Burn schreef op 16 augustus 2004 @ 12:31:[edit/toevoeging]
Echter in de meeste situaties kun je dan net zo goed het bericht over dat "veilige kanaal" doorgeven,

Echter is die "veilige kanaal" vaak te langzaam voor grote datatransporten... wat de reden is waarom dit in oa SSL niet wordt gedaan.

Ik snap ook het probleem niet wat betreft het opslaan van gecodeerde gegevens?
Ik beheer een aantal betaalmodules. Alle rekening en creditcard gegevens staan Rijndeal256 in de database.. en de keys hiervan in ZEND-encoded bestanden.
Mocht iemand mn server jatten en de harde schijf uitpluizen, en dus toegang hebben tot de database-files.. dan heeft hij nog niets.
Die ene microseconde CPU-tijd die ik nodig heb om die gegevens te decoderen bij de verwerking van de transacties neem ik dan maar voor lief.

[Anoniem: 32412]

frickY schreef op 16 augustus 2004 @ 19:15:
[...]

Echter is die "veilige kanaal" vaak te langzaam voor grote datatransporten... wat de reden is waarom dit in oa SSL niet wordt gedaan.

Ik snap ook het probleem niet wat betreft het opslaan van gecodeerde gegevens?
Ik beheer een aantal betaalmodules. Alle rekening en creditcard gegevens staan Rijndeal256 in de database.. en de keys hiervan in ZEND-encoded bestanden.
Mocht iemand mn server jatten en de harde schijf uitpluizen, en dus toegang hebben tot de database-files.. dan heeft hij nog niets.
Die ene microseconde CPU-tijd die ik nodig heb om die gegevens te decoderen bij de verwerking van de transacties neem ik dan maar voor lief.

precies! helemaal mee eens. Alleen ik ben niet de uber php programmeur. Hoe haal ik dat random IV-gedoe weg? (stond zo beschreven op de php site, voor de rest weinig info.