Beveiligen gevoelige gegevens

[Verwijderd]

Hallo iedereen, ik heb met interesse een aantal topics doorgenomen, maar zit toch met enkele concrete vraagjes.

Het gaat als volgt.

Ik zou een applicatie moeten ontwikkelen voor een arts waarbij het mogelijk is om online een consultatie te reserveren.
Je klikt dan op een lege afspraak in de kalender en vervolgens worden je een aantal gegevens gevraagd.
Deze gegevens bevatten gevoelige informatie zoals bijvoorbeeld de reden van je bezoek.

Ik gebruik dus een encryptiefunctie om deze gegevens op te slaan en een decryptiefunctie om ze terug te tonen.
Aan deze functies geef ik dus een string "reden" mee en een key (zelfverzonnen).

Natuurlijk moet de key voor zowel encryptie als decryptie hetzelfde zijn en het lijkt me ook niet echt slim om deze key als parameter in de database zelf op te slaan.

Nu had ik dus gedacht om de encryptiesleutel in een aparte .php file te steken, een soort parameterfile.

Nu heb ik de volgende vragen:
- is dit goed en veilig genoeg of is er een betere manier?
- is er een manier waarop de data geencrypteerd worden zodat ik nooit weet wat erin staat?
Lijkt me onmogelijk gezien er altijd een key beschikbaar moet zijn.

[lier]

Misschien kan je eens kijken naar certificaten ?
Die zorgen er zowel voor dat je de partij bent die je zegt dat je bent en het verkeer wordt versleuteld.

Mij lijkt een sleutel waarmee ge-encrypt en ge-decrypt niet echt veilig...

[wackmaniac]

Verwijderd schreef op vrijdag 21 mei 2010 @ 09:19:Nu heb ik de volgende vragen:
- is dit goed en veilig genoeg of is er een betere manier?
- is er een manier waarop de data geencrypteerd worden zodat ik nooit weet wat erin staat?
Lijkt me onmogelijk gezien er altijd een key beschikbaar moet zijn.

* De vraag is of je de gegevens op een dergelijke manier wilt opslaan, of dat je de verbinding alleen wilt versleutelen. Dat zou je moeten afspreken met je opdrachtgever. Zorg iig voor een SSL certificaat voor je applicatie.

* Dat heet een hash, maar dan kan niemand het meer terughalen. Je aanname dat de key bij het de- en encrypten gelijk moet zijn is niet waar. Kijk maar eens naar public key encryption en asymmetrische encryptie, zoals bijvoorbeeld RSA. Je versleuteld de gegevens met een sleutel die iederen mag weten, maar het ontcijferen gaat via een sleutel die alleen jij (en je opdrachtgever) kent.

[MueR]

Ga eens praten bij het CBP. Dit is niet iets wat je solo wil gaan doen. Jij kan heel leuk een vorm van encryptie op je systeem zetten, maar zodra jij dergelijke gegevens gaat opslaan zit je aan een aantal erg zware regels wat betreft security vast.

Om zo maar wat vragen te stellen:
- Op wat voor server gaat dit draaien? Shared/dedicated hosting of een server in volledig eigendom?
- Ben je op de hoogte van de Richtlijnen inzake het omgaan met medische gegevens (pdf)?
- Ben je op de hoogte van de NEN 7512 norm?
- Ben je op de hoogte van de Wet op de Geneeskundige BehandelingsOvereenkomst (WGBO)?

Met andere woorden; kan je dit aan?

[Verwijderd]

Dit is niet iets wat je solo wil gaan doen. Jij kan heel leuk een vorm van encryptie op je systeem zetten,

Sowieso, never, ever, zelf een encryptiemechanisme gaan verzinnen. Cryptografie is een vakgebied op zich. Cryptografen zijn jaren bezig om een nieuw algoritme te verzinnen en dan nog wordt het vaak gekraakt. Iets wat je zelf verzint is waarschijnlijk binnen enkele minuten te kraken.

[Verwijderd]

Het veiligste is denk ik door middel van polling op server B de gegevens vanaf server A halen (via ssh ofzo). Dit kan je elke 5 min doen, waarna je de gegevens op server A wipet. Server B kan gewoon op de locatie van de arts staan. Maar wat doe je als server B niks meer pollt, verwijder je dan automatisch afspraken op server A?! Ik denk dat je altijd afspraken moet wipen, wanneer de klanten langs zijn geweest.

Je kan ook een aantal zaken write-only maken, zodat lezen geen zin heeft. Bijv. na uploaden meteen coderen, en dan chownen naar root:root en dan nog goed chmodden.

De grootste zorg ligt denk ik niet aan de serverkant, maar aan de client. De arts gebruikt vast en zeker een windows pc, dan moet je niet aan komen met dat een hacker een keer de gegevens in kan lezen .

Ik heb niet lang nagedacht over bovenstaande oplossing, denk er zelf nog even langer over na. Aan de richtlijnen zal het vast niet voldoen, die MueR gaf. Misschien ook vragen of hij de hele harde schijf heeft gecodeerd, zodat fysieke aanvallen ook niks prijs kunnen geven?

[leuk_he]

Je gegevens encrypted opslaan in de database doe je alleen als je je applicatie/database beheerder niet mag vertrouwen. Volgens mij is daar geen sprake van in dit geval. Een andere mogelijkheid is dat je controle hashes opslaat zodat je wijzingen kan vaststellen.

Jij wil echter vooral inbouwen wie welke gegevens mag zien.

Voorbeeld:

-Openingstijden doctor zijn voor iedereen beschikbaar.
-Afspraken zijn wellicht alleen voor assistent en doctor beschikbaar.
-Afpraakdetails zijn alleen voor de arts en zijn vervanger beschikbaar.

Dat heeft niks met encrypty te maken, maar met toegangsbeheer.
Als het een web applicatie is is het handig de verbinding met https te beveiligen.

Wellicht moet/kun je een log bijhouden wie welke data heeft benaderd. (Een vervanger mag overal bij, maar moet naderhand wel verantwoording kunnen afleggen). Maar dan moet er wel iemand zijn die dit in de gaten houd.

EVT kun je de database in een encrypted partitie zetten, of op een encrypted file systeem, zodat bij diefstal van de server een dief niks met data kan, maar ook dan heb je het probleem dat iemand een wachtwoord moet ingeven na een herstart. Server op en veilige fysieke plek zetten is echter belangrijker. (gedeeld datacentrum is wellicht niet zo veilig in deze context)

[RobIII]

Everything you need to know about cryptography in 1 hour
Bottom line: zorg ver-dom-des goed dat je weet waar je mee bezig bent of geef het uit handen aan iemand die dat wél weet.

Verwijderd schreef op vrijdag 21 mei 2010 @ 10:42:
De arts gebruikt vast en zeker een windows pc, dan moet je niet aan komen met dat een hacker een keer de gegevens in kan lezen .

Wikipedia: Security through obscurity

Los van of je wel of geen encryptie nodig hebt, heb je ook te maken met access control etc. zoals hierboven al wordt uitgelegd en dan nog authenticatie/identificatie etc. With all due respect maar als je een beginnend programmeur bent (en dat concludeer ik uit 't feit dat je denkt dat een aparte .php file beter is) dan ben je echt niet de aangewezen persoon om deze klus op te pakken; de kans op fuckups is gewoon te groot.

[ Voor 63% gewijzigd door RobIII op 21-05-2010 11:01 ]

[Verwijderd]

MueR schreef op vrijdag 21 mei 2010 @ 10:26:
Ga eens praten bij het CBP. Dit is niet iets wat je solo wil gaan doen. Jij kan heel leuk een vorm van encryptie op je systeem zetten, maar zodra jij dergelijke gegevens gaat opslaan zit je aan een aantal erg zware regels wat betreft security vast.

Om zo maar wat vragen te stellen:
- Op wat voor server gaat dit draaien? Shared/dedicated hosting of een server in volledig eigendom?
- Ben je op de hoogte van de Richtlijnen inzake het omgaan met medische gegevens (pdf)?
- Ben je op de hoogte van de NEN 7512 norm?
- Ben je op de hoogte van de Wet op de Geneeskundige BehandelingsOvereenkomst (WGBO)?

Met andere woorden; kan je dit aan?

Heb je groot gelijk in, ben er dan ook nog lang niet, en wil me eerst goed informaren.

[Verwijderd]

Je gegevens encrypted opslaan in de database doe je alleen als je je applicatie/database beheerder niet mag vertrouwen.

Daar ben ik het nou totaal niet mee eens ;-)

Als de applicatie onveilig is (SQL-Injection) of als het wachtwoord van de MySQL database wordt gekraakt, liggen die gegevens open en bloot. Als je dan een en/de-cryptie eroverheen haal, zal het een stuk moeilijker worden om de data terug te halen.

Zelf heb ik een en/de-cryptie gemaakt die alleen te kraken is als je de (PHP) code heb. Zonder die, is het niet mogelijk om die te bruteforcen omdat er geen logica in lijkt te zitten. "83LcqFxhXKJcYXaVFaKWlNVN" in een database zetten en ze hebben geen idee wat het is. (Terwijl het wel iets betekend ;-))

[Verwijderd]

RobIII schreef op vrijdag 21 mei 2010 @ 10:56:

Los van of je wel of geen encryptie nodig hebt, heb je ook te maken met access control etc. zoals hierboven al wordt uitgelegd en dan nog authenticatie/identificatie etc. With all due respect maar als je een beginnend programmeur bent (en dat concludeer ik uit 't feit dat je denkt dat een aparte .php file beter is) dan ben je echt niet de aangewezen persoon om deze klus op te pakken; de kans op fuckups is gewoon te groot.

Ben zeker geen beginnend programmeur, en weet ook dat een aparte file verre van een goede oplossing is, vandaar mijn topic, maar het leek mij in ieder geval een veel betere oplossing dan de key gewoon te storen in de database. Met andere woorden, encryptie op een plaats, key op een andere...
Ik ben echter wel zeer onervaren met dit niveau van beveiliging en daar kan ik inderdaad nog veel van leren.


Anyway, ik heb nu de methode met private en public keys even onder de loep genomen en het lukt me niet om terug te decrypteren, met andere woorden, op het einde "output" is leeg.

code:

<?php
$passphrase = "KDIJLF877DFHKDF8";
// generate a 1024 bit rsa private key, returns a php resource, save to file
$privateKey = openssl_pkey_new(array(
    'private_key_bits' => 1024,
    'private_key_type' => OPENSSL_KEYTYPE_RSA,
));
openssl_pkey_export_to_file($privateKey, '/var/www/app/installation/keys/privatekey', $passphrase);
 
// get the public key $keyDetails['key'] from the private key;
$keyDetails = openssl_pkey_get_details($privateKey);
file_put_contents('/var/www/app/installation/keys/publickey', $keyDetails['key']);




$pubKey = openssl_pkey_get_public('file:///var/www/app/installation/keys/publickey');
openssl_public_encrypt($sensitiveData, $encryptedData, $pubKey);
 
// store $encryptedData ...





// retrieve $encryptedData from storage ...
 
// load the private key and decrypt the encrypted data
$privateKey = openssl_pkey_get_private('file:///var/www/app/installation/keys/privatekey', $passphrase);
openssl_private_decrypt($encryptedData, $output, $privateKey);
echo $output;
?>

[ Voor 40% gewijzigd door Verwijderd op 21-05-2010 11:57 ]

[begintmeta]

Je zal het als je goed nadenkt en plant al snel beter doen dan dit ziekenhuis... Maar zorg dus in elk geval dat je donders goed weet wat je doet.

Ik zou trouwens niet weten waarom de keys voor en- en decryptie dezelfde zouden moeten zijn. De private key hoeft alleen beschikbaar te zijn bij de agenda(beheerder(s)), de publieke kan je gewoon gebruiken voor encryptie van de gegevens. En vergeet de beveiliging van de verbinding met de site niet.

[ Voor 43% gewijzigd door begintmeta op 21-05-2010 12:00 ]

[Verwijderd]

Denk je bij de beveiliging van de data ook aan de zwakste schakel:
De mensen die ermee werken?

[DutchKel]

En dan krijg je dat je php server is gehacked en alle bestanden zijn verwijderd... Weg key (want de key ergens anders bewaren is ook weer een risico), weg data.

Ik denk dat je dit inderdaad beter kunt uitbesteden (althans de encryptie en security) en dat je zelf de UI in de hand houd, dan heb je zelf nog wel iets werk eraan.

PS als je niet weet hoe je die bovenstaande code moet debuggen dan zou ik alles maar uitbesteden:

$privateKey = openssl_pkey_get_private('file:///var/www/app/installation/keys/privatekey', $passphrase);
echo "enc data: " + $encryptedData;
echo "priv key: " + $privateKey;
openssl_private_decrypt($encryptedData, $output, $privateKey);
echo $output;

Dus eerst kijken of alles wel netjes is ingevuld.

Edit 2: Mag ik weten voor welke arts je dit maakt? Dan zorg ik direct dat hij mij nooit meer behandeld, iemand die zoiets aan een willekeurig persoon overlaat is niet erg strict met de gegevens van zijn klanten.

[ Voor 51% gewijzigd door DutchKel op 21-05-2010 12:10 ]

[RobIII]

Verwijderd schreef op vrijdag 21 mei 2010 @ 11:53:
Zelf heb ik een en/de-cryptie gemaakt die alleen te kraken is als je de (PHP) code heb.

Eigen encryptie algoritmes zijn, per definitie, in 99.99999999% van de gevallen waardeloos. En in dat ene andere geval hooguit 'pittig' om te kraken. En zeker de algoritmes die zo even in een halve dag in elkaar gezet zijn. "Beetje XOr-en, beetje wat bitjes husselen, Base64 erover heen en klaar..."

Denk eens na: van alle gangbare encryptiemethodes is het algoritme openbaar (in tegenstelling tot jouw algoritme) en dan nog zijn de gegevens (zo goed als) onmogelijk te decrypten zonder de juiste key(s). Ik plaatste eerder ook al een link naar "Security through Obscurity"; lees die eens en Kerckhoffs' principle.

En om nog eens te quoten uit Everything you need to know about cryptography in 1 hour:

Conventional wisdom: Don’t write cryptographic code!

Wat jij, at best, hebt gemaakt is een schijnveiligheid; je denkt dat 't wel goed zit maar in realiteit is het nutteloos.

Verwijderd schreef op vrijdag 21 mei 2010 @ 11:53:
Zonder die, is het niet mogelijk om die te bruteforcen omdat er geen logica in lijkt te zitten.

Ah, dus kunt het beter dan vele, vele, knappe koppen die achter de gangbare encryptiealgoritmes zitten? Geloof je het zelf?

Verwijderd schreef op vrijdag 21 mei 2010 @ 11:53:
"83LcqFxhXKJcYXaVFaKWlNVN" in een database zetten en ze hebben geen idee wat het is.

En nog altijd een factor 10.000.000.000.000 makkelijker te kraken dan de gangbare encryptiealgoritmes.

[ Voor 35% gewijzigd door RobIII op 21-05-2010 12:21 ]

[Battle Bunny]

Wat ik dan niet begrijp is dat er bergen goede programmeurs zonder werk zitten, en iemand die geen PHP kan debuggen krijgt een opdracht om een artsen-reserveer-systeem te bouwen... Krom, erg krom.

[begintmeta]

RobIII schreef op vrijdag 21 mei 2010 @ 12:06:
...
En nog altijd een factor 10.000.000.000.000 makkelijker te kraken dan de gangbare encryptiealgoritmes.

Op zich is een one-time-pad wel heel veilig, maar dan moet je de sleutel (naast dat die groot en random genoeg moet zijn) wel goed beveiligen, een database gekoppeld aan een php-pagina of een php-pagina zelf lijken me daar niet zo geschikt voor.

[MueR]

Verwijderd schreef op vrijdag 21 mei 2010 @ 11:54:
Ik ben echter wel zeer onervaren met dit niveau van beveiliging en daar kan ik inderdaad nog veel van leren.

Sorry, maar als je geen ervaring hebt met dit niveau van security, moet je nu ophouden. Er zijn gespecialiseerde bedrijven die dit doen, juist omdat er een enorme bult aan wetten, regels, richtlijnen en gedragscodes aan vast hangt. Als er iets mis gaat en patientdata komt op straat te liggen, ben jij de lul, dan kan de beste dokter jou aanklagen voor nalatigheid en weet ik wat.

Dit soort applicaties zijn een aparte tak van sport, laat het over aan de professionals. Ik waag me er ook niet zomaar aan, juist omdat er heel erg veel regels zijn om rekening mee te houden. Dat vereist dermate veel voorbereiding, middelen en werk dat het heel lucratief moet zijn.

[Verwijderd]

kfaessen schreef op vrijdag 21 mei 2010 @ 12:02:
En dan krijg je dat je php server is gehacked en alle bestanden zijn verwijderd... Weg key (want de key ergens anders bewaren is ook weer een risico), weg data.

Ik denk dat je dit inderdaad beter kunt uitbesteden (althans de encryptie en security) en dat je zelf de UI in de hand houd, dan heb je zelf nog wel iets werk eraan.

PS als je niet weet hoe je die bovenstaande code moet debuggen dan zou ik alles maar uitbesteden:

[...]


Dus eerst kijken of alles wel netjes is ingevuld.

Edit 2: Mag ik weten voor welke arts je dit maakt? Dan zorg ik direct dat hij mij nooit meer behandeld, iemand die zoiets aan een willekeurig persoon overlaat is niet erg strict met de gegevens van zijn klanten.

Maak je geen zorgen, de applicatie is nog lang niet in productie en er is mij gevraagd om eens te kijken of het al dan niet mogelijk is dit zelf te doen, maar daar zal grondig onderzoek aan voorafgaan.

Wat de code betreft ben ik natuurlijk in staat om PHP te debuggen, het probleem is dat het om een letterlijk voorbeeld gaat en ik alle variabelen kan echoen behalve de output.
Het voorbeeld komt van hier : http://www.webtatic.com/b...-public-key-cryptography/

. in plaats van "+" lijkt me trouwens beter (wie gaf hier commentaar over debuggen?) en had ik natuurlijk allang gedaan, zoals ik zei liep daar ook nog alles goed.

code:

echo "enc data: " . $encryptedData;
echo "priv key: " . $privateKey;

anyway, problem solved, bleek gewoon aan de cache in firefox te liggen..

[ Voor 10% gewijzigd door Verwijderd op 21-05-2010 13:20 ]

[Verwijderd]

Battle Bunny schreef op vrijdag 21 mei 2010 @ 12:10:
Wat ik dan niet begrijp is dat er bergen goede programmeurs zonder werk zitten, en iemand die geen PHP kan debuggen krijgt een opdracht om een artsen-reserveer-systeem te bouwen... Krom, erg krom.

nogmaals, debuggen is geen probleem, alle vars hebben een waarde behalve de output.
In ieder geval bedankt voor je evaluatie

heb hier het script zelf gepost komende van een website online, debuggen heb ik op mijn pc uiteraard gedaan, dus je opmerking vind ik niet gepast en erg flauw.

[ Voor 15% gewijzigd door Verwijderd op 21-05-2010 12:54 ]

[Verwijderd]

MueR schreef op vrijdag 21 mei 2010 @ 12:22:
[...]

Sorry, maar als je geen ervaring hebt met dit niveau van security, moet je nu ophouden. Er zijn gespecialiseerde bedrijven die dit doen, juist omdat er een enorme bult aan wetten, regels, richtlijnen en gedragscodes aan vast hangt. Als er iets mis gaat en patientdata komt op straat te liggen, ben jij de lul, dan kan de beste dokter jou aanklagen voor nalatigheid en weet ik wat.

Dit soort applicaties zijn een aparte tak van sport, laat het over aan de professionals. Ik waag me er ook niet zomaar aan, juist omdat er heel erg veel regels zijn om rekening mee te houden. Dat vereist dermate veel voorbereiding, middelen en werk dat het heel lucratief moet zijn.

Daar heb je gelijk in, daarom dat ik me eerst deftig wilde informeren.
In tegenstelling tot sommigen denken ben ik echt niet van plan om eventjes los los de applicatie te schrijven en online te gooien.
Ik heb heel weinig ervaring met php-security en zal me er dan ook zeker niet aan wagen als er ook maar enig risico is.


excuses @hieronder, wist het wel, maar vond het overzichtelijker, zal er voortaan op letten.

[ Voor 4% gewijzigd door Verwijderd op 21-05-2010 13:21 ]

[RobIII]

sarnath:Gebruik de edit knop ( ) als je iets toe te voegen hebt; je topic herhaaldelijk omhoogschoppen is niet nodig.

[Verwijderd]

Ik heb nog eens even alle informatie van jullie doorgenomen en ben inderdaad tot de conclusie gekomen dat er zowel proceduraal als programmatorisch heel wat risico's verbonden zijn aan het werken met dit soort gevoelige materie en heb besloten om er gewoon een online afsprakensysteem van te maken (dus niet voor artsen en dergelijke).
Lijkt me dat de openssl beveiliging met private en public key hier zeker ruimschoots voor moet volstaan.

Alvast bedankt voor de nuttige reacties (grotendeels toch)

[leuk_he]

Verwijderd schreef op vrijdag 21 mei 2010 @ 11:53:
[...]
[Je gegevens encrypted opslaan in de database doe je alleen als je je applicatie/database beheerder niet mag vertrouwen.]

Daar ben ik het nou totaal niet mee eens ;-)

Als de applicatie onveilig is (SQL-Injection) of als het wachtwoord van de MySQL database wordt gekraakt, liggen die gegevens open en bloot. Als je dan een en/de-cryptie eroverheen haal, zal het een stuk moeilijker worden om de data terug te halen.

Wat jij doet is alleen een stukje obfuscation, aangezien je decryption key gewoon in je applicatie (php files) beschikbaar is. Enkel als je key in een geode keystore zit die met (bijvoorbeeld ) een gebruikerswachtwoord beveiligd is spreek je echt over encrypty. Door dat encrypty te noemen zonder goed key-management maak je een fout in encrypty.

Als je data hebt die write only is (betaling gegevens met creditkaartgegevens), is het wellicht een betere optie die in een 2e database op een extern systeem te zetten.

Uiteraard ben ik het met je eens dat ook obfuscatie een kleine meerwaarde heeft in beveiliging, maar verwar dit niet met het hoofdprobleem.

Voor wat jij voorstaat, de key sla je op in de gebruikers tabel, en encrypt je met het wachtwoord van de gebruiker. Vervolgens salt je alle encrypty met de je recordnummer(/PK) en de tabelnaam. Gevolg: alleen die gebruiker kan erbij, als die gebruiker zijn wachtwoord kwijt is is de data weg. (Dit is dus ook ongeveer het model wat windows ongeveer gebruikt voor windows file encrypty, met als randeffect dat het windows wachtwoord , met fyske access, te achterhalen is en daarma dus de file encrypty net zo sterk is als de beveiling van het windows wachtwoord)


PS sarnath heeft meer belang bij goede toegangscontrole, en auditing dan by encrypty, dus dit is enigzins offtopic.

[Sv3n]

Overigens is dit er ook al, zie: https://www.patientportaal.nl/ Dit systeem is aan het HIS van je arts gekoppeld en schiet afspraken rechtstreeks de kalender van de praktijk in.\

@Onder: Ow das ook lekker, deze link werkt wel: https://www.patientportaal.nl/patientportaal/

[ Voor 21% gewijzigd door Sv3n op 21-05-2010 15:24 ]

[RobIII]

Sv3n schreef op vrijdag 21 mei 2010 @ 15:17:
Overigens is dit er ook al, zie: https://www.patientportaal.nl/ Dit systeem is aan het HIS van je arts gekoppeld en schiet afspraken rechtstreeks de kalender van de praktijk in.

Mooi die site!

Red Hat Enterprise Linux Test Page
This page is used to test the proper operation of the Apache HTTP server after it has been installed. If you can read this page, it means that the Apache HTTP server installed at this site is working properly.

[ Voor 24% gewijzigd door RobIII op 21-05-2010 15:19 ]

[MSalters]

Misschien is het gewoon handiger om de TS erop te wijzen dat hij simpelweg een password systeem nodig heeft? Daarna is de "encryptie" van de reden triviaal: DBReden = Concatenate(RandomSalt, PHPReden XOR Hash(Concatenate(Password, RandomSalt)).

(RandomSalt is nodig omdat sommige mensen meer dan 1 afspraak hebben, dus meer dan 1 reden, en je die niet beiden met dezelfde Hash(Password) will concatenaten.

Toegegeven, password wijzigingen zijn dan niet helemaal triviaal