[PHP/MYSQL] Beveiligen creditcard informatie

[Verwijderd]

Ik heb een mysql database waarin ik creditcard informatie wil opslaan. Nu wil ik graag het creditcardnummer op een zo veilig mogelijke manier coderen. Nu ben ik bekend met PHP functies als base64 en MD5. Beide voldoen eigenlijk niet. Base64 is eenvoudig weer te decoderen en MD5 is geheel niet te decoderen zodat ik het alleen kan gebruiken om te vergelijken.

1) Ik ben op zoek naar de beste manier om middels PHP in Mysql deze gegevens maximaal te beveiligen, maar wel op een manier dat ik zelf in staat ben om deze gegevens in mijn scripts te kunnen gebruiken.

2) Ik dacht zelf aan een eigen gemaakt algoritme dat een base64 encoded string aanpast. (Bijv. door het laatste cijfer -1 aan te passen) Op deze manier is het voor scriptkiddies die onverhoopt toegang krijgen niet eenvoudig te decoderen. Is dit nuttig? (Ik heb helaas geen verstand van encryptie) Of kan alsnog dergelijke aanpassingen simpel worden gedecodeerd?

Ik begrijp uiteraard dat serverbeveiliging een belangrijke rol speelt. Ik ben echter op zoek naar methodes die ik binnen PHP kan toepassen om mijn data zo veilig mogelijk op te slaan. Wie helpt mij op de juiste weg?

[GlowMouse]

Als je dit vraagt, denk ik dat je het beter niet op kunt slaan

[Verwijderd]

Dit heeft geen zin omdat je code en algoritme ook bekend zijn als er een beveiligingslek is. Als je echt encryptiealgoritme gebruikt moet de key ook bekend zijn op de server. Het heeft dus geen zin om je data op die manier te beveiligen.

MD5 is zinloos, want een hashalgoritme, geen encryptiealgoritme.
Base64 is al helemaal geen encryptiealgoritme.

Kijk liever naar mcrypt, maar ik denk dat dat niet veel zin heeft. Dat is overigens wel afhankelijk van de applicatie. Als de applicatie alleen hoeft te encrypten, kun je een public key algoritme gebruiken.

GlowMouse schreef op woensdag 13 januari 2010 @ 00:20:
Als je dit vraagt, denk ik dat je het beter niet op kunt slaan

So true.

[ Voor 14% gewijzigd door Verwijderd op 13-01-2010 00:25 ]

[TeeDee]

1: Wat zou jij verder met de creditcard gegevens willen doen dan?
2: Security through obscurity. Een of ander vreemd 'algorithme' wat door 'scriptkiddies' ook gewoon netjes doorgekeken kan worden zodra ze toegang hebben.

Sla het gewoon niet op, en laat bijvoorbeeld een payment provider dit lekker oplossen voor je.

[Osiris]

Verwijderd schreef op woensdag 13 januari 2010 @ 00:25:
Dit heeft geen zin omdat je code en algoritme ook bekend zijn als er een beveiligingslek is. Als je echt encryptiealgoritme gebruikt moet de key ook bekend zijn op de server. Het heeft dus geen zin om je data op die manier te beveiligen.

Ah ja, want als de DB exposed is vanwege bijvoorbeeld een SQL-injection-exploit, dan is ook meteen alle PHP-code beschikbaar tot de hacker?

[Verwijderd]

Osiris schreef op woensdag 13 januari 2010 @ 00:29:
[...]

Ah ja, want als de DB exposed is vanwege bijvoorbeeld een SQL-injection-exploit, dan is ook meteen alle PHP-code beschikbaar tot de hacker?

Ja, maar daar staat geen creditcard informatie in niet zo interessant dus...

[RobIII]

Note to self: ver uit de buurt blijven van ray79's projecten/webshops.

Osiris schreef op woensdag 13 januari 2010 @ 00:29:
[...]

Ah ja, want als de DB exposed is vanwege bijvoorbeeld een SQL-injection-exploit, dan is ook meteen alle PHP-code beschikbaar tot de hacker?

Nee, maar dat is dan wel een kwestie van tijd Met een beetje leuk injecten kom je zo weer achter andere zaken/gegevens die je weer kunt gebruiken om (bijv.) wachtwoorden te achterhalen om in te kunnen loggen op weer een andere service etc. of toegang krijgen tot een CMS ofzo waar dan weer (misschien) een lek in zit etc.

Je moet gewoon een CC-nummer niet eens (willen) opslaan. Sla desnoods (als je 't nodig hebt als referentie bij betalingen e.d. om te zien welke CC gebruikt is) enkel de eerste en laatste groep cijfers op en laat de rest weg. Dat is redelijk gangbaar. Maar nog makkelijker (en betrouwbaarder en gangbaarder) is gewoon een payment provider gebruiken. Ben je meteen verzekerd en kun je veel sneller (niet altijd, je hebt net zo goed verantwoordelijkheden!) de schuld bij hen leggen als de poep de ventilator raakt.

Verwijderd schreef op woensdag 13 januari 2010 @ 00:49:
[...]


Ja, maar daar staat geen creditcard informatie in niet zo interessant dus...

Maar wel de key om te decrypten

[ Voor 44% gewijzigd door RobIII op 13-01-2010 01:04 ]

[Verwijderd]

Osiris schreef op woensdag 13 januari 2010 @ 00:29:

Ah ja, want als de DB exposed is vanwege bijvoorbeeld een SQL-injection-exploit, dan is ook meteen alle PHP-code beschikbaar tot de hacker?

Jij houdt alleen rekening met SQL injection?

[Osiris]

Verwijderd schreef op woensdag 13 januari 2010 @ 00:49:
[...]


Ja, maar daar staat geen creditcard informatie in niet zo interessant dus...

Maar misschien wel ergens die AES-key die gebruikt is om de CC-info te encrypten.

RobIII schreef op woensdag 13 januari 2010 @ 00:59:
[...]

Nee, maar dat is dan wel een kwestie van tijd Met een beetje leuk injecten kom je zo weer achter andere zaken/gegevens die je weer kunt gebruiken om (bijv.) wachtwoorden te achterhalen om in te kunnen loggen op weer een andere service etc. of toegang krijgen tot een CMS ofzo waar dan weer (misschien) een lek in zit etc.

Nou ja, dat kan inderdaad. Maar zaken als CMS-toegangs-wachtwoorden zullen ook wel weer hashed zijn enzo. Ik heb iig geen passwords zo rondslingeren in mijn MySQL-DB's. Maar ofcourse, het is mogelijk ja.

RobIII schreef op woensdag 13 januari 2010 @ 00:59:
Je moet gewoon een CC-nummer niet eens (willen) opslaan. Sla desnoods (als je 't nodig hebt als referentie bij betalingen e.d. om te zien welke CC gebruikt is) enkel de eerste en laatste groep cijfers op en laat de rest weg. Dat is redelijk gangbaar.

Kun je ook niet een modern hash-geval zoals SHA-2 oid gebruiken? Zolang dat nog veilig is, kun je 't ook gebruiken lijkt me?

RobIII schreef op woensdag 13 januari 2010 @ 00:59:
Maar nog makkelijker (en betrouwbaarder en gangbaarder) is gewoon een payment provider gebruiken. Ben je meteen verzekerd en kun je veel sneller (niet altijd, je hebt net zo goed verantwoordelijkheden!) de schuld bij hen leggen als de poep de ventilator raakt.

Lijkt me sowieso verstandig

Verwijderd schreef op woensdag 13 januari 2010 @ 01:11:
[...]

Jij houdt alleen rekening met SQL injection?

Welnee, maar jouw opmerking vond ik simpelweg een beetje te kort door de bocht.

[RobIII]

Osiris schreef op woensdag 13 januari 2010 @ 01:21:
Kun je ook niet een modern hash-geval zoals SHA-2 oid gebruiken? Zolang dat nog veilig is, kun je 't ook gebruiken lijkt me?

Hoe zie je dat voor je?

[T020]

Osiris schreef op woensdag 13 januari 2010 @ 01:21:
Kun je ook niet een modern hash-geval zoals SHA-2 oid gebruiken? Zolang dat nog veilig is, kun je 't ook gebruiken lijkt me?

Dat heeft geen zin zoals ray79 zelf ook al aangaf, van bij een hash-functie kun je namelijk de brontekst niet achterhalen en dat moet nu juist wel kunnen.

GlowMouse schreef op woensdag 13 januari 2010 @ 00:20:
Als je dit vraagt, denk ik dat je het beter niet op kunt slaan

Mee eens inderdaad, laat het opslaan van dit soort gevoelige gegevens liever over aan de banken, dat is ook wel zo leuk voor de klanten van je webshop...

als het een webshop is tenminste, en dan nog zie ik maar één mogelijk doel om het nummer te bewaren en dat is om het later automatisch in te vullen in een betaalschermpje o.i.d.
Dit is ook gewoon te realiseren door een cookie, zo wordt het nummer clientside opgeslagen en dus is het wel veilig <-- niet bestand tegen XSS inderdaad (thx RobIII), kleine moeite dus om het de gebruiker nog een keer te laten invoeren in dat schermpje

[ Voor 6% gewijzigd door T020 op 13-01-2010 01:58 ]

[RobIII]

T020 schreef op woensdag 13 januari 2010 @ 01:49:
[...]

Dat heeft geen zin zoals ray79 zelf ook al aangaf, van bij een hash-functie kun je namelijk de brontekst niet achterhalen en dat moet nu juist wel kunnen.

Nee maar jou zou wel hash(opgeslagen) met hash(input) kunnen vergelijken, maar erg praktisch is dat niet. Vandaar mijn vraag: Hoe zie je dat voor je?

T020 schreef op woensdag 13 januari 2010 @ 01:49:
Dit is ook gewoon te realiseren door een cookie, zo wordt het nummer clientside opgeslagen en dus is het wel veilig

En met het eerste het beste XSS lek ligt je CC-info alsnog op straat.

[ Voor 26% gewijzigd door RobIII op 13-01-2010 01:52 ]

[T020]

RobIII schreef op woensdag 13 januari 2010 @ 01:51:
[...]

Nee maar jou zou wel hash(opgeslagen) met hash(input) kunnen vergelijken, maar erg praktisch is dat niet. Vandaar mijn vraag: Hoe zie je dat voor je?

Precies mijn punt goeie vraag

[cariolive23]

Verwijderd schreef op woensdag 13 januari 2010 @ 00:19:
Ik heb een mysql database waarin ik creditcard informatie wil opslaan.

Tip: Ga eerst eens uitzoeken voor hoeveel (miljoen?) euro jij het schip in kan gaan wanneer jouw database-gegevens op straat komen te liggen. Jij bent aansprakelijk voor het veilig opslaan van deze gegevens, wanneer jij het alleen hebt over PHP en MySQL, dan ga je dit nooit voorelkaar krijgen. Heb je bv. al wel een extreem veilig operating system geinstalleerd en geconfigureerd? (denk aan SELinux)

Wanneer jij credit card gegevens wilt opslaan in een database, zul je al een database moeten nemen die speciale veiligheidsmaatregelen heeft genomen om dit te ondersteunen, Oracle heeft dit in huis, PostgreSQL heeft daar het project SEPostgreSQL voor. Lees de wiki eens door en zie hoe lastig het is om dit soort gegevens veilig op te slaan. Met alleen een beetje PHP en MySQL is dit niet mogelijk.

Advies: Sla geen gegevens op of ga een expert inhuren die eerst een veilige omgeving gaat opzetten.

[Nvidiot]

Ben je zodra je dit soort gegevens opslaat niet verplicht je te houden aan de PCI DSS standaard? Wikipedia: Payment Card Industry Data Security Standard

Het goed implementeren van die standaard is zeker niet triviaal, laat dat lekker over aan een payment provider

[HuHu]

Dat soort gegevens moet je inderdaad niet eens willen opslaan. Het enige wat ik van mijn Payment Service Provider (PSP) door krijg zijn de laatste 4 cijfers van het creditcard nummer. Ik sla dan dingen op als: XXXXXXXXXXXX4013.

Als een klant dan belt of mailt met een vraag voor informatie aangaande een betaling, dan kun je melden dat er een betaling is gedaan op die-en-die datum, met een creditcard eindigend op nummers 4013. Dan weet je klant meestal wel genoeg.

Het hele nummer bewaren betekend dat je betalingen kunt doen met die creditcard en de enige die betalingen met een kaart mag doen is de eigenaar. Dus de enige die het nummer hoeft te weten is de eigenaar.

Ik kan me eigenlijk geen reden bedenken waarom een internetwinkel het volledige nummer zou moeten weten, tenzij die de betaling zelf volledig afhandelt zonder PSP.

[Pin0]

Ik heb redelijk wat ervaring met webshops (wij beheren er een stuk of 40) en wij waken ervoor om CC gegevens niet op te slaan. Dit doet onze payment provider inderdaad voor ons. (deze slaat zoals gezegd alleen de laatste 4 cijfers op.)
Verder heb ik nog nooit die gegevens nodig gehad, en ik kan ook niet bedenken waarom ik die nodig zou hebben. Ik kan altijd bepaalde zaken terugvinden mbv. het email adres, datums, klantnaam etc...

Maar er staat volgens mij nergens dat hij een webwinkel wil maken, misschien maakt de ts voor zichzelf een beheer app. Dan is het wel interessant om verschillende encryptie technieken te bespreken.
Zelf gebruik ik wel eens mcrypt om hele array's via de url te sturen zonder dat die aangepast kunnen worden...

[ Voor 0% gewijzigd door Pin0 op 13-01-2010 08:51 . Reden: typo ]

[Woy]

Pin0 schreef op woensdag 13 januari 2010 @ 08:50:
Maar er staat volgens mij nergens dat hij een webwinkel wil maken, misschien maakt de ts voor zichzelf een beheer app. Dan is het wel interessant om verschillende encryptie technieken te bespreken.
Zelf gebruik ik wel eens mcrypt om hele array's via de url te sturen zonder dat die aangepast kunnen worden...

Dan is het zinnig om het eerst eens over de theorie van encryptie te hebben, in plaats van over een implementatie. Als je niet goed snapt waar je mee bezig bent, dan kun je er vrijwel zeker van zijn dat je niet de juiste techniek gaat gebruiken. Zo hebben verschillende technieken verschillende toepassingen.

Je hebt in feite 3 grote stromingen van encryptie: symmetrisch, a-symmetrisch en hashing

elk van die vormen heeft zijn eigen toepassingen.

[MueR]

Je mag geen credit card informatie opslaan zonder toestemming van de uitgevende instanties (VISA, MasterCard etc). Als je strafbaar wilt zijn, moet je vooral doorgaan. Er zijn redenen dat je dit soort grappen alleen mag doen wanneer je elke week controleurs van die instanties over de vloer krijgt namelijk. Uiteraard mag je best de laatste 3 nummers van een creditcard opslaan als vermelding aan de klant, maar daar houdt het ongeveer op.

[steffex]

Ik hoop toch dat bovenstaande posts de ts genoeg attenderen op het feit dat je geen CC gegevens moet opslaan. Anders wil ik graag de shop/website hebben die hij aan het maken is, zodat ik deze kan vermeiden!

Naast dat het strafbaar is zoals MueR zegt, lijkt het me ook niet dat de TS genoeg geld heeft om eventuele claims uit te kunnen betalen zodra de gegevens op straat liggen...

[RobIII]

MueR schreef op woensdag 13 januari 2010 @ 10:26:
Als je strafbaar wilt zijn, moet je vooral doorgaan.

Of het strafbaar is valt nog te bezien, daar gaan die instanties namelijk niet over maar een rechtbank. En AFAIK is het niet strafbaar, maar zéker ook niet slim. Het heimelijk opslaan (of verkrijgen) van die gegevens door ze bijvoorbeeld te sniffen zal waarschijnlijk wél strafbaar zijn. Daarbij krijgen payment providers écht niet elke week controleurs over de vloer.
Then again: AINAL en het lijkt me inmiddels duidelijk dat je die zaken voor een "webshopje" niet wil opslaan. En anders verwijs ik naar Woy's reply.

[ Voor 5% gewijzigd door RobIII op 13-01-2010 10:45 ]

[MueR]

Regelgeving mbt verkrijgen en opslag creditcard gegevens in Nederland zoals gesteld door VISA/MasterCard, met aanvulling van een aantal zeer sterke adviezen van een grote payment provider.

[ Voor 16% gewijzigd door MueR op 13-01-2010 11:10 ]

[Osiris]

RobIII schreef op woensdag 13 januari 2010 @ 01:30:
[...]

Hoe zie je dat voor je?

Je had 't over bepaalde getallen "als referentie" gebruiken. Lijkt me dat je een hash ook prima als referentie kunt gebruiken?

[Woy]

Voor gegevens die te maken hebben met betaalpassen/transacties is het ook handig om eens naar de PCI+ standaard te kijken. Er gelden inderdaad erg strenge regels kan ik je uit ervaring vertellen!

[RobIII]

MueR schreef op woensdag 13 januari 2010 @ 11:08:
Regelgeving mbt verkrijgen en opslag creditcard gegevens in Nederland zoals gesteld door VISA/MasterCard, met aanvulling van een aantal zeer sterke adviezen van een grote payment provider.

Het woord 'strafbaar' komt daar niet in voor Ze hebben 't wel over boetes, maar da's niet hetzelfde

offtopic:
Maar de slogan 'if you don’t need it, don’t store it' maakt 't wel (weer) duidelijk.

[ Voor 13% gewijzigd door RobIII op 13-01-2010 13:46 ]

[MueR]

offtopic:
mier, copuleren, semantics

[ Voor 16% gewijzigd door MueR op 13-01-2010 14:43 ]

[Verwijderd]

Dank voor alle reacties. Het komt er eigenlijk op neer dat het niet mogelijk is dit te beveiligen voor kleine partijen zonder veel geld. Dat creditcardinformatie gevoelig is en goed beschermd dient te worden ligt voor de hand. Maar hoe zit het eigenlijk met andere informatie zoals b.v N.A.W in combinatie met een bankrekeningnummer. Marktplaats.nl bijv. slaat deze gegevens bij online machtiging op. Is dat wettelijk eigenlijk wel toegestaan? Het lijkt er op, dat creditcardmaatschappijen enorme claims bij je kunnen neerleggen indien je deze informatie opslaat. Hoe zit dat eigenlijk met bankrekeningnummers? Verder, wat voor encryptie techniek zou een partij als marktplaats.nl gebruiken om deze gegevens te beschermen?

[Janoz]

Wie zegt dat ze die gegevens opslaan? Dat er om wordt gevraagd betekent niet automatisch dat het ook opgeslagen wordt. Het kan heel goed dat het gelijk doorgegeven wordt aan de payment provider.

[Woy]

Het grote verschil is ook dat je met N.A.W. gegevens en een rekening nummer geen geld op kan nemen van een rekening. Je kunt er hoogstens geld op storten.

Met een creditcard nummer kun je in principe betalen ( Al zal je voor online transacties altijd ook de CVC code nodig hebben )

Voor N.A.W. gegevens hoef je niet perse encryptie te gebruiken, al zul je nog steeds aan de eisen van College bescherming persoonsgegevens moeten voldoen.

[Verwijderd]

Marktplaats.nl geeft in hun voorwaarden aan dat ze deze gegevens opslaan, zodat een gebruiker ze maar één keer hoeft in te vullen. linkje

N.A.W met rekeningnummer kan gebruikt worden om een incasso-opdracht uit te voeren. Je moet dan wel een mogelijkheid hebben om incasso's uit te laten voeren.

[MueR]

Wat is nu eigenlijk je doel met al die informatie?

Moet je trouwens eens proberen, een incasso starten zonder toestemming. Als $klant de incasso laat terugdraaien ligt de bewijslast wel bij jou.

[Gomez12]

En na ongeveer 3x een foutieve incasso ben je je incasso vergunning kwijt en dan wens ik je veel succes met het weer terugkrijgen...

Automatische incasso's zijn in NL gewoon een "lek" systeem wat berust op vertrouwen, met een telefoonboek in je hand heb je al genoeg info.

[webinn]

ga even lekker in zee met een provider die je dit voor je kan aanbieden (bv http://www.google.com/sea...official&client=firefox-a ). Dit is niet iets om zelf met te experimenteren, zeker als je niets van encryptie kent (cfr "base64")

[steffex]

Verwijderd schreef op woensdag 13 januari 2010 @ 14:50:
... Het komt er eigenlijk op neer dat het niet mogelijk is dit te beveiligen voor kleine partijen zonder veel geld. ...

en daarom zijn er payment providers, die het voor kleine organisaties mogelijk maken om allerlei soorten betalingen te verrichten.

Helaas geef je in je posts niet aan waarom je creditcard gegevens wilt opslaan! Dit zou namelijk voor ons het hele verhaal een stuk duidelijker maken.

[Verwijderd]

Wat is nu eigenlijk je doel met al die informatie?

Helaas geef je in je posts niet aan waarom je creditcard gegevens wilt opslaan! Dit zou namelijk voor ons het hele verhaal een stuk duidelijker maken.

Ik moet bekennen dat ik niet helemaal eerlijk ben geweest in mijn openingspost. Ik heb geen intentie om CC gegevens op te slaan. Een reden dat ik dit vraag is, dat ik wil polsen of dit uberhaupt gedaan wordt en wat voor technieken daarvoor worden toegepast. Uit de antwoorden is dat niet gebleken. Een fictieve situatie dus, uit nieuwsgierigheid wat dat betreft. Mijn excuses als dit als storend ervaren is. (ik begrijp dat amateurs in encryptie en aanverwante zaken mbt beveiliging zich niet moeten bezig houden met opslag van CC gegevens)

Waar het op neerkomt is dat ik bezig ben met een webomgeving waar ik wel belangrijke informatie moet opslaan, zoals bankrekeningnummers. Ik zoek daarvoor binnen een PHP omgeving naar een zo veilig mogelijke oplossing. Tot dusver lijkt mij de veiligste manier om deze informatie te encrypten met een AES encryptie waarvan ik de key bepaal door het wachtwoord van de gebruiker. Zodoende hoef ik een key niet op te slaan (tenminste in zijn oorspronkelijk vorm) en moet een kwaadwillende tijdens eens sessie het wachtwoord uit het geheugen lezen of uit de post data weten te onderscheppen (of het MD5 opgeslagen wachtwoord decoderen). Het wachtwoord wordt met een bepaalde $salt en MD5 opgeslagen. De key zelf wordt met een andere $salt en MD5 omgezet om de data in de database te encrypten. Mochten er betere methodes zijn dan hoor ik die uiteraard graag.

Voor het encrypten kan mcrypt gebruikt worden. Maar voor diegene die voor soortgelijke problemen staan zou deze link interessant kunnen zijn. Uit de benchmark blijkt deze in ieder geval sneller te zijn dan mcrypt.

Ik dank iedereen voor de input. En nogmaals sorry dat het eigenlijk niet om CC gegeven gaat.

[cariolive23]

Verwijderd schreef op woensdag 13 januari 2010 @ 23:45:
Een reden dat ik dit vraag is, dat ik wil polsen of dit uberhaupt gedaan wordt en wat voor technieken daarvoor worden toegepast.

Uiteraard wordt dat gedaan, banken en paymentproviders zullen wel moeten!

Uit de antwoorden is dat niet gebleken.

Beter lezen, je hebt genoeg links en informatie gekregen over hoe je dit soort gegevens veilig moet opslaan en waar je meer informatie kunt krijgen. Het komt er op neer dat dat alleen de eigenaar van de informatie, de informatie kan inzien. Zie de linkjes naar SELinux en SEPostgreSQL, dan krijg je een idee hoe dat werkt.

(ik begrijp dat amateurs in encryptie en aanverwante zaken mbt beveiliging zich niet moeten bezig houden met opslag van CC gegevens)

En op dit gebied zijn vrijwel alle programmeurs een stelletje amateurs, me incluis.

Ik zoek daarvoor binnen een PHP omgeving naar een zo veilig mogelijke oplossing.

Wat is er mis met de database? Daar staat de data, dat moet je dus beveiligen. Het begint al met het aanmaken van de juiste databaserollen en het toekennen van de juiste rechten. Wanneer jij er voor zorgt dat alleen rol X de gegevens kan selecteren en dat deze rol nooit via jouw PHP-applicatie kan worden gebruikt, zul je nooit data via deze kant gaan lekken.

Uiteraard zijn er nog vele andere issues, maar je moet er in de eerste plaats voor zorgen dat niemand bij de data kan komen. Encryptie is belangrijk, maar wanneer jij de versleutelde data op straat gooit (teveel rechten toekent) komt er een moment dat iemand de boel kan kraken. En omdat bankrekeningnummers vele jaren hetzelfde blijven, 50 jaar is niets bijzonders, heeft een hacker ook vele jaren de tijd om de boel te kraken.

Dit betekent dus ook dat je dit soort gegevens niet op shared hosting kunt opslaan, de beheerder van de database heeft superuserrechten en dus toegang tot jouw data. Backups die hij/zij maakt, worden ook ergens (waar?) opgeslagen, iedereen die hiertoe toegang heeft, kan dus ook weer bij jouw data komen.

Zie de handleiding van jouw database hoe deze kan worden ingezet om de inkomende data te gaan encrypten, je kunt dit met triggers automatisch inregelen. Zorg er wel voor dat de logging van queries uitstaat, anders zijn de loggings weer een veiligheidsprobleem.

Ps. MySQL is nogal beperkt op het gebied van veiligheid, hou dat in je achterhoofd